JavaScript represents all its numbers, by default, with a 64-bit binary floating-point number type.

The link you offer supports this statement because it says that we can represent integers exactly up to 2^53, which is what happens under the IEEE binary64 type.

Is there any work on replacing the functions for this in the language’s respective standard libraries? The Rust implementation seems like it would be a good fit for the Rust standard library, with it having no dependencies and no_std support.

Is there any work on replacing the functions for this in the language’s respective standard libraries?

It is part of Go as of the latest version.

Suminda Sirinath Salpitikorala Dharmasenasays:

I would like to help out on the Java port but I my requirement is that I can go round trip without having different cache table for float/double to string and string to float/double.

We provide exact parsing with round-to-even so “round trip” is not a concern. I have not worked on serialization.

Frank Astiersays:

But, when I have to store e.g. a big matrix of floating point numbers, I would do a copy of that contiguous chunk of memory to disk, and vice-versa, possibly throwing in mmap – precisely to avoid parsing from text?

Right. If you serialize your numbers in binary form, you obviously have no parsing difficulty. In the paper, I also allude to another possibility: you can use hexadecimal floating-point numbers.

What do you feel accounts for the great differences in bandwidth used by each approach? It would be interesting to test these same computations on multiple different CPUs.

I made my own floating point input/output method (https://reddit.com/r/fpio) How does the performance of r/fpio compare to your benchmark?

My name when spreading silly questionssays:

hello, nice work, but I’m unsure about one point:
the video title reads ‘w/Perfect Accuracy’, but in the end you state:
‘can do exact computation 99,99% of the time’, doe’s that mean:
‘in 0.01% of time ( cases ) you see an error and can fall back to other algorithm’, or
‘in 0.01% of cases you get a slightly wrong result, learn to live with it’?

Idiotsays:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER

JavaScript is not 64-bit

Daniel Lemiresays:@Idiot

My statement is…

The link you offer supports this statement because it says that we can represent integers exactly up to 2^53, which is what happens under the IEEE binary64 type.

Daniel Lemiresays:@Idiot

The link you offer does confirm my statement, please check.

Alice Ryhlsays:Is there any work on replacing the functions for this in the language’s respective standard libraries? The Rust implementation seems like it would be a good fit for the Rust standard library, with it having no dependencies and

`no_std`

support.Daniel Lemiresays:Is there any work on replacing the functions for this in the language’s respective standard libraries?It is part of Go as of the latest version.

Suminda Sirinath Salpitikorala Dharmasenasays:I would like to help out on the Java port but I my requirement is that I can go round trip without having different cache table for float/double to string and string to float/double.

At the moment I am trying to port a DragonBox version (https://github.com/jk-jeon/dragonbox/, https://github.com/jk-jeon/fp/, https://github.com/abolz/Drachennest/) but I am interested in this if it can outperform DragonBox and can go round trip (float/double to string, string to float/double).

Daniel Lemiresays:We provide exact parsing with round-to-even so “round trip” is not a concern. I have not worked on serialization.

Frank Astiersays:But, when I have to store e.g. a big matrix of floating point numbers, I would do a copy of that contiguous chunk of memory to disk, and vice-versa, possibly throwing in mmap – precisely to avoid parsing from text?

Daniel Lemiresays:Right. If you serialize your numbers in binary form, you obviously have no parsing difficulty. In the paper, I also allude to another possibility: you can use hexadecimal floating-point numbers.

Bret Bernhoftsays:What do you feel accounts for the great differences in bandwidth used by each approach? It would be interesting to test these same computations on multiple different CPUs.

Daniel Lemiresays:The paper does cover different CPUs.

Piotr Grochowskisays:I made my own floating point input/output method (https://reddit.com/r/fpio) How does the performance of r/fpio compare to your benchmark?

My name when spreading silly questionssays:hello, nice work, but I’m unsure about one point:

the video title reads ‘w/Perfect Accuracy’, but in the end you state:

‘can do exact computation 99,99% of the time’, doe’s that mean:

‘in 0.01% of time ( cases ) you see an error and can fall back to other algorithm’, or

‘in 0.01% of cases you get a slightly wrong result, learn to live with it’?

Daniel Lemiresays:It is the former: we fallback if needed.

My name when spreading silly questionssays:🙂 thank you,