ValueGenerator creates incorrect sequences due to the double arithmetic imprecision

[mkommend]

Example: ValueGenerator.GeneratorSteps(0.05, 1, 0.05) produces:

0.05, 0.1, 0.15000000000000002, 0.2, 0.25, 0.3, 0.35, 0.39999999999999997, 0.44999999999999996, 0.49999999999999994, 0.54999999999999993, 0.6, 0.65, 0.70000000000000007, 0.75000000000000011, 0.80000000000000016, 0.8500000000000002, 0.90000000000000024, 0.95000000000000029, 1.0000000000000002

while the excpected result is:

0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5, 0.55, 0.6, 0.65, 0.7, 0.75, 0.8, 0.85, 0.9, 0.95, 1.0

This could lead to incorrectly created problem instances, parameter ranges, etc.

[abeham]

Btw, we have similar logic in e.g. HeuristicLab.MainForm.WindowsForms.DefineArithmeticProgressionDialog (and the same problem). But notice that you can do it in 2 ways. Either start with the minimum and add the step (round it) until you reach or surpass the maximum. Or you could start from the maximum and reduce the step until you reach the minimum. The progression (1, 100, 10) would return 1, 11, 21, 31, ... in the first case and 1, 10, 20, ... in the second case. Maybe that was specific to the requirements of the CreateExperimentDialog where often the minimum of a parameter doesn't necessarily fit right into the progression ​see comment from swagner.

I think there should be some class in Common that computes such progresssions (and performs the necessary rounding) rather than distribute such ValueGenerators throughout the code.

[mkommend]

I agree that a common class for values generation should be used throughout HL. However, we created steps by starting from the start value and adding/subtracting the step width until the end is reached.

To achieve a sequence like you gave in your example (1,10,20, ...), which is not evenly spaced between the first two points you would have to call ValueGenerator.GenerateSteps(100,1,-10,includeEnd:true).Reverse().

A problem is that the ValueGenerator uses a HL.Random.FastRandom for creating of values according to a specified distribution(e.g., gaussian, uniform) and hence cannot be moved to HL.Common. An option would be to change the FastRandom to System.Random.

[mkommend]

r11434: Changed ValueGenerator to work with decimals instead of doubles to achieve a higher accuracy and adapted all problem instance providers accordingly.

[mkommend]

r11435: Added includeEnd parameter to ValueGenerator.GenerateSteps and removed overloads that take a Func<double,double> for value transformation.

[mkommend]

r11441: Changed expected values for training R² and neg log likelihood in Gaussian Process regression unit test.

The changes in the ValueGenerator resulted in two training rows to be slightly off (~E-16) for the generated spatial coevolution dataset and hence the unit test failed.

[mkommend]

The changes in this ticket depend on r11313 & r11348 from #2236.

[mkommend]

Ticket #2236 was closed as obsolete => r11313 & r11348 must be released with this ticket.

[abeham]

ok, changes look goood. I created #2301 to maybe put this class in a more prominent place. Or otherwise improve the numeric accuracy of the create experiment dialog.

[mkommend]

r11868: Merged r11434, r11435, r11441 and r11313, r11348 into stable.