Printable View
I'm sure many of you have seen it at some point.
If, for example, you do lots of calculations to a number, just adding or subtracting 0.1, after a while the number will end up something like 0.00000001 instead of landing on 0.
Is there any known way to avoid this?
Round the value
But then it gets rid of the decimal point altogether :(
Round then add .01
i have nver seen this bug
But if it's 0.4 and you round it then add 0.1, you end up with 0.1 instead of 0.4?
if its .4, then the glitch hasnt occured? and everything is ok?
I agree this is annyoing. MMF uses single-precision floats. I really hope that MMF3 won't - that way, floating point calculations will be much more accurate.
Anyway, I also hope for optional parameters in MMF3, so e.g. you can specify the number of digits to round to using Round(), like in PHP.
round(1.234) = 1
round(1.234,2) = 1.23
@lookie
round(1.234,2) = 1.23 or
round(1.234*100)/100.0 = 1.23
All programming languages have problems with the precision of floating points data types. Even doubles have the issue you are talking about but it might take longer before you can see it.
It happens because you cannot have infinite precision with a finite number of bits. At some point you get to a number that the bits cannot represent and it has to set the value to the closest value it can represent.
No, MMF uses double-precision flotaing point values since the build 243 (except for values passed to / retrieved from extension objects).Quote:
MMF uses single-precision floats.
The Counter object allows us to customise the format of the numbers it holds.
Will we be able to have this customisation with alterable values also?
SEELE: Workaround. :D It's just cooler to have direct support ;)
Andos: You're right - But I never really had this kind of problem with doubles (Never did anything complex though).
Yves: Oh, thanks for the info. I didn't know that (Well, I knew that extensions use floats, so I assumed MMF would in general).
yeah in that case it'd make sense for the extension interface to use doubles too... the way it is now unnecessarily cripples precision of extensions that use doubles internally (like the lua objects)Quote:
Originally Posted by Looki
yes vararg would make a lot of functions just plain nicer to use, ESPECIALLY 'random()' or even a 'choose()' function that can be supplied with however many numbers you want and it returns one at randomQuote:
Originally Posted by Looki
EDIT: but yeah you'll have to deal with this kind of precision issues; if you haven't noticed by now, 'sin()' and 'cos()' won't return exactly 0 when they should. about the only way to keep this from happening or at least just reduce it to cases you'd expect (such as x/3 or x/7) would be to use bignum, but that's slower and more complicated to implement
It's just the display format, not the internal format, the stored value has no specific format (for example your counter could be equal to 1.23456, it will display 1.23 if you selected 2-digit after decimal points in the properties).Quote:
Originally Posted by Nick