ActionScript 3 Number data type problem with long integer values

Posted in ActionScript 3 by Branislav Abadjimarinov on 6/23/2010 4:22:00 PM - CST

Lately I've been doing some front-end flex programming and in a series of posts starting with this one I'll share my view of the Adobe's programming framework. First I'll start with ActionScript 3 - the programming language used in flex. It is an EcmaScript derived language. From what I've seen for a month or so programming there are two basic rules in the ActionScript world:

The owls are not what they seem and
There are a lot of owls

Maybe it is a good choice in flash with its simple syntax and agility but when it comes to enterprise programming I've found that it fails too often to accomplish simple tasks. As a .net refugee I expect at least the basic language features to be working predictably.
Consider a case in which you need a really big integer number to be passed to the UI of your flex application. Let's say that it is bigger than 32bits. There is a special data type Number in ActionScript to preserve 64bit values and it seems to do it well ... except when your integer number is bigger than 16 digits. In that case god knows what happens to your number.

    var reallyBigNumber:Number = Number(2885118563511697402);

    trace(reallyBigNumber); // traced value is 2885118563511697400

    var asString:String = reallyBigNumber.toPrecision(21);

    trace(asString); // traced value is 2885118563511697408.00

Not only your number is "rounded" to a different value but when you call toPrecission function (which is expected to give you more precise representation of the number) you get a whole new third value. To bring even more confusion the Flash builder's watch shows that reallyBigNumber's value is 2885118563511697408 which is not what trace prints to the console. All the provided numbers are far from the max value of the Number data type. Go figure.
Maybe the Number data type is perfect for flash animations where you have two trees and five owls flying around but when you build an enterprise framework you got to have strong foundations.

[Edit 9/2/2011]

For an year or so about 2 or 3 of my work collegues also hit the same issue in several different areas. Also, as Art commented on my previous post, this is not a bug but rather a tech limitation of actionscript 3 and hence flex limitation also.
In a nutshell the actionscript Number data type is implemented by the IEEE-754 standard. The IEEE-754 is a standard for doble precission floating point numbers. So the equivalent of actionscript 3 Number type is java and .net's double. This is the reason for loosing precission when transfering java long values to actionscript Number.

Comments

Trackback on 7/6/2010 7:57:51 PM - CST

czmqhvlg - Google Search

Posted by shaffi on 7/9/2010 1:30:20 AM - CST

I too have the same problem, Did you find any solution for this?.

Posted by Branislav Abadjimarinov on 7/12/2010 1:35:00 AM - CST

No, there is no clean solution that I know of. I logged a bug to Adobe - https://bugs.adobe.com/jira/browse/ASL-95 but I sill have no answer. For my case I made a workaround. Since I need only to show the numbers I pass them around as strings. Another thing that comes to my mind is that you can keep the large number separated in an array of smaller numbers. Depending on what operations you need to perform on them you should choose different representation. Also another wild guess of mine is to try to use numbers that are powers of two - maybe the problem will not appear in this case. All of these are workarounds.

Posted by Art on 3/3/2011 3:07:32 PM - CST

It didn't get resolved because technically it's not a bug. The IEEE-754 standard (http://en.wikipedia.org/wiki/Double_precision_floating-point_format) which Flash follows correctly, specifies that the "integer" section of a double is 53 bits long (sign bit included) which is equal to: 4,503,599,627,370,496, hence why you ran into the lack of precision above 16 decimal digits.
This is also clearly documented in the Flex SDK (http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Number.html). Nowhere in the documentation it states that it preserves a 64bit (long) int. The Number class is a floating point value, developers should be aware of the difference in precision between Integer values and floating point values. In this case the owl is very clearly an owl. Even though technically this doesn't give the full range as a 64 bit long int, it's good enough for most of everything in the enterprise world. Bigger values can be addressed in different fashions, like Branislav suggested, strings can be used for example. By no means am I trying to imply that Flex is better than .net for the enterprise world. They both have their pros/cons, but Flex is constantly being used in the Enterprise world very successfully.

Posted by David mecham on 3/9/2011 11:53:33 AM - CST

Number is a Double value, not a Integral value, so when you get large, it is going to round off the integers...

Posted by Ganz on 5/9/2011 4:19:34 PM - CST

Is there any solution to store a 64 bit integer?
either using Number or any other wrapper class?

Posted by encoder on 5/13/2011 9:03:24 AM - CST

you can build your own number class to resolve this problem. and it shouldn't be a problem for you if you are building enterprise applications.
any programmer in need of more then double float is smart enough to create a more precise data type. like stacking unsigned integers (on the flash platform). the tricky part is the manipulation. PS: it's called overflow and actually it appears at 16 digits so 15 digits are usable.

Posted by Branislav Abadjimarinov on 5/18/2011 1:17:00 AM - CST

It's an option but you'll have to do it yourself. Also you'll have to handle serialization/deserialization and all kinds of stuff. I honestly expect any UI framework to provide this for me. Maybe I'm too spoilt from .net.

Branislav Abadjimarinov's technical blog