News for hackers. Stuff that matters.
Re:Show HN: libRmath.js – A port of R's Nmath numeric librar... by RobertRoberts on Monday March 19, 2018 @10:52PM (#16625643)
Well, the errors I ran into were happening within 4 decimal places. And the research I did at the time said you simply can't trust that the numbers will be accurate. Is this just an issue with floating point numbers in general then? This was a few years ago, maybe something has changed?
Re:Show HN: libRmath.js – A port of R's Nmath numeric librar... by dak1 on Monday March 19, 2018 @10:55PM (#16625661)
You may be thinking of https://stackoverflow.com/questions/588004/is-floating-point...

  0.1 + 0.2 === 0.3 // false
However, R is not immune to this problem either: https://stackoverflow.com/questions/6874867/floating-point-i...
Re:Show HN: libRmath.js – A port of R's Nmath numeric librar... by RobertRoberts on Monday March 19, 2018 @10:59PM (#16625677)
I did a quick look up and edited my original comment. But I think this is related...
Re:Show HN: libRmath.js – A port of R's Nmath numeric librar... by dagw on Tuesday March 20, 2018 @04:40AM (#16626853)
Is this just an issue with floating point numbers in general then?

Short answer, Yes. JavaScript floats behave identically to 64-bit IEEE floats in all other programming languages. Dealing with rounding errors, precision, stability etc when doing math with floating point numbers is an entire area of research in itself that many very smart people have dedicated their research careers to. This is why you should be very careful before you start writing your own numeric algorithms since the pitfalls are as subtle as they are numerous. Rolling your own core numeric algorithms basically falls into the same category as rolling your own crypto. To a first approximation, leave it to the experts.

Some languages/libraries do offer arbitrary precision numbers that let you avoid these all pitfalls in exchange for a massive performance hit.