‫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.