Generation of test case data for Scala and Java, in the spirit of QuickCheck. When your test fails, it gives you a minimised failing test case and a way of reproducing the failure immediately.
TrialsApi.chooseWithWeights and TrialsApi.alternateWithWeights both impose a precondition that weights must be strictly positive.
This precondition should be relaxed slightly by allowing weights to be zero - so long as they are not negative, this should be permitted, the interpretation being that the choice or alternative is filtered out by having a zero weighting.
The reason for wanting this is to support the use of weighted choices or alternations within flat-mapping, where the weights are dynamically computed from some prior context in the flat-map (or possibly outside of a flat-map but driven by some configuration setting). This is handy for say, generating operations to apply in sequence, where the choice of operation may depend on prior state - we want a way of sometimes dropping out operations where they would not be appropriate.
While this can be done via filtering too, that approach tends to be less efficient and can lead to case starvation.
NOTE: the current implementation would be incorrect if the precondition check was to be simply relaxed - so we need a test for this prior to making the change.
TrialsApi.chooseWithWeights
andTrialsApi.alternateWithWeights
both impose a precondition that weights must be strictly positive.This precondition should be relaxed slightly by allowing weights to be zero - so long as they are not negative, this should be permitted, the interpretation being that the choice or alternative is filtered out by having a zero weighting.
The reason for wanting this is to support the use of weighted choices or alternations within flat-mapping, where the weights are dynamically computed from some prior context in the flat-map (or possibly outside of a flat-map but driven by some configuration setting). This is handy for say, generating operations to apply in sequence, where the choice of operation may depend on prior state - we want a way of sometimes dropping out operations where they would not be appropriate.
While this can be done via filtering too, that approach tends to be less efficient and can lead to case starvation.
NOTE: the current implementation would be incorrect if the precondition check was to be simply relaxed - so we need a test for this prior to making the change.