Open aliabbas-elastic opened 7 months ago
hi @aliabbas-elastic , I can confirm that I've observed the following generic behaviour: fields with a range leaning towards the minimum bound of the range
i think that what you are observing is a corner case of the above when rounding integer ranges with a fuzziness applied.
basically you reach a point where the "current" integer value reach the minimum bound of the range, 1
in your case.
in the next generation cycle, given fuzziness: 0.6
and range.min: 1
, the value that can be generated is 1 < x < 1.6
since internally the value are generated as float and than rounded to integer you end up having 1
again, and so on for all the every following generation cycle
the problem can be probably mitigated with a properly chosen mix of range.min
and fuzziness
:
a = range.min
b = range.min * fuzziness
b > a + 1
I see two options in order to deal with the problem directly in the code:
1 < x < 1.6
scenario rounded to 1
without violating fuzziness. we can agree that we want to violate fuzziness for that specific scenario :)range.min
upfront calculating the higher value that will not end up in the specific scenario. this does not violate the range.min
. not sure about ending up violating range.max
in general, without the extreme outcome of ending up generating the same value after a certain number of events, we should investigate the tendency for random numeric values to lean towards 0. i'm not an expert: not sure if it's a limit of the specific go random package or something more generic to randomness on computer, and/or it is a known limit that can be mitigated with proper approach
stubstatus
data stream, I am seeing the value of a field being set as the minimum value of therange
provided after a certain set of documents whenfuzziness
config is provided.Attaching the configs used:-
config.yml
Attaching the subset corpus generated for 200 events generated. Find the field
writing
in the corpus generated and it's values generated after a certain set of documents generated.