Oh, and this:
parseFloat(n2Split[0])
also adds errors. The number (6.3) probably can't be accurately
represented in float/double format, so it's not quite 6.3 (it might be
6.3000000000000005123412, for example). So, when you then multiply it
by the power of 10 it won't be the same as when it was simply parsed
from the full string.
-Andy
On 3/9/07, Andy Herrman <[EMAIL PROTECTED]> wrote:
> I think the problem here is that this:
>
> var n2:Number = parseFloat(n2Split[0])*Math.pow(10,
parseInt(n2Split[1]));
>
> is not the same as doing the math. When you define it as a string the
> code will convert the number directly, trying to get as close as it
> can to the value.
>
> However, in the code you have there you're not doing the same thing as
> the string. Math.pow is going to be using floats/doubles in order to
> calculate the power. The instant that happens you lose accuracy, so
> before you even do the multiplication you've lost accuracy, so the
> resulting number won't be the same. So in fact, you aren't deriving
> the same value. This is the problem with floats.
>
> Also, you try to do this to show that they should be the same:
> trace(n1);//6.30000000000000e+51
> trace(n2);//6.3e+51
> trace(6.30000000000000e+51 == 6.3e+51);//true
>
> However, n1 != 6.30000000000000e+51.
>
> 6.30000000000000e+51 is simply the approximation that Flash uses when
> converting it back to a string. It maxes out at a certain number of
> digits after the decimal point, so the string representation isn't
> accurate. As your math later shows, there would be more digits way
> back at the 36th position (where the first digit is the 51st
> position).
>
> I hope that helps to explain it a bit.
>
> -Andy
>
> On 3/9/07, elibol <[EMAIL PROTECTED]> wrote:
> > I stated the origin of the number and what I want to do with it. The
number
> > is derived from a string using parseFloat, and it simply needs to
serve its
> > purpose as an operand in an expression.
> >
> > The relevant point of this discussion is that a hard coded
assignment
of
> > 6.3e+51 to a Number yields different results than 6.3e+51 parsed
from
a
> > string using the top level parseFloat() function in as3.
> >
> > It's a matter of consistency, not precision.
> >
> > What I specifically mean: How the number is derived should not
affect
what
> > it does. The number should simply represent the value it's
suppose to.
> >
> > Another experiment to elaborate on this point:
> >
> > var test1_str:String = "6.3e+51";
> > var n1:Number = parseFloat(test1_str);
> > var n2Split:Array = test1_str.split("e+");
> > var n2:Number = parseFloat(n2Split[0])*Math.pow(10,
parseInt(n2Split[1]));
> >
> > trace(n1);//6.30000000000000e+51
> > trace(n2);//6.3e+51
> > trace(6.30000000000000e+51 == 6.3e+51);//true
> > trace(n1 == n2);//false
> > trace(n1 == 6.3e+51);//false
> > trace(n2 == 6.3e+51);//true
> > trace(n1-6.3e+51);//1.32922799578491e+36
> > trace(n2-6.3e+51);//0
> >
> > On 3/9/07, Ron Wheeler <[EMAIL PROTECTED]> wrote:
> > >
> > > If you really have a number with 52 decimal digits of precision
> > > required, you can not store it in a double.
> > > I believe that a double is only good for about 16-17 digits.
> > >
> > > What is the origin of such a number and what do you want to do
with
it?
> > >
> > > You will have to write all of your own arithmetic or find a
package
> > > designed to work with large numbers with high precision.
> > >
> > > There are probably ways to deal with this but ordinary float or
double
> > > will not do it even in JVM. You may get one test to work but there
is no
> > > assurance that with a different sequence of operations with
different
> > > numbers you will not get a different result since the hardware is
> > > throwing away the extra precision.
> > >
> > > Ron
> > >
> > > elibol wrote:
> > > > Thank you Jim.
> > > >
> > > > To clarify the problem we are discussing, when a string is
parsed
into a
> > > > number, and the string is representing a very large number, the
number
> > > > does
> > > > not yield the expected results when used in an operation.
This is
> > > > demonstrated in the first modulo experiment. This issue does not
exist
> > > in
> > > > AVM1 or JVM.
> > > >
> > > > "From previous data packing experiments, I've found that the
last
nibble
> > > > (4 bits) of a 64-bit Number isn't reliable when you're
casting to
and
> > > > from Numbers (e.g . reading 8 bytes out of a ByteArray into a
Number or
> > > > doing round-trips via the toString and parseFloat methods). I'm
not
> > > > sure why this is the case--perhaps someone from Adobe can reply
and
> > > > speak to this particular issue."
> > > >
> > > > This seems relevant, as 6.3e+51 would require an allocation of 3
64 bit
> > > > Numbers (approx. 173) to be represented, using at least 2
sets of
those
> > > 4
> > > > unreliable bits you've mentioned. Is this correct?
> > > >
> > > > Is there a solution/technique for correctly representing such
parsed
> > > > Numbers? The subject Number will be concerned with properly
> > > > representing its
> > > > value in order to be used in any operation supported by as3.
> > > >
> > > > Is it impossible to write a parseFloat function that would
correctly
> > > > parse
> > > > Numbers under the new Number specification?
> > > >
> > > > Thank you Fumio and Jim.
> > > >
> > > > Note: I posted this 2 days ago and I didn't notice that I got an
> > > > Undeliverable error. I've been getting these a lot. Not sure
what
the
> > > > deal
> > > > is...
> > > >
> > > > On 3/7/07, elibol <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> To clarify the problem we are discussing, when a string is
parsed
into
> > > a
> > > >> number, and the string is representing a very large number, the
> > > >> number does
> > > >> not yield the expected results when used in an operation.
This is
> > > >> demonstrated in the first modulo experiment. This issue does
not
> > > >> exist in
> > > >> AVM1 or JVM.
> > > >>
> > > >> On 3/7/07, elibol <[EMAIL PROTECTED]> wrote:
> > > >> >
> > > >> > Thank you Jim.
> > > >> >
> > > >> > "From previous data packing experiments, I've found that the
last
> > > >> nibble
> > > >> > (4 bits) of a 64-bit Number isn't reliable when you're
casting
to and
> > > >> > from Numbers (e.g . reading 8 bytes out of a ByteArray into a
> > > >> Number or
> > > >> > doing round-trips via the toString and parseFloat
methods). I'm not
> > > >> > sure why this is the case--perhaps someone from Adobe can
reply
and
> > > >> > speak to this particular issue."
> > > >> >
> > > >> > This seems relevant, as 6.3e+51 would require an
allocation of
3 64
> > > >> bit
> > > >> > Numbers (approx. 173) to be represented, using at least 2
sets
of
> > > >> those 4
> > > >> > unreliable bits you've mentioned. Is this correct?
> > > >> >
> > > >> > Is there a solution/technique for correctly representing such
parsed
> > > >> > Numbers? The subject Number will be concerned with properly
> > > >> representing its
> > > >> > value in order to be used in any operation supported by as3.
> > > >> >
> > > >> > Is it impossible to write a parseFloat function that would
correctly
> > > >> > parse Numbers under this specification?
> > > >> >
> > > >> > Thank you Fumio and Jim.
> > > >> >
> > > >> > On 3/6/07, Jim Cheng <[EMAIL PROTECTED]> wrote:
> > > >> > >
> > > >> > > Fumio Nonaka wrote:
> > > >> > > > 2 floating point numbers are NOT "close enough". That IS
the
> > > >> > > problem.
> > > >> > > >
> > > >> > > > var _str:String = "1.2e+51";
> > > >> > > > var n:Number = parseFloat(_str);
> > > >> > > > trace(( n-1.2e+51 ) >
100000000000000000000000000000000000); //
> > > >> > > true
> > > >> > >
> > > >> > > In ActionScript 3, the native Number data type is
internally
> > > >> > > represented
> > > >> > > as a IEEE-754 double-precision floating-point number.
Due to
the
> > > >> way
> > > >> > > that the IEEE-754 standard defines how the bits are used to
> > > >> represent
> > > >> > > the number, the accuracy of the mantissa precision
(always 52
> > > >> bits, or
> > > >> > > 16 decimal digits) changes depending on the exponent
(always
11
> > > >> bits).
> > > >> > >
> > > >> > > See: http://en.wikipedia.org/wiki/IEEE_754
> > > >> > >
> > > >> > > This is to say, the "close enough" value that you need to
compare
> > > >> the
> > > >> > > absolute difference between the two Numbers scales in
magnitude
> > > with
> > > >> > > the
> > > >> > > exponent. This can be particularly bad if you need
arbitrary
> > > >> > > precision,
> > > >> > > (e.g. when doing financial or scientific calcuations), as
while
> > > >> > > 1.32e+36
> > > >> > > is paltry compared to 1.2e+51, no one would want to be
swindled
> > > >> out of
> > > >> > > 1.32e+36 dollars due to faulty floating point comparisons,
hence
> > > the
> > > >> > > need for arbitrary precision integer libraries for such
> > > applications
> > > >> > > as
> > > >> > > was recently mentioned on this list.
> > > >> > >
> > > >> > > Fortunately however, if you don't need this kind of exact
> > > precision,
> > > >> > > but
> > > >> > > simply need to match large values originally parsed from
strings to
> > > >> > > Numbers as per your example, there is a much better and
easier
> > > >> way to
> > > >> > > compare very large Numbers in ActionScript 3--by inspecting
them at
> > > >> > > the
> > > >> > > bit level following the IEEE-754 specification.
> > > >> > >
> > > >> > > From previous data packing experiments, I've found that the
last
> > > >> > > nibble
> > > >> > > (4 bits) of a 64-bit Number isn't reliable when you're
casting to
> > > >> and
> > > >> > > from Numbers (e.g. reading 8 bytes out of a ByteArray
into a
> > > >> Number or
> > > >> > > doing round-trips via the toString and parseFloat
methods). I'm
> > > not
> > > >> > > sure why this is the case--perhaps someone from Adobe can
reply and
> > > >> > > speak to this particular issue.
> > > >> > >
> > > >> > > That being said, all you really need to do for a
nearly-equals
> > > >> Number
> > > >> > > comparison is a byte-by-byte comparison save for the last
byte, in
> > > >> > > which
> > > >> > > case you only compare the four most significant bits.
If all
bits
> > > >> > > aside
> > > >> > > from the last nibble match, the Numbers are close enough.
> > > >> > >
> > > >> > > Here's how I do it:
> > > >> > >
> > > >> > > <code>
> > > >> > >
> > > >> > > /**
> > > >> > > * Compare two ActionScript 3 Numbers for near-equality.
> > > >> > > *
> > > >> > > * @param The first Number
> > > >> > > * @param The second Number
> > > >> > > *
> > > >> > > * @return True on near-equality, false otherwise.
> > > >> > > */
> > > >> > > public function closeEnough(a:Number, b:Number):Boolean {
> > > >> > > var ba:ByteArray, i:uint;
> > > >> > > if (a == b) {
> > > >> > > // A is explicitly equal to B
> > > >> > > return true;
> > > >> > > }
> > > >> > > else {
> > > >> > > // A isn't exactly equal to B, so we need to
> > > >> > > // check the Numbers' bytes one byte at a time.
> > > >> > > ba = new ByteArray();
> > > >> > > ba.writeDouble(a);
> > > >> > > ba.writeDouble(b);
> > > >> > >
> > > >> > > // If any of the first 7 bytes differ, then
> > > >> > > // the two values are not close enough.
> > > >> > > for (i = 0; i < 7; i++) {
> > > >> > > if (ba[i] != ba[i + 8]) {
> > > >> > > return false;
> > > >> > > }
> > > >> > > }
> > > >> > >
> > > >> > > // Mask the last four bits out and compare the
> > > >> > > // last byte. If they match, the Numbers are
> > > >> > > // close enough. The last nibble tends not to
> > > >> > > // be reliable enough for comparison, so we
> > > >> > > // allow these to differ and the two Numbers
> > > >> > > // still be considered close enough.
> > > >> > > if ((ba[7] & 0xf0) != (ba[15] & 0xf0)) {
> > > >> > > return false;
> > > >> > > }
> > > >> > > }
> > > >> > > return true;
> > > >> > > }
> > > >> > >
> > > >> > > </code>
> > > >> > >
> > > >> > > Jim Cheng
> > > >> > > effectiveUI
> > > >> > > _______________________________________________
> > > >> > > [email protected]
> > > >> > > To change your subscription options or search the archive:
> > > >> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >> > >
> > > >> > > Brought to you by Fig Leaf Software
> > > >> > > Premier Authorized Adobe Consulting and Training
> > > >> > > http://www.figleaf.com
> > > >> > > http://training.figleaf.com
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> > > > _______________________________________________
> > > > [email protected]
> > > > To change your subscription options or search the archive:
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >
> > > > Brought to you by Fig Leaf Software
> > > > Premier Authorized Adobe Consulting and Training
> > > > http://www.figleaf.com
> > > > http://training.figleaf.com
> > > >
> > > >
> > > _______________________________________________
> > > [email protected]
> > > To change your subscription options or search the archive:
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > > Brought to you by Fig Leaf Software
> > > Premier Authorized Adobe Consulting and Training
> > > http://www.figleaf.com
> > > http://training.figleaf.com
> > >
> > _______________________________________________
> > [email protected]
> > To change your subscription options or search the archive:
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> > Brought to you by Fig Leaf Software
> > Premier Authorized Adobe Consulting and Training
> > http://www.figleaf.com
> > http://training.figleaf.com
> >
>
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
