256-bit unsigned integer
JohnGreenan opened this issue · 8 comments
Allow SBE to handle 256-bit unsigned integers. Use case specifically for non-traditional asset class trading where there can be a lot of numbers after the decimal point and a lot of numbers before the decimal point.
Happy to share more details on a call or at a WG meeting.
To help my understanding do you mind sharing what language you are going to consume this value in and how you intend to represent it?
@JohnGreenan, when you say "a lot of numbers after the decimal point and a lot of numbers before the decimal point", it seems to me that the immediate requirement is actually for a very large exact decimal number rather than an integer.
Anyone correct me if I'm wrong, but most general purpose hardware still is limited to 64 bit integer operands with 128 bit arithmetic results. Therefore, such a number definition will be composed rather than a native type. To compose such a decimal, we would need a mantissa larger than uint64.
I'm not opposed to this proposal, but we have to make sure it can be implemented across platforms and programming languages. As a work-around you can use array of uint of sufficient size.
To help my understanding do you mind sharing what language you are going to consume this value in and how you intend to represent it?
No comment on the language. Sorry, commercial sensitivity.
How we intend to represent it? Not sure I understand.
@JohnGreenan, when you say "a lot of numbers after the decimal point and a lot of numbers before the decimal point", it seems to me that the immediate requirement is actually for a very large exact decimal number rather than an integer.
Anyone correct me if I'm wrong, but most general purpose hardware still is limited to 64 bit integer operands with 128 bit arithmetic results. Therefore, such a number definition will be composed rather than a native type. To compose such a decimal, we would need a mantissa larger than uint64.
I'm not opposed to this proposal, but we have to make sure it can be implemented across platforms and programming languages. As a work-around you can use array of uint of sufficient size.
Hi Don,
"immediate requirement is actually for a very large exact decimal number rather than an integer"
Yes, but thus far this has been done by using a unit64 and moving the decimal point around.
Agreed on hardware. Agreed on number definition - for example https://gmplib.org/
Workaround has been to chunk up 256 in 4x64.
With regard to platforms and programming languages - that's sensible. Is there a quorum that is required? If you can provide some guidance then I can work to establish some relevant proof-of-concept implementations...
It is common to have 256 bit operations defined on Cryptocurrency virtual machines, such as Ethereum's EVM. And 1 ETH equals 10^18 wei, and wei is the most small currency unit in Ethereum. So for the trading of those assets, a very large exact decimal number may be convenient.
When we started SBE over 5 years ago, we recognized the need for an exact decimal datatype for money. Although there is an industry standard, namely IEEE 754-2008, many programming languages lacked support for it as a decimal interchange format, even though they all implement the standard for binary floating point. Maybe it is time to reconsider. My understanding is that there is support now in gcc and as I recall, limited support in .NET. However, Java's BigDecimal does not conform to the standard for serialization.
We should avoid getting into a format that does not conform to an industry standard, and numerical methods are notoriously difficult to get right. We should use something tried and true if we make any change.
Discussed in HPWG meeting April 10. Discussion:
- Agreed that there is a need for large numbers for cryptocurrency, keys, etc.
- Integer representation is relatively straightforward, but not floating point.
- We don't want to specify operations and numerical methods, only wire format.
- The large numbers are not native on common platforms, and no agreed standard.
- Since they are not native, access is as an array of native integers.
- Tabled until a more specific proposal is offered.
Closing this issue for v2.0 rc2. May be reopened at a later date.