For future readers who are unaware of what is causing this bug. It is the floating numbers itself, when you operate with floating points, its 15th to 32th decimal places produces a random numbers which leads "mod(),float(),ceil(), floor division" to inaccurately do their computations when there is one or more floating numbers included on at their operations... Floating point issues existed ages ago until now.
This can be observed by using this sample code:
Code: Select all
x:=0.05+0.01,y:=0.95-0.05,z:=15.324-3
Setformat,float,0.32
msgbox %x%`n%y%`n%z%
Setformat,float,0.32
x:=0.05+0.01,y:=0.95-0.05,z:=15.324-3
msgbox %x%`n%y%`n%z%
To get with this modulo problem. replace the built-in function mod() by adding this function to your script, this will override the default mod() function:
Code: Select all
mod(a,b,decimalplaces:="") ; since autohotkey built-in modulo has a bug, this will fix the problem for integers and floating points
/*
computation was
if decimalplaces=
return round(a - (b * floor(round(a/b,14))),14)+0 ; since 15th decimaplaces and above provides unexpected numbers, this fixes the problem
else return round(a - (b * floor(round(a/b,decimalplaces))),decimalplaces)+0 ; user can specify the decimal places of the rounding
modulo:=rtrim(rtrim(modulo,0),".") ; remove trailing zeros and dot if not needed
*/
{
modulo:=((decimalplaces="")?(round(a - (b * floor(round(a/b,14))),14)):(round(a - (b * floor(round(a/b,decimalplaces))),decimalplaces)))+0
return rtrim(rtrim(modulo,0),".")
}
floor() and ceil() is also most vulnerable to this issue since rounding up/down WHOLE NUMBERS in floating point format produces jagged numbers at its 15th to 32th decimal places.
eg. 0.99+0 results 0.98999999999999999111821580299875 using a 32 floating point precision.