How to check whether parseFloat leads to missing precision

you are right there are a number of cases where the example function does not work. Also it would not have been appropriate given @drkamaleon's use case focusing on performance (why not directly using GMP's mpf_t?). The code you shared is very interesting, the link that is there

How to check whether parseFloat leads to missing precision

the code shouldn't work, for once if you just strip the decimal point you can get such a big integer value that converted to double it will probably be Inf. Ignoring those cases, I think a decimal number without the decimal point might fit or fit not a double, but then not fit or fit exactly wit

How to check whether parseFloat leads to missing precision

I know it's about `float`s. I'm just mentioning `parseFloat` since I'm kind-of trying to make it behave as `parseInt` and throw an Overflow error if that is the case. Basically, I'm working on Arturo and - given a weird error I've noticed - I'm trying to handle floating-point numbers/literals i

How to check whether parseFloat leads to missing precision

it is not really a limit of `parseFloat`, it is a limit of `float`, which is not made for arbitrary long decimal numbers. In particular echo 12312.12123123456786708789878987123812739182739182739182739812739128739182731923 # outputs 12312.12123123457 Run One way to

How to check whether parseFloat leads to missing precision

I've been experimenting with parseFloat and I guess I'm already hitting its limits: parseFloat("12312.12") # => 12312.12 parseFloat("12312.12123123456786708789878987123812739182739182739182739812739128739182731923") # => 12312.12123123457 Run How would you go abo