3 ms·
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 accu
by RobertRoberts 9y ago
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?
- dak1 9y agoYou may be thinking of https://stackoverflow.com/questions/588004/is-floating-point-math-broken 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-issue-in-r https://stackoverflow.com/questions/6874867/floating-point-i...
- RobertRoberts 9y agoI did a quick look up and edited my original comment. But I think this is related...
- dagw 9y agoIs 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.