So let's try this high precision double and for that, I'll first of all
delete that entry I have in my science collection here and now I'll again insert one document into my
science collection and that one document will be a high precision double or will be using high precision
doubles.
So I still have a
but now I will use number decimal which is the mongodb shell constructor for this value.
Now again if you're using a driver for Python, for Node, for C++, for Java, you will find help in the driver
docs,
there you will find the constructor you use to create this 128 bit decimal. In the shell,
the constructor is named number decimal
and then again we use quotation marks to pass the value.
You don't have to use them,
you could pass something like this
but then you face that issue of imprecision because that value is not precise,
so at the point of time mongodb tries to store it precisely, it still has the
well imprecision baked in,
so we should pass it as a string
and the same of course for B.
So there, I also have my number decimal, 0.1 stored like this.
Now if we query our database here, we see it's stored as such decimal, 128 bit decimal in the database.
Now let's repeat that aggregation command from before where we project into that result field by subtracting
B from A.
If I hit enter here, we see now the result is actually an exact number decimal,
so now we indeed have the exact value we need
and just as with long and integer, we can use the number decimal for all kinds of calculations like subtract
here,
we could also sort by it, we can increment it in an update operation,
you have to be aware though just as with the long value that if you do update for example,
so we update our one value here and you do that with increment,
if you do increment a by .1 let's say, that will work
but if you have a look into your database, you of course now face the issue of having an imprecision.
It actually did not convert it to a float 64,
it kept the 128 bit decimal but you could introduce imprecision here if you add a float like this because
that float could be unprecise.
So a better way for updating is of course just as before to use number decimal in this case and pass
that value
and if you do this, you're guaranteed that you don't suddenly introduce some imprecision into your otherwise
precise data on the backend.
But then besides that, you can use it in your normal sorting, querying, just like a normal number but with
more precision, of course that precision comes at a price, that's also worth noting. If I quickly add a
new collection, nums and I insert one value here,
let's say a
which is .1,
if I now have a look at the stats of my nums collection with only that one document with that one
field in there, we see that is the size that happens to be stored
and if I now remove that,
so I delete many in nums, all elements that are in there and I now insert A again
but now I use number decimal for this value,
then you will see that if I have a look at the stats again, it's actually bigger.
So here you see it has a bigger size now because more space is reserved for this high precision decimal.
So that is a downsize,
so using it for all decimal values might not be optimal
but for cases where you need a high precision, this is your solution which allows you to do high precision
math without losing any precision.