Re: [Flashcoders] AS3 parseFloat issue?

[Ron Wheeler]

elibol wrote:

Mr. Wheeler,

""up to 1.0e+63" says nothing about precision. This is the
exponent it deals with magnitude not precision. Precision is
determined by the mantisa." 

 
Thank you for correcting me, I respect and honor your knowledge, but 
this statement doe not help me at all. I still don't know why 
parseFloat in as3 fails where other languages succeed. The Java Double 
and the AS3 Number are documented to have the same # of bits for the 
exponent. Why does the parsing algorithm for these numbers return 
different results?
Because of the way the algorithms are coded. Within the specification of 
floating point numbers both are correct. You can not have more than 16 
meaningful digits in the whole number. You can put lots of zeros before 
and after to make very big numbers or very small numbers.
10010 and 10014 are the same double precision 
number. The hardware can not represent any difference
I have a lot of reading to do. There are a lot of details that I need 
in order to have a good grasp on the idea.


I found this particularly helpful:
http://people.uncw.edu/tompkinsj/133/Numbers/Reals.htm#applet

I certainly need a better idea of floating point numbers in general, 
but I don't think the basic idea will give me the answer to this 
question. It's as if I have to know how different data types store all 
kinds of numbers on the binary level. I then need to understand how 
storage affects the parsing process. I will have to know and 
understand the parsing algorithms.


You got it. If you are going to try to exceed the spec, you have to 
understand what is happening.

You need to understand what "equality" means in floating point.
You must never compare 2 floating point numbers for equality. You can 
only get "close enough".
It has been that way for almost 60 years now and you and I are not going 
to change it.
If you really need to do arithmetic on very big or very small numbers 
with high precision, you have to use data types that support that or 
write your own. This was mentioned in an early part of this thread. That 
is what astronomers and nuclear physicists have to do.
ATM, I am on the verge of understanding why some base 10 numbers 
cannot be represented in base 2. I've wondered about the mechanism for 
representing fractions in different bases. I think representing 
fractions in base 2 will finally allow me to abstract this concept. 
It's something I've been pondering for some time now...



All base 10 numbers can be represented up to some level of precision.
Why can't 1/3 be represented in Base 10?

I think that you will get this figured out but I am afraid that we have 
lost sight of your original need.


Ron


Thank you,

Melih

On 3/13/07, *Ron Wheeler* < [EMAIL PROTECTED] 
> wrote:




elibol wrote:
> Your example uses a machine which solves to a working precision.
>
> If I were to do that problem by hand, 100/3 would be 100 over 3, and
> when multiplied by 3, it would be 100.
Show the intermediate storage of 100/3 in writing. You are making
a leap
("I see a string of 3s as far as the eye can see, so I can assume that
it goes on forever") that a computer is not able to do since the can
only see to end of its mantissa and is not supposed to make guesses
about how the number might turn out if only it had more places to
store
the least significant digits.
>
> I understand working precision, and floating point arithmetic,
> however, I don't understand how the parsing algorithms differ,
> specifically, why parseDouble has greater precision than AS3
> parseFloat, and why AS1 parseFloat (up to 1.0e+63) even has greater
> precision than AS3 parseFloat.
>
"up to 1.0e+63" says nothing about precision. This is the exponent it
deals with magnitude not precision. Precision is determined by the
mantisa.


The maximum exponent allowed is determined by the hardware as is the
number of bits in the mantissa.. There are some general statements
about
what float can stand and what double can handle but no one makes any
promises about the last few bits of the mantissa.

From Wikipedia http://en.wikipedia.org/wiki/Floating_point
The arithmetical distance between two consecutive representable
floating
point numbers is called an "ULP", for Unit in the Last Place. For
example, the numbers represented by 45670123 and 45670124
hexadecimal is
one ULP. An ULP is about 10^-7 in single precision, and 10^-16 in
double
precision. The mandated behavior of IEEE-compliant hardware is
that the
result be within one-half of an ULP.

This tells you exactly what is supposed to happen - 7 digits of
information in floating point and 16 in double
and the last bit can be off by 1/2.

If you look carefully at your previous examples, you will see that
the
differences that are botheri

Re: [Flashcoders] AS3 parseFloat issue?

[Ron Wheeler]

elibol wrote:
Hmm, I understand how the first operand does not represent the parsed 
string

in:

trace(6.30e+51 == 6.3e+51);

And how what trace prints is just the string representation of the 
number...


I guess the point of the final experiment is that the solution is to 
parse

the float without the exponent, because the string will always be human
input, so the number would always be whatever float to the +- exponent.

Here is the Java double:

http://people.uncw.edu/tompkinsj/133/Numbers/Reals.htm

Shouldn't this make the as3 Number equal to the Java Double? Both are
represented using the IEEE 754 standard.

In Java, doubles are parsed and represented exactly up to 1.0e+308. This
goes up to the largest value the language can handle.

In as3, Numbers lose precision at about 1.0e+32.
Numbers lose precision when bits are generated in the mantissa that go 
past the number of bits available in the hardware.
The exponent has nothing to do with it. It is simply stored as a byte at 
the front of the word.


If you do some math by hand on a calculator with 2 decimal points
100/3 = 33.33  which when multiplied by 3 is only 99.99 so arithmetic 
does not work in real life


100 times 4 divided by 3 is not the same as 100 divided by 3 times 4 
100*4=400/3=133.33

100/3=33.33*4=133.32
Submit a bug report to God.



Would it make sense to build a parseDouble function for as3? Could 
that be

the problem?

Do I have to do some more reading? I think so.

kk,

thank you Ron and Andy.

On 3/9/07, Andy Herrman <[EMAIL PROTECTED]> wrote:


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.3005123412, 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.30e+51
> trace(n2);//6.3e+51
> trace(6.30e+51 == 6.3e+51);//true
>
> However, n1 != 6.30e+51.
>
> 6.30e+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.30e+51
> > trace(n2);//6.3e+51
> > trace(6.30e+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 pre

Re: [Flashcoders] AS3 parseFloat issue?

[Ron Wheeler]

elibol 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.


By now, you should be pretty clear about why this does not work.


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.30e+51
trace(n2);//6.3e+51
trace(6.30e+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 f

Re: [Flashcoders] AS3 parseFloat issue?

[elibol]

Hmm, I understand how the first operand does not represent the parsed string
in:

trace(6.30e+51 == 6.3e+51);

And how what trace prints is just the string representation of the number...

I guess the point of the final experiment is that the solution is to parse
the float without the exponent, because the string will always be human
input, so the number would always be whatever float to the +- exponent.

Here is the Java double:

http://people.uncw.edu/tompkinsj/133/Numbers/Reals.htm

Shouldn't this make the as3 Number equal to the Java Double? Both are
represented using the IEEE 754 standard.

In Java, doubles are parsed and represented exactly up to 1.0e+308. This
goes up to the largest value the language can handle.

In as3, Numbers lose precision at about 1.0e+32.

Would it make sense to build a parseDouble function for as3? Could that be
the problem?

Do I have to do some more reading? I think so.

kk,

thank you Ron and Andy.

On 3/9/07, Andy Herrman <[EMAIL PROTECTED]> wrote:


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.3005123412, 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.30e+51
> trace(n2);//6.3e+51
> trace(6.30e+51 == 6.3e+51);//true
>
> However, n1 != 6.30e+51.
>
> 6.30e+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.30e+51
> > trace(n2);//6.3e+51
> > trace(6.30e+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 ver

Re: [Flashcoders] AS3 parseFloat issue?

[Andy Herrman]

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.3005123412, 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.30e+51
trace(n2);//6.3e+51
trace(6.30e+51 == 6.3e+51);//true

However, n1 != 6.30e+51.

6.30e+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.30e+51
> trace(n2);//6.3e+51
> trace(6.30e+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 corre

Re: [Flashcoders] AS3 parseFloat issue?

[Andy Herrman]

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.30e+51
trace(n2);//6.3e+51
trace(6.30e+51 == 6.3e+51);//true

However, n1 != 6.30e+51.

6.30e+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.30e+51
trace(n2);//6.3e+51
trace(6.30e+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 operatio

Re: [Flashcoders] AS3 parseFloat issue?

[elibol]

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.30e+51
trace(n2);//6.3e+51
trace(6.30e+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 =

Re: [Flashcoders] AS3 parseFloat issue?

[Ron Wheeler]

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 ) > 1000);  //
> > 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 orig

Re: [Flashcoders] AS3 parseFloat issue?

[elibol]

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 ) > 1000);  //
> > 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 

Re: [Flashcoders] AS3 parseFloat issue?

[Jim Cheng]

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) > 1000);  // 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:



/**
 * 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;
}



Jim Cheng
effectiveUI
___
Flashcoders@chattyfig.figleaf.com
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

Re: [Flashcoders] AS3 parseFloat issue?

[Fumio Nonaka]

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) > 1000);  // true
_
Ron Wheeler wrote:
If you want to know that 2 floating point numbers are "close enough" to 
be considered as the same value, then subtract them and check to see if 
the absolute value of their difference is less than your criteria for 
"sameness".



elibol wrote:

I came to this specific value from 6.3e51. Here are some more tests:

var test1_str:String = "6.3e51"; //6.3e+51 outputs same result.
var n1:Number = parseFloat(test1_str);



trace(n1-(6.3e51));

//AS3



1.32922799578491e+36



On 3/5/07, Fumio Nonaka <[EMAIL PROTECTED]> wrote:

I am not sure whether it is a bug or by design, though.

var test0_str:String = "6.30e+51";
var n0:Number = parseFloat(test0_str);



trace(n0-(6.30e+51));
// ActionScript 3.0



1.32922799578491e+36
// ActionScrpt 2.0



0


Good luck,
--
Fumio Nonaka
mailto:[EMAIL PROTECTED]
http://www.FumioNonaka.com/
My books
Flash community

___
Flashcoders@chattyfig.figleaf.com
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

Re: [Flashcoders] AS3 parseFloat issue?

[Ron Wheeler]

Since the dawn of computing in the 1950s, it has clearly been understood 
that

"Thou shalt not compare floating point numbers for equality"

It is not supposed to work.

It only rarely does work(every now and again you will get lucky 
depending on the number that you chose to test). If you change hardware 
architecture or change the implementation of some parsing or 
manipulation your code will change behaviour - not very desirable.


It is not a bug.

You should not do it.

If you want to know that 2 floating point numbers are "close enough" to 
be considered as the same value, then subtract them and check to see if 
the absolute value of their difference is less than your criteria for 
"sameness".
That has been the correct way to compare floating point numbers for 
about 50 years and until we stop using binary components to build 
computers, it will persist.


Ron

elibol wrote:

I came to this specific value from 6.3e51. Here are some more tests:

var test1_str:String = "6.3e51"; //6.3e+51 outputs same result.
var n1:Number = parseFloat(test1_str);
trace(n1);
trace(n1 == (6.3e51));
trace(6.30e+51 == 6.3e+51);
trace(n1-(6.3e51));

//AS3
6.30e+51
false
true
1.32922799578491e+36

It may certainly be by design, but aren't these unexpected results? 
as2 and

java do not behave this way. The parseFloat function is flawed.

I will post a comment on livedocs, and I've submitted the issue as a 
bug at

http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

I am not going over board am I? I just need my program to work correctly.

On 3/5/07, Fumio Nonaka <[EMAIL PROTECTED]> wrote:


I am not sure whether it is a bug or by design, though.

var test0_str:String = "6.30e+51";
var n0:Number = parseFloat(test0_str);
trace(n0);
trace(n0 == (6.30e+51));
trace(n0-(6.30e+51));
// ActionScript 3.0
6.30e+51
false
1.32922799578491e+36
// ActionScrpt 2.0
6.3e+51
true
0

Decrease one digit:

var test1_str:String = "6.3e+51";
var n1:Number = parseFloat(test1_str);
trace(n1 == (6.3e+51));
trace(n1-(6.3e+51));
// ActionScript 3.0
true
0
_
elibol wrote:
> Those who are interested in helping me verify the problem can run this
test
> in actionscript 2.0 and again in actionscript 3.0.
>
> var a:String = "6.30e+51";
> var b:String = "23";
> var c:Number = parseFloat(a)%parseFloat(b);
> trace(c); //outputs 7 in as3, and 18 in as2
> trace(6.30e+51%23); // outputs 18 in both as2 and 3

Good luck,
--
Fumio Nonaka
mailto:[EMAIL PROTECTED]
http://www.FumioNonaka.com/
My books
Flash community

___
Flashcoders@chattyfig.figleaf.com
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


___
Flashcoders@chattyfig.figleaf.com
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



___
Flashcoders@chattyfig.figleaf.com
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

Re: [Flashcoders] AS3 parseFloat issue?

[elibol]

I came to this specific value from 6.3e51. Here are some more tests:

var test1_str:String = "6.3e51"; //6.3e+51 outputs same result.
var n1:Number = parseFloat(test1_str);
trace(n1);
trace(n1 == (6.3e51));
trace(6.30e+51 == 6.3e+51);
trace(n1-(6.3e51));

//AS3
6.30e+51
false
true
1.32922799578491e+36

It may certainly be by design, but aren't these unexpected results? as2 and
java do not behave this way. The parseFloat function is flawed.

I will post a comment on livedocs, and I've submitted the issue as a bug at
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

I am not going over board am I? I just need my program to work correctly.

On 3/5/07, Fumio Nonaka <[EMAIL PROTECTED]> wrote:


I am not sure whether it is a bug or by design, though.

var test0_str:String = "6.30e+51";
var n0:Number = parseFloat(test0_str);
trace(n0);
trace(n0 == (6.30e+51));
trace(n0-(6.30e+51));
// ActionScript 3.0
6.30e+51
false
1.32922799578491e+36
// ActionScrpt 2.0
6.3e+51
true
0

Decrease one digit:

var test1_str:String = "6.3e+51";
var n1:Number = parseFloat(test1_str);
trace(n1 == (6.3e+51));
trace(n1-(6.3e+51));
// ActionScript 3.0
true
0
_
elibol wrote:
> Those who are interested in helping me verify the problem can run this
test
> in actionscript 2.0 and again in actionscript 3.0.
>
> var a:String = "6.30e+51";
> var b:String = "23";
> var c:Number = parseFloat(a)%parseFloat(b);
> trace(c); //outputs 7 in as3, and 18 in as2
> trace(6.30e+51%23); // outputs 18 in both as2 and 3

Good luck,
--
Fumio Nonaka
mailto:[EMAIL PROTECTED]
http://www.FumioNonaka.com/
My books
Flash community

___
Flashcoders@chattyfig.figleaf.com
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


___
Flashcoders@chattyfig.figleaf.com
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

Re: [Flashcoders] AS3 parseFloat issue?

[Fumio Nonaka]

I am not sure whether it is a bug or by design, though.

var test0_str:String = "6.30e+51";
var n0:Number = parseFloat(test0_str);
trace(n0);
trace(n0 == (6.30e+51));
trace(n0-(6.30e+51));
// ActionScript 3.0
6.30e+51
false
1.32922799578491e+36
// ActionScrpt 2.0
6.3e+51
true
0

Decrease one digit:

var test1_str:String = "6.3e+51";
var n1:Number = parseFloat(test1_str);
trace(n1 == (6.3e+51));
trace(n1-(6.3e+51));
// ActionScript 3.0
true
0
_
elibol wrote:

Those who are interested in helping me verify the problem can run this test
in actionscript 2.0 and again in actionscript 3.0.

var a:String = "6.30e+51";
var b:String = "23";
var c:Number = parseFloat(a)%parseFloat(b);
trace(c); //outputs 7 in as3, and 18 in as2
trace(6.30e+51%23); // outputs 18 in both as2 and 3


Good luck,
--
Fumio Nonaka
mailto:[EMAIL PROTECTED]
http://www.FumioNonaka.com/
My books
Flash community

___
Flashcoders@chattyfig.figleaf.com
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

[Flashcoders] AS3 parseFloat issue?

[elibol]

Hi guys,

I've been writing some code that evaluates operations from strings, and when
doing some stress testing, I think I may have discovered a problem.

Those who are interested in helping me verify the problem can run this test
in actionscript 2.0 and again in actionscript 3.0.

var a:String = "6.30e+51";
var b:String = "23";
var c:Number = parseFloat(a)%parseFloat(b);
trace(c); //outputs 7 in as3, and 18 in as2
trace(6.30e+51%23); // outputs 18 in both as2 and 3

Here is the test I ran in Java, just to confirm:

String a = "6.30e+51";
String b = "23";
double c = Double.parseDouble (a)%Double.parseDouble(b);
System.out.println(c); //18
System.out.println(6.30e+51%23); //18

Clearly, the answer to this problem is 18, but as3 calculates 7 after
parsing the large number.

I feel reluctant to draw any wild conclusions, I mean, I have no idea what
the problem could be. Anyone have any clue? Is this an issue or am I missing
something?

Good day,

Melih
___
Flashcoders@chattyfig.figleaf.com
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