Thanks! TigerBeetle can track currency, but leaves accounting policy and money types to a higher layer, since accounting policy (and preferred money type or even precision) differs according to application/organization/jurisdiction.
I wonder if hyperinflation might be one edge case where using something like floating point for money makes sense. I’m thinking your number format might be, say: no sign bit, 28 bits exponent, 100 bits mantissa. So all practical computations with non-broken currencies will stay in the “denormal” region forever, but if a currency implodes and somehow manages to carry on hyperinflating in that way for a long time without collapsing completely, eventually the exponent bits start getting used and giving you more headroom before the software all crashes.
Quadruple precision floating point format is kinda close with that, but with even more of a mantissa and less of an exponent. But hardware acceleration of quads is rare in commodity hardware and seems to be mostly limited to mainframes.
I was thinking there’s no need to go with something standard since there’s negligible hardware support for the standard anyway and you have some slightly weird requirements like not needing sign.
[Comment removed by moderator pushcx: Reminder that Lobsters is not the place to define the one moral economic system for the world.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
[Comment removed by moderator pushcx: Off-topic thread on banking.]
I might suggest taking a look at some reading for how to handle monetary values rigorously and portably via a powerful type system.
All the best,
-HG
Thanks! TigerBeetle can track currency, but leaves accounting policy and money types to a higher layer, since accounting policy (and preferred money type or even precision) differs according to application/organization/jurisdiction.
I wonder if hyperinflation might be one edge case where using something like floating point for money makes sense. I’m thinking your number format might be, say: no sign bit, 28 bits exponent, 100 bits mantissa. So all practical computations with non-broken currencies will stay in the “denormal” region forever, but if a currency implodes and somehow manages to carry on hyperinflating in that way for a long time without collapsing completely, eventually the exponent bits start getting used and giving you more headroom before the software all crashes.
Quadruple precision floating point format is kinda close with that, but with even more of a mantissa and less of an exponent. But hardware acceleration of quads is rare in commodity hardware and seems to be mostly limited to mainframes.
Thanks.
I was thinking there’s no need to go with something standard since there’s negligible hardware support for the standard anyway and you have some slightly weird requirements like not needing sign.
I once made a datatype for D, where I came to the same conclusion: 128bit integer is the best default.
The next fun aspect about money is rounding modes. Some people have to use weird ones in their calculations.
I love your docs there and the reasons given. We certainly leave rounding modes to the accounting policy in the application above TigerBeetle!
The blog posts for TigerBeetle are always great, and almost make me wish I had use for this software, keep it up.