RFR: 8346107: Generators: testing utility for random value generation
theoweidmannoracle
duke at openjdk.org
Wed Dec 18 11:56:38 UTC 2024
On Wed, 18 Dec 2024 11:52:03 GMT, theoweidmannoracle <duke at openjdk.org> wrote:
>> Ok. I suppose I could factor this out into some extra class and extra file.
>> But is that worth it? Then I need to still somehow route all that logic through the constructor, and `nextDouble`. I think in the end I have more code and more abstractions, I don't yet see how that is worth it.
>>
>> Maybe you had a better idea in mind that I did not yet think of ;)
>
> To be more clear, without generics:
>
>
> abstract class FloatingGenerator {
> // specialCountDown detemines in how many iterations we generate the next special value.
> private final int specialMinFrequency;
> private final int specialMaxFrequency;
> private int specialCountDown;
>
> // .. constructor ...
>
> protected final bool shouldUseSpecial() {
> specialCountDown--;
> if (specialCountDown <= 0) {
> specialCountDown = RANDOM.nextInt(specialMinFrequency, specialMaxFrequency);
> return true;
> } else {
> return false;
> }
> }
> }
>
>
> Then in SpecialDoubleGenerator:
>
>
> @Override
> public double nextDouble() {
> if (shouldUseSpecial()) {
> int r = RANDOM.nextInt(VALUES.length);
> return VALUES[r];
> } else {
> return backgroundGenerator.nextDouble();
> }
> }
>
>
> If you make FloatingGenerator generic, though, of course, and rename the methods from nextDouble and nextFloat to just next for the generators, then everything except for the list of special values itself could be moved into FloatingGenerator. That would result in very clean code in my opinion. If you need to adjust the logic for special selection later, with the current approach, that requires changes in multiple locations, which in my experience, ultimately leads to inconsistencies.
I posted my second comment without seeing your latest comment. So it's not really a reply to that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22716#discussion_r1890116356
More information about the hotspot-compiler-dev
mailing list