Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

256-bit unsigned integer #102

Open
JohnGreenan opened this Issue Mar 25, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@JohnGreenan
Copy link

commented Mar 25, 2019

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.

@juddgaddie

This comment has been minimized.

Copy link

commented Mar 25, 2019

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?

@donmendelson

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

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

@JohnGreenan

This comment has been minimized.

Copy link
Author

commented Mar 26, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 26, 2019

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

@gelupa

This comment has been minimized.

Copy link

commented Apr 1, 2019

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.

@donmendelson

This comment has been minimized.

Copy link
Member

commented Apr 1, 2019

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.

@donmendelson

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.