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

BigInt and Float support #51

Open
jimscarver opened this issue May 10, 2022 · 3 comments
Open

BigInt and Float support #51

jimscarver opened this issue May 10, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@jimscarver
Copy link
Collaborator

jimscarver commented May 10, 2022

Introduction/Motivation/Abstract

Data limitations create bugs. Without BigInt we are forever plagued by overflow and underflow errors. One may blow up the world. without these types we are unable to marshal objects of those types faithfully using inter blockchain protocol.

Motivating Examples

@dckc pointed out these issues and how agoric contracts convert easily to rholang and there is a lot there we can use ERTP, IBC, CapTP, etc. However when BigInts and Float are used we will introduce bugs as already happened with the POS contract and again recently. See video. https://youtu.be/IbW6uvgCSv4?t=5463

Design

BigInt requires virtually a global change in the rnode source of Int to BigInt.

Adding floating point operations and constants is faily mechanical and requires an update to the rholang spec.

Counter-Examples

Drawbacks

Alternatives

References

@jimscarver jimscarver added the enhancement New feature or request label May 10, 2022
@dckc
Copy link

dckc commented May 10, 2022

I suggest making floats a separate issue; those are much, much less important.

@Bill-Kunj
Copy link

Bill-Kunj commented May 11, 2022

I suggest making floats a separate issue; those are much, much less important.

I agree. Arbitrary precision floats are far less important.
Making BigInt universal is vital, as recent problems with PoS demonstrate.
The fact that custom tooling has been required to support the total RPC token supply should be ample evidence.

@Bill-Kunj
Copy link

As a general reply to the abstract of this rchip, data limitations create bugs is more properly expressed as data limitations ARE bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants