You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PGauxiliaryFunctions.pl has the function Round(x,n). It doesn't always work as you'd want it to. This is understandable, given rounding issues with floating point.
When floating point rounding errors accumulate in just the right way, they can move something like 0.5 to 0.4999...9 or similar. I am seeing that as an issue with:
$x = 3.3625/0.025;
$rounded = Round($x,0);
TEXT("When you round $x you get $rounded.");
with seed 4098 (if that even matters) which outputs
When you round 134.5 you get 134
In defaults.conf, there is numZeroLevelDefault => 1E-14. Would there be any objection to me redefining Round() to make use of this? One way to characterize what I would do is to add this to a number before rounding. So if it were internally 0.499999999999992, then it would become 0.500000000000002 and then get rounded to 1. It would be an approach that assumes something like 0.499999999999992 is really supposed to be 0.5, but rounding error crept in.
Everything I said would be adjusted if not rounding to a whole number.
Alternatively I could make a new subroutine with a different name.
The text was updated successfully, but these errors were encountered:
PGauxiliaryFunctions.pl has the function
Round(x,n)
. It doesn't always work as you'd want it to. This is understandable, given rounding issues with floating point.When floating point rounding errors accumulate in just the right way, they can move something like 0.5 to 0.4999...9 or similar. I am seeing that as an issue with:
with seed 4098 (if that even matters) which outputs
In
defaults.conf
, there isnumZeroLevelDefault => 1E-14
. Would there be any objection to me redefiningRound()
to make use of this? One way to characterize what I would do is to add this to a number before rounding. So if it were internally 0.499999999999992, then it would become 0.500000000000002 and then get rounded to 1. It would be an approach that assumes something like 0.499999999999992 is really supposed to be 0.5, but rounding error crept in.Everything I said would be adjusted if not rounding to a whole number.
Alternatively I could make a new subroutine with a different name.
The text was updated successfully, but these errors were encountered: