Is actionscript selfish lol?

[Killya]

I have this script:

on(release){
 _global.combospeed -= 0.1;
}

and the same with + version.
I also have a dynamic text where the combospeed is show.
But when I do - 0.1 at 9.6 --> 9.5 it doesnt subtract by 0.1, but by 0.0999999999
WHY?!
it also adds 0.099999999 at 9.5 --> 9.6
WTF is wrong with actionscript? xD

[glosrfc]

There's nothing wrong with Actionscript. It's your computer that's "faulty"
http://en.wikipedia.org/wiki/Floatin...uracy_problems

[adBuryD]

try using, Math.abs(var)

[Killya]

doesnt Math.abs() make everything that is negative positive? O=
I tried it, doesn't work :<

[TheCanadian]

Did you read the link that glos posted?

[FizixMan]

Maybe try refactoring the way the numbers work so that all this arithmetic is working with integers (that is, work with numbers 10 or 100 times you would normally) and only convert the final number back down (divide by 10 or 100) when finally using the values for say, ._x and ._y properties.

Otherwise maybe you can do something like this:

_global.combospeed = Math.Round((_global.combospeed - 0.1) * 10) / 10

Which would round your combospeed to the nearest tenth of a decimal place. (change the 10's to 100, or 1000 for more decimal places of precision)

[glosrfc]

Perhaps this is a simpler explanation of the floating point error with your PC:
http://kb2.adobe.com/cps/139/tn_13989.html

You can avoid these type of errors by adopting two simple rules of thumb:
1. Avoid any kind of rounding until the last possible moment in your calculations.
2. Rethink the level of precision you really need. For example, if combospeed is supposed to represent the movement of a movieclip across the stage, you'll only really want it to move in whole pixels anyway! Similarly, if you're attempting to increase/decrease the _alpha of a movieclip, the minimum step is 0.4, so you should probably be adding/subtracting 0.5 each time.

[Killya]

Thanks glosrfc, but with my half year experience and only 15 years old I don't understand both those articles (could be because im reeaaaly tired)
I ask my math teacher today(also a programmer) and he gave the same tip as Fizixman, I also think that is one of the simplest way,
I don't use any round commands in my script so that isn't it glosrfc, but ty anyway

[glosrfc]

No problem. To simplify it further for you....

...some numbers are known as recurring numbers. For example, 1/3 = 0.33333..
The 3 is repeated indefinitely so we say that the answer is 0.3 recurring. Notice the dots following the number which is mathematical shorthand to tell us that the 3's keep repeating.

Now, we might not be able to understand how some of these numbers work (although your Maths teacher will be able to explain them) but our brains can cope with them in the real world. Imagine that you have a cake which you cut into three identical pieces. Each piece measures 0.33333.. parts of that cake but you know that the whole cake is still there. If you put the pieces back together you will get a whole cake again. So, when we add 0.33333.. + 0.33333.. + 0.33333.. in our heads we get the right answer, 1, because we know that must be the right answer, and our brains can automatically cope with all of those 3's.

Computers aren't that clever, although they're a lot faster at dividing cakes! When a computer divides a number it only has so much storage space to hold those floating point numbers, i.e. all of those 3's. At some point, when the storage space runs out, it ignores all of the remaining numbers. Let's just imagine that your computer can only store 7 digits in its memory at one time. So 0.3333333333333.. wil be shortened to 0.33333
Now, when we ask the computer to add those numbers back together, it gives us the wrong answer:
0.33333 + 0.33333 + 0.33333 = 0.99999
It's close to 1 but, not close enough, because the computer has lost all of those extra 3's that stretch to infinity.

The more you compute with numbers like these (typically when a computer is asked to round a number internally) the more often these floating point errors occur, and the bigger the error becomes.

And yes, rounding the number yourself is the easiest way to get round the problem, although the key phrase (linked to my second rule of thumb) is to make sure that your own rounding function uses an appropriate level of precision. FizixMan mentioned that too at the end of his post.

There's a few easy ways to remind yourself about the correct level of precision. Just say to yourself, elephants or ants!
If you want to weigh elephants, you'd use kilogrammes. If you want to weigh ants, you'd use grams
Or say snakes and worms (you'd use feet/metres to measure the length of a snake, and use inches/centimetres to measure a worm)

Hope that helps.

[Killya]

Thanks! That was like, an awesome easy explenation, but I don't know why it would get errors at particular moments when I'm doing 9.6-0.1
Guess I never know!
I fixed it now by multiplying and dividing by 10 again

[FizixMan]

It happens because of the estimations that processors use when working with these floating-point numbers.

Remember, to you and me, 9.6 and 0.1 are simple, exact numbers. To the computer, they are actually approximations. When the computer performs arithmetic on them, it will also produce an approximate number. Often these approximations are not an issue, but sometimes they crop up randomly and in very simple conditions (such as yours) or in very complex conditions such as this:

var x:Number = 1/3;
var y:Number = 2/3;
var z:Number = 4/3;
trace((x - y) * 3 - z + 9 * y / 3 + x);

Something like this SHOULD trace out 0, but instead it gives you 0.000000000000000277555756156289.

So people usually work around it by using the correct scale of units (kilograms vs grams) or performing the calculations then rounding to the proper number of significant digits at the very end.