3 ms·
I think the advantage behind using something like Big.js is to future proof the code against hyper-inflation. Though a dedicated currency engine would better ha
by strainer 8y ago
I think the advantage behind using something like Big.js is to future proof the code against hyper-inflation. Though a dedicated currency engine would better have the ability to set and conveniently update the currency denomination of stored values to cope with this.
With float64's maximum 'safe' integer at almost ten thousand trillion, I believe this should be enough to compute most commercial transactions securely as long as the amounts base denomination is up to date (eg cents or dollars or megadollars).
The quantization noise mentioned in this article is possible to round off when appropriate.
function round_tail_digits(c){
return Math.round(c*1e15)/1e15
}
function round_at_hundreds(c){
return Math.round(c*100)/100
}
- sk5t 8y agoThis approach, at least in languages like C and Java, would effectively smush the effective MAX_INT down to MAX_INT/1e15 or whatever. No bueno.
- strainer 8y agoIt doesn't because basically - the point floats. The max_int doesn't mean the largest whole number that can be represented, it effectively means how much resolution you have on the number line in every one of a very wide range of scales. These languages all give exactly the same standard IEEE754 float math results for basic operations.
- smallnamespace 8y ago> I think the advantage behind using something like Big.js is to future proof the code against hyper-inflation. This is probably over-engineering. Currencies that go through hyperinflation typically end up being officially re-denominated many times, there's no 'zero maintenance' path that a library will give you.