[dbaupp]

That problem is normal and expected behaviour for finite precision floating point: it appears with any scheme for floating point (IEEE-754 or not), as computers are finite. A significant chunk of the field of numerical analysis is about controlling the error introduced by floating point.

And, anyway, R uses IEEE-754 for 'numeric' too[0], and will do the same "fudging":

> All R platforms are required to work with values conforming to the IEC 60559 (also known as IEEE 754) standard

There's fair criticisms that JS may not offer the required control over rounding modes that R (or the C libs underlying R) provide or the necessary instructions to minimise error accumulation, but general handwavings about "fudging" of floating point don't apply: floating point is unavoidably imprecise, and R and JS even use the same basic format.

[0]: https://stat.ethz.ch/R-manual/R-devel/library/base/html/doub...

[RobertRoberts]

>...general handwavings about "fudging" of floating point don't apply...

Handwaving is all I can do, I am just the tech taking orders.

I just talked with my statistician friend on the phone, here's one issue my friend just showed me. (integer error, not even floating point)

111,111,111 * 111,111,111 = 12,345,678,987,654,321

(I did this by hand to confirm, he made me the big meany)

Excel, Libre Office, my calculator, Javascript, etc.. all get this number wrong. But with R there's a library that can add support for numbers this big. (I guess this is a well known issue)

Edit: _All_ numbers in JS are floating point numbers, there are no integers... <hmmm>

"In JavaScript, all numbers are implemented in double-precision [...] There is no specific type for integers."

Edit 2: (for fun) This is from R:

  > library(gmp)
  > bignum <- as.bigz(111111111)
  > mul.bigz(bignum, bignum)
  Big Integer ('bigz') :
  [1] 12345678987654321

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

[dbaupp]

> Handwaving is all I can do, I am just the tech taking orders.

Even "the tech" can have some understanding of finite precision integers and floats, and how they behave, given they're building blocks of the trade. It seems somewhat relevant to knowing what changes are valid to code. http://floating-point-gui.de/ is a great place to start if you're interested in learning more. :)

> Edit: _All_ numbers in JS are floating point numbers, there are no integers... <hmmm>

Not having any native integers is unfortunate and annoying, but there are various tricks to ensure numbers are integers (e.g. floats exactly represent integers up to 2^53) plus various tricks to convince the JS engines that things are guaranteed to be integers for optimizations. These are clunky and ugly hacks, but they're possible and even more possible when using JS as a compilation target from a different language (e.g. asm.js in the extreme).

> I guess this is a well known issue

Indeed, it very much is. As you demonstrate, even R doesn't allow doing your example calculation natively, you need to import a library... something that can be done just fine in JS too: for arbitrary size integers https://github.com/Yaffle/BigInteger and for arbitrary precision floats https://github.com/charto/bigfloat (among many examples). It's true that these won't approach the performance of GMP due to lack of access to the specialized instructions it uses, but they offer the same basic functionality.

That said, I agree with the general sentiment that JS is suboptimal for scientific computing, but mostly because of performance (although R's performance falls off very quickly when using anything other than vector operations) rather than inaccurate concerns about precision.

[RobertRoberts]

>Even "the tech" can have some understanding of finite precision integers and floats, and how they behave, given they're building blocks of the trade.

I do have "some understanding". But not enough to processing millions of records and notice that one or two numbers of output, out of hundreds, aren't correct. That's the PhD's job.

[dbaupp]

Concepts like finite integer sizes (aka integer overflow) and finite floating point precision (1/3+1/3+1/3 != 1) aren't PhD-level concerns. :)

[Jacobot]

...apples and oranges.... R doesn't support non IEEE standard floats, what you are basically doing is using an external library (GMP), and special functions for addition, multiplication from that package.

Nor can any of the functions in R "base" use GMP.

Again, nobody is fudging numbers, neither R, Java, C, or JS because floating point is implemented on hardware so this argumument is a moot one.

[RobertRoberts]

My comment started off about floats, but then I found out it's not just floats, it's also integers.

But JS doesn't even _have_ integers...