You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: This is part of #1093, where I encourage people to work on the shrinker. As such I will not be working on it myself and encourage you to take a look at it if it takes your fancy.
Due to the underlying representation, Hypothesis usually wants to return lists of things in sorted order of increasing complexity (this is strictly speaking not always true, but it is true for "well behaved" element strategies, including anything in hypothesis.strategies).
These should be in order of ascending size, so that the correct answer is ['', '0', '00', '000', '0000'].
The problem is that our current sorting logic is focused entirely on blocks. These basically correspond to individual low-level primitives. This does not allow the sorting to have any sort of higher level knowledge of how to move things around, which is required here.
I believe that we have all of the correct information under the hood to do this relatively easily. One possible approach here would be:
Partition all drawn examples by their depth and label (this ensures you get non-overlapping examples that are "roughly similar")
Where those partitions have more than one element, attempt an insertion sort on them to reorder the byte stream to put them in order.
Some care may be needed when examples are of difference size because swapping them might not be valid even if it looks it from the individual examples because of what bytes come after it in the underlying representation.
The text was updated successfully, but these errors were encountered:
Note: This is part of #1093, where I encourage people to work on the shrinker. As such I will not be working on it myself and encourage you to take a look at it if it takes your fancy.
Due to the underlying representation, Hypothesis usually wants to return lists of things in sorted order of increasing complexity (this is strictly speaking not always true, but it is true for "well behaved" element strategies, including anything in hypothesis.strategies).
Sometimes this works currently:
(simplicity for integers is size then sign, so that's the correct order)
However for more complex objects it doesn't:
These should be in order of ascending size, so that the correct answer is
['', '0', '00', '000', '0000']
.The problem is that our current sorting logic is focused entirely on blocks. These basically correspond to individual low-level primitives. This does not allow the sorting to have any sort of higher level knowledge of how to move things around, which is required here.
I believe that we have all of the correct information under the hood to do this relatively easily. One possible approach here would be:
Some care may be needed when examples are of difference size because swapping them might not be valid even if it looks it from the individual examples because of what bytes come after it in the underlying representation.
The text was updated successfully, but these errors were encountered: