Re: The 0.0000000000001 bug
Re: The 0.0000000000001 bug
But then it gets rid of the decimal point altogether :(
Re: The 0.0000000000001 bug
Round then add .01
i have nver seen this bug
Re: The 0.0000000000001 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?
Re: The 0.0000000000001 bug
if its .4, then the glitch hasnt occured? and everything is ok?
Re: The 0.0000000000001 bug
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
Re: The 0.0000000000001 bug
@lookie
round(1.234,2) = 1.23 or
round(1.234*100)/100.0 = 1.23
Re: The 0.0000000000001 bug
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.
Re: The 0.0000000000001 bug
Quote:
MMF uses single-precision floats.
No, MMF uses double-precision flotaing point values since the build 243 (except for values passed to / retrieved from extension objects).
Re: The 0.0000000000001 bug
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?
Re: The 0.0000000000001 bug
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).
Re: The 0.0000000000001 bug
Quote:
Originally Posted by Looki
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
SEELE: Workaround. :D It's just cooler to have direct support ;)
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 random
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
Re: The 0.0000000000001 bug
Quote:
Originally Posted by Nick
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?
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).