Re: [Dynapi-Dev] Browser limitations of big integers.

[Andrew G. <an...@dy...>]

According to the ECMAScript specification, numbers are stored in IEEE 
754 floating point format (52-bit fraction, 11-bit biased exponent, and 
a 1-bit sign).
The language does not support integers at all, so there is no chance of 
representing a 64 bit integer.
The number you got (9007199254740992) is near enough to 2^53, which is 
about what you should expect.

Andrew


Leif W wrote:

> Hello,
>
> I don't know if anyone has followed the bug report for 1232705.  An 
> issue is raised about big integer support.  For the purposes of this 
> context, big integers shall be anything bigger than 32-bits, either 
> signed or unsigned, and may herein be expressed in either hex or 
> decimal (preferably both).
>
> The biggest/smallest integer I can get in Mozilla Firefox on WinXP 32 
> is +/- hex 20 0000 0000 0000 or dec 9007199254740992.  I have not 
> tested in Linux yet.  Can anyone on other OSes or browsers get bigger 
> or smaller numbers?  I wrote a simply JavaScript to help, and attached 
> it to the bug report.
>
> The JavaScript page merely has some buttons with predefined numbers, 
> an input field, a parse button, and an output field.  The "parse" 
> button takes the string representation in the input text field, passes 
> it to parseInt to make an integer.  Then it assigns that integer to 
> the value of the output text field, which implicitly converts back to 
> a string. The strings expect decimal only at this point.  I could do 
> bin2hex and hex2bin later.
>
> The strings should be the same.  I haven't got an algorithm to do this 
> automatically.  I did it manually.  I just started with all 9s, (9, 
> 99, 999, and so on) until the results differed.  Then I reduced the 
> first 9 to 1, and the rest of the 9s to 0s.  Then I increased the last 
> digit from 0 through 9 to ensure they were all the same.  If it's the 
> same, go half way up, else go half way down on the most significant 
> digit until you isolate the highest you can make it.  For example, 
> take the first digit from 1 to 5, and the last from 0-9.  If it' the 
> same, take the first up to 7, last 0-9.  I found that sometimes the 
> number would (seemingly at random) match and then differ with the last 
> digit changes. If this happens, it's considered an overflow 
> somewhere.  Usually the overflow caused the least significant digit(s) 
> to go to 0.  But sometimes it would make odds round down to evens, 
> usually 2 or 0 though.
>
> It's hard to explain.  If you come up with a good algorithm, let me 
> know.  I think it would be handy to have a quick, automatic way of 
> determining your browser's math limits.  Either way, if you've got 
> about 5-10 minutes to kill, please test this.  You can easily start 
> off where I was to save time.  A dec <-> hex converter might be handy, 
> so if it might be useful, I'll include later.  The odd looking decimal 
> number held little meaning for me until I converted it to hex and was 
> surprised to find a pretty number, which I don't believe is 
> coincidence.  :p  It's probably a C #define in some header file of 
> some math library in Mozilla.  Simply making it bigger and recompiling 
> might work locally, but does nothing for the default installs out 
> there.  Maybe there's an archaic way to change it in some browser 
> config file.  But I kind of doubt that.
>
> Leif
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted 
> by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>
>