Calculation precision in JavaScript

[tab00]

Has there been any progress in fixing the problem with imprecise calculations in JavaScript (e.g. 0.1+0.2===0.3 returns false)?

I’ve expressed my disappointment on numerous occasions before about this problem and have just been hit again when using MongoDB’s $divide aggregation operator. 280/0.28 returns 999.9999... when I need it to return 1000 for correct sort order.

In my own code I use https://www.npmjs.com/package/big-number for precise calculations but I have no control over how MongoDB does $divide, so it’s very frustrating.

[robfallows]

This is because JavaScript uses the IEEE-754 64-bit specification for floating point. MongoDB themselves have some advice on maintaining precision:

https://docs.mongodb.com/manual/tutorial/model-monetary-data/

Note that you’ll need to do calculations with the database engine, not JS code to take advantage of NumberDecimal.

[tab00]

NumberDecimal

NumberDecimal was released in MongoDB 3.4, and looks like I could use it for accurate aggregation queries.
Though I can’t use Meteor’s built-in MongoDB to try it as it’s still at version 3.2.15.

[rhywden]

0.1+0.2===0.3 is false

That’s pretty much a standard issue for any and all languages using floats.

[tab00]

@rhywden

0.1+0.2===0.3 is false

That’s pretty much a standard issue for any and all languages using floats.

Not for a long time (e.g. decade) in Java, ASP.NET, etc. I’ve already expressed my thoughts before which you can read in these threads:

What is Meteor missing?

ES6 modules has certainly made Meteor much more complicated, but it’s for the better in the long run. Though what’s missing now are things that would make it easier to work with ES6 modules. e.g. auto-import functionality. It would be great if there was an IDE that could allow you to easily import a required module (just right click on the unresolved variable), which is what Visual Studio has had for C# for years. Visual Studio even knows which imports are unnecessary that you can remove. More…

The Sad State of Web Development

I’ve been programming since around 10 years of age and do know about other languages. I use decimal in .NET and BigDecimal in Java for monetary calculations. They’ve been around for almost a decade. JavaScript has been around since 1995 (over 2 decades) yet we still don’t have a type other than floating point for non-integer numerical calculations, which is imprecise. I’d think it’s one reason to call it a bad language. Yet now here we are trying to build serious applications with it (or at le…

Meteor for corporate developers

It should be their goal if they wish to be a commercially viable company. I worked as a developer in IBM Global Services in my previous full-time job, and worked on big projects for corporate clients. The clients are willing to pay top rates for quality (including labor), and project budgets are often into the multi millions. Now that I’ve immersed myself into the Meteor world, I see huge disparities that need to be addressed. More people from the corporate world are going to discover Meteor a…

Do you recommend meteor for financial service..?

It’s better to be aware of the issues at design and planning time. It can be a hassle to redesign at later stages. My point is that it can be more complicated than you think. Saying simply “there’s no problem, just do this or that” is often not helpful in solving frustrating problems of working with monetary data in JavaScript which I have already been through. Based on my experience, when developing financial applications in JavaScript, it’s OK to store monetary values in ordinary double dat…

[rhywden]

@tab00

@rhywden

0.1+0.2===0.3 is false

That’s pretty much a standard issue for any and all languages using floats.

Not for a long time (e.g. decade) in Java, ASP.NET, etc. I’ve already expressed my thoughts before which you can read in these threads:

Erm, no. In Java you need to do java.lang.Float.compare(float1, float2) for example. The problem is inherent to floats.

Either you use other data types or you create special functions (for example using an error margin, though that has problems of its own).

Again: This is an inherent problem of the data type which makes naive comparison through a standard implementation of == impossible.

It’s why the data type decimal(aka numeric) exists in the first place.

[tab00]

I meant that the BigDecimal data type was provided in Java around a decade ago. Nobody should still be using other data types for monetary data and calculations in Java.

What has been done in JavaScript for the same problem? ECMA have been busy giving us a whole lot of programming shorthand (ES6 or ES2015). But will they do anything about making it easier to do accurate monetary calculations? Or are they still spending their time and effort to give us more exciting shorthand coding syntax so that one day we’ll be able to write full-featured infinitely-scalable production-ready apps in around 10 lines of code?

[rhywden]

Maybe, just maybe, Javascript isn’t the proper language for financial applications then?

I mean, I wouldn’t trust a weakly-typed language anyway for anything really important…