very strange property behavior

[abeall]

this is copy pasted code:

m._alpha = 15;
trace(m._alpha);

output:
14.84375

What is going on here? Naturally there is alot of other code involved, but
I've run into this problem a number of times before, so I'm sure some guru out
there has an idea what it is. It is extremely strange. In all other cases, I
found some work around. In the case I'm currently facing, I cannot think of a
work around. Why does the value "15" get turned into that strange number?

[Rothrock]

Internally Flash maps the alpha to one of 255 values. So only 0, 25, 50, and
100 will return the exact amount you put in. That is why you should never rely
on retrieving the value to use it in future calculations. If you need exact
values for iteration, store the value in a variable, that will give you
accuracy to 15 places.

Before you ask, position coordinates are only stored to .05. This is a twip,
the twentieth of a pixel. And again if you need accurate values you should
store the actual value in a variable and apply it as needed.

[abeall]

Huh, I never noticed that it always returns weird values(although I did know _x
and _y is rounded)... I'll remember that. Seems that _alpha property
should/could have had it's value range just be 0-255(instead of 0-100, with
overflow) if that's the case?

Of course, it's turned out that the inaccurate values were not causing my
problem. I can't figure out what is.

[NSurveyor]

I'm a bit confused... You say there are really 255 values... yes? So, if you
set the alpha to x/255*100 and then trace alpha/100*255 you should get x, buy
you don't get the correct number... however if you use x/256*100 and
alpha/10*256 you get the correct values. So, wouldn't that mean that the value
ranges from 0-256? 257 values!?! Ex:

MovieClip.prototype.addProperty('_alpha255',function(){return
this._alpha/100*255;},function(x){this._alpha = x/255*100});
MovieClip.prototype.addProperty('_alpha256',function(){return
this._alpha/100*256;},function(x){this._alpha = x/256*100});
_alpha256 = 20;
trace(_alpha256);
_alpha255 = 20;
trace(_alpha255);

[Rothrock]

Sorry I should have said one of 256, I forgot 0 ? so there are 256 values or
2^8 or 8-bit. My algebra is rusty, but I'm thinking it is like Arrays being
zero based. For this little trick you should use the number of possible
choices, 256, even though they are mapped 0 to 255.

As for abeall's idea of just having alpha go from 0 to 255, it does make sense
to geeks like us. :) But I imagine that 0 to 100 percent is easier for most
folks to understand. I also seem to recall that some folks who were poking
around in the new way of doing video and all noticed that a pixel/movieclip (I
can't quite remember) could now have a "color" of something like 0xffffffff.
Basically 4 pairs of hex or 4 8-bit groups which the first three groups being
0-255 for RGB and the last group being 0-255 for the alpha. Kinda all makes
sense and makes a nice symmetry. Now all we need is gradient masking!

[NSurveyor]

Yes, but in order to get 100 percent alpha you need to use 256, because
256/256*100 = 100; ANd to get 0 percent you need to use 0, because 0 /256*100 =
0; So, it starts from 0 to 256, which is 257? I know, 256 makes sense.