7

Is there a way to represent a number with higher than 53-bit precision in JavaScript? In other words, is there a way to represent 64-bit precision number?

I am trying to implement some logic in which each bit of a 64-bit number represents something. I lose the lower significant bits when I try to set bits higher than 2^53.

Math.pow(2,53) + Math.pow(2,0) == Math.pow(2,53)

Is there a way to implement a custom library or something to achieve this?

hippietrail
  • 15,848
  • 18
  • 99
  • 158
  • Some special reason you can't split it into two variables or use a string or an array instead? – some Feb 03 '09 at 08:40
  • Splitting it into 2 variables is the solution that I see now. string and array seems to be inefficient, because I would be using only few out of the 64 bits. Thanks. –  Feb 03 '09 at 23:08

7 Answers7

1

Google's Closure library has goog.math.Long for this purpose.

Jeremy Condit
  • 6,766
  • 1
  • 28
  • 30
  • The guy who wrote the ProtoBuf JavaScript code also isolated Long from the Closure library so you can use it standalone: https://github.com/dcodeIO/Long.js – SomeCallMeTim Jul 26 '15 at 23:31
0

The GWT team have added a long emulation support so java longs really hold 64 bits. Do you want 64 bit floats or whole numbers ?

mP.
  • 18,002
  • 10
  • 71
  • 105
0

I'd just use either an array of integers or a string.

The numbers in javascript are doubles, I think there is a rounding error involved in your equation.

Georg Schölly
  • 124,188
  • 49
  • 220
  • 267
  • I think arrays and string would be an inefficient datastructure here. Because I would be using only few of the 64 bits. Currently I am thinking of using 2 numeric types for higher 32 and lower 32 bits. Thanks –  Feb 03 '09 at 22:26
  • The problem is you can't rely on a double to be consistent if you try to do bit-manipulation. Javascript isn't made for manipulating data on the bit-layer. – Georg Schölly Feb 03 '09 at 22:54
  • Totally get your point. I am an expert on javascript or floating point numeric, is there a datatype in js which uses fixed point arithmetic? –  Feb 03 '09 at 23:02
  • No, it's sad but true. :( But for a normal web application it's just not needed. – Georg Schölly Feb 04 '09 at 00:34
0

Perhaps I should have added some technical detail. Basically the GWT long emulation uses a tuple of two numbers, the first holding the high 32 bits and the second the low 32 bits of the 64 bit long.

The library of course contains methods to add stuff like adding two "longs" and getting a "long" result. Within your GWT Java code it just looks like two regular longs - one doesn't need to fiddle or be aware of the tuple. By using this approach GWT avoids the problem you're probably alluding to, namely "longs" dropping the lower bits of precision which isn't acceptable in many cases.

Whilst floats are by definition imprecise / approximations of a value, a whole number like a long isn't. GWT always holds a 64 bit long - maths using such longs never use precision. The exception to this is overflows but that accurately matches what occurs in Java etc when you add two very large long values which require more than 64 bits - eg 2^32-1 + 2^32-1.

To do the same for floating point numbers will require a similar approach. You will need to have a library that uses a tuple.

hippietrail
  • 15,848
  • 18
  • 99
  • 158
mP.
  • 18,002
  • 10
  • 71
  • 105
0

The following code might work for you; I haven't tested it however yet: BigDecimal for JavaScript

Tim Parenti
  • 511
  • 7
  • 26
Schalk Versteeg
  • 1,057
  • 13
  • 23
-1

Yes, 11 bit are reserved for exponent, only 52 bits containt value also called fraction. Javascript allows bitwise operations on numbers but only first 32 bits are used in those operations according to Javascript standard specification.

I do not understand misleading GWT/Java/long answers in Javascript/double question though? Javascript is not Java.

exebook
  • 32,014
  • 33
  • 141
  • 226
-7

Why would anyone need 64 bit precision in javascript ?

Longs sometimes hold ID of stuff in a DB so its important not to lose some of the lower bits... but floating point numbers are most of the time used for calculations. To use floats to hold monetary or similar exacting values is plain wrong. If you truely need 64 bit precision do the maths on the server where its faster and so on.

mP.
  • 18,002
  • 10
  • 71
  • 105
  • Answering a question with a question is never helpful. Plus, server-side JavaScript is becoming more and more common. – scotts Oct 10 '09 at 05:51
  • Because maybe just maybe the asker is doing the wrong thing, because they don't know what they are doing... – mP. Oct 10 '09 at 07:23