I think it should work, the step will counts from the default value.
So currently:
1. if the user set default value to X1 and then he iterates forward 100 times then he
will get some X2. During this calculation, he could get "100" rounding issues.
2. If later the user decides iterates backward then most probably he will not get X1, and
the amount of possible "rounding issues" will be 200.
If the user will repeat steps 1. and 2. then each time the values will "float".
If we will use counter then in the worst case we will get only two roundings
per step: X1+step*100 = X2(if we will use fma we will get only one for every
step).
It will not solve all issues but at least will make the iteration "stable".
On 2/17/20 1:59 am, Alexey Ivanov wrote:
Hi Vlad,
The idea looks reasonable. However, it does not allow for manual editing. The
cases where max and min values are not multiples of step would be hard to
handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1;
how many ticks are there? What if the user enters 1.01015; the value should
change to 1.11015 or 0.91015.
On 13/02/2020 22:22, Volodin, Vladislav wrote:
Hello Sergey, Alexey and Pankaj,
I am reading the current discussion and I was thinking about an idea changing
the code in the way that instead of working with float/double numbers we work
with integer ticks. For example, the model remembers the min/max/step values
and calculates a number of steps required to reach from min to max. All
increment/decrement actions are done against the current ˋtickˋ value. If the
current ˋtickˋ reaches 0 - we return min; if maxTick — we return max. And the
current value can be always counted as (min + tick * step) if tick is neither
zero, nor max tick count.
At least if we deal with integer ticks, but all reading operations calculate on
the fly, we will be able to control the representativeness of output.
As always, I don’t know all the details and possible consequences, so feel free
to ignore my email, if I am wrong.
Kind regards,
Vlad
Sent from myPad
On 13. Feb 2020, at 22:34, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote:
On 2/12/20 8:21 am, Alexey Ivanov wrote:
The bug report says that going from -0.15 to -0.10 does not allow going back to
-0.15. This happens because the result of this sequence of operations cannot be
represented exactly, or, in other words, because of rounding errors; or rather
the result is less than the set minimal value.
Can we set the value of the spinner to the set minimal value instead of
disallowing the operation. I mean, after going up the displayed value is -0.10;
going down by 0.05 gives the result which is less than the minimal value for
the spinner, and thus going down is not allowed. What if we set the value of
the spinner to its minimal value instead?
In this case, we will need to update all types including int. Isn't it will be
surprised that the spinner will show the value which is not calculated as
"defaultValue + stepValue * stepCount"?
--
Best regards, Sergey.
--
Best regards, Sergey.
