Weird behavior of numbers in as3

June 5th, 2007

My colleague Bram de Jong at splicemusic did some tests with number types in arrays to find out, if we can save memory somehow. However his findings are rather not expected that way. Numbers can loose their type in an irreproducible way.

So lets try:

 
trace( getQualifiedClassName( uint( 0 ) ) ); // int
trace( '28bits', getQualifiedClassName( uint( 0x0fffffff ) ) ); // int
trace( '29bits', getQualifiedClassName( uint( 0x1fffffff ) ) ); // Number
 

Above all check this:

 
			var num: uint;
 
			for( var i: int = 0 ; i < 64 ; i++ )
			{
				num = 1 << i;
 
				trace( i, getQualifiedClassName( num ) );
			}
 

From 0 to 27 it is int
From 28 to 31 it is Number
From 32 to 59 it is int (again)
From 60 to 63 it is Number (again)

The disadvantage of this is that Numbers are slower in computation as well as reading, writing in an Array. And however it doesn't make any sense at all. Bram has already sent a note to adobe. I'll keep you updated.

Filed under: actionscript

6 Responses to “Weird behavior of numbers in as3”

  1. someone Says:
    June 5th, 2007 at 11:02 pm

    Anti-Spam: What is the sum of 7 and 3?

    int

  2. bram Says:
    June 6th, 2007 at 4:17 pm

    Someone @ Adobe writes us back the explanation:

    The AS3 VM uses 32-bit Atom formats to store various types. 3-bits of the Atom describe the type data, leaving 29-bits for actual data. In some cases, like null/undefined/void/etc, we use 3-bits plus a few more bits to define the type.

    For signed integers, we have 28-bits to work with plus a sign bit. For unsigned integers we have 29-bits (or maybe 28 with the upper bit always zero?). Once your number gets larger than 28/29 bits, we dynamically switch it to a Number Atom type, which contains a 3-bit type value with a 29-bit ptr. All ptrs are 8-BYTE aligned so we get away with using 29-bits there.

    All three formats are basically interchangeable. When storing a number in an Atom, we see if it’s an integer and fits within the 28/29 bits. If so, we store it as a int/uint value – otherwise we store it as a Number value.

    Which, sadly enough makes total sense and is a bit of a bummer for us…

  3. Nate Chatellier Says:
    June 12th, 2007 at 11:26 pm

    Great post… but, hmm, Sho claims that his tests led him to believe that Numbers may actually be faster than ints in Flash:

    Grant Skinner’s tests showed that ints had only a small improvement over Number, but uint was much worse then either:

    Michael Baczynski claims that it is converting between types is the big killer (which makes sense):

    It seems like the only consistent claim is that numerical data types in Flash are inconsistent ;)

  4. Nikolaj Says:
    June 17th, 2007 at 9:48 pm

    Speaking of weird number behavior.. What is going on here?

    var n:Number = 2374;
    trace(n);
    trace(n*.01);

    Traces:

    2374
    23.740000000000002

  5. bram Says:
    June 18th, 2007 at 9:16 am

    Nikolaj, that’s pretty standard IEEE roundof errors. Have a look here:

    http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

  6. Tenegri’s blog » Blog Archive » Are there real int and uint types? Says:
    May 3rd, 2008 at 5:19 pm

    [...] Christensen: AS3 Interesting Numeric Storage Behavior Andre Michelle: Weird behavior of numbers in as3 Michael Baczynski: Bitwise gems – fast integer math Michael Baczynski: Int, uint and number data [...]

Leave a Reply