“The internal findings when storing a uint

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) …”

Should be

“The internal findings when storing a uint

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

Otherwise it is easy to think that uints should only be used when the expected value is from 0 to 27!

var num: uint;

for (var i: int = 0; i < 64; i++)
{
num = 1 << i;

trace( i, getQualifiedClassName( num ) , num);
}

0 int 1
1 int 2
2 int 4
3 int 8
4 int 16
5 int 32
6 int 64
7 int 128
8 int 256
9 int 512
10 int 1024
11 int 2048
12 int 4096
13 int 8192
14 int 16384
15 int 32768
16 int 65536
17 int 131072
18 int 262144
19 int 524288
20 int 1048576
21 int 2097152
22 int 4194304
23 int 8388608
24 int 16777216
25 int 33554432
26 int 67108864
27 int 134217728
28 Number 268435456
29 Number 536870912
30 Number 1073741824
31 Number 2147483648
32 int 1
33 int 2
34 int 4
35 int 8
36 int 16
37 int 32
38 int 64
39 int 128
40 int 256
41 int 512
42 int 1024
43 int 2048
44 int 4096
45 int 8192
46 int 16384
47 int 32768
48 int 65536
49 int 131072
50 int 262144
51 int 524288
52 int 1048576
53 int 2097152
54 int 4194304
55 int 8388608
56 int 16777216
57 int 33554432
58 int 67108864
59 int 134217728
60 Number 268435456
61 Number 536870912
62 Number 1073741824
63 Number 2147483648

The Adobe Guys must to filter this issue, but in some way a programmer should understand this bad function in interpreted languages.

Yeh the uint constantly does conversions from int to Number so that is slower by far, conversions are expensive. The important thing is I guess is to go with one type and stick with it. Conversions are the bottleneck in uint when bitwise operations happen.

Grant Skinner’s tests showed that ints had only a small improvement over Number, but uint was much worse then either:
http://www.gskinner.com/blog/archives/2006/06/types_in_as3_in.html

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

Yes it has to do with the underlying framework that runs probably in C or C++ that runs the virtual machine. This only happens when doing performance tweaks like bitwise shifts because it accesses the type faster due to direct memory but because there is no wrapper (I am speculating) then it passes the types back without any filtering.

This does not happen on a normal loop with a typed iterator only performance areas where bitwise shifts are faster (which are in many places stop by polygonal labs to see that the cleanest code or simplest code is not always the fastest). Optimization can sometimes be a gotcha. Now on iterations using bitwise on a high performance app there will be slowdowns appearing in the range where Numbers appear rather than int. Again, not a big deal if you aren’t really looking to extend every bit of performance you can out of the flash vm, for most purposes its overkill. When doing games and other really high concurrent systems like that it becomes an issue. (i.e. iterating over objects in a multiplayer map rapidly)

You don’t print out the value of num, but I suspect you’ll find that «1 << 1» is the same as «1 << 33». If so, it inherits this behaviour from the SHL instruction on Intel architectures.