Sigh....this again?? (Any why is everything a bug - maybe go do a search first? )
Its not a bug but a limitation with floating point numbers. Most fractions and real numbers cannot actually be accurately represented by a float value. They are approximated and so error creeps in.
https://floating-point-gui.de/errors/rounding/
https://www.theregister.co.uk/2006/08/12/floating_point_approximation/
This code below shows the ACTUAL value being stored and you might be suprised to know that most of those values are not actually what you think they are
// Project: test27
// Created: 2019-03-19
// show all errors
SetErrorMode(2)
// set window properties
SetWindowTitle( "test27" )
SetWindowSize( 1024, 768, 0 )
SetWindowAllowResize( 1 ) // allow the user to resize the window
// set display properties
SetVirtualResolution( 1024, 768 ) // doesn't have to match the window
SetOrientationAllowed( 1, 1, 1, 1 ) // allow both portrait and landscape on mobile devices
SetSyncRate( 30, 0 ) // 30fps instead of 60 to save battery
SetScissor( 0,0,0,0 ) // use the maximum available screen space, no black borders
UseNewDefaultFonts( 1 ) // since version 2.0.22 we can use nicer default fonts
y as float = 1.0
do
y=1.0
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
dec y,0.1
Print(str(y,10))
//Print( ScreenFPS() )
Sync()
loop
The best way to correctly account for this is to use integers where possible or when comparing floats use <= or >= when you want to detect crossing thresholds.
