Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add EIP-5850: Complex Numbers stored in Bytes32 types #5850
Add EIP-5850: Complex Numbers stored in Bytes32 types #5850
Changes from 22 commits
d69341c
d7b6785
78354fa
b39a883
3a88ffd
4f75ec7
364af5d
bd8761a
b2c70b0
558dc94
2f1f2fc
55deb17
b3fa493
b14d5c2
13ec67d
55dd0ea
f46ad31
932e773
f42044a
cbcfc50
00bc0ff
612ca29
93c8c4b
d325fc3
693072c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, thank you for the EIP draft!
My question is regarding movitation: Could you help give more concrete examples of real world usage of on-chain imaginary numbers?
Also, is EIP/ERC the best place or is it better to be proposed as a Solidity/Vyper language feature?
@axic FYI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fundamentally, this EIP is essential if you want to track/control/record a variable (but more likely an array) that is complex in nature.
This EIP was focused on defining the storage aspect of the complex number building block, not how or why it would be manipulated on-chain. However, there is no harm discussing use cases outside of the EIP document.
Complex numbers are invaluable for electrical engineering specifications and calculations. A live certified safety standard defined as a working calculation (using the gasless view functionality) is much more valuable than a dead pdf equation.
Time-series analysis use Fourier Transforms for calculations and statistical distributions are defined via their complex number based characteristic function.
Linear algebra can easily enter into the realm of complex numbers.
Polynomials with non-real roots shouldn't necessarily interrupt your algorithm.
Code can be simpler, more readable and reusable if complex numbers are used (e.g. 2D rotations).
Even if you believe the above sorts of calculations will never be performed on-chain, some intermediate and final results will likely be reported as complex numbers.
But the simplest (and maybe most useful) use case/hack would be to define a 2d space within a single
bytes32
data type.Even though I gave the specification example in solidity, this EIP is language independent. The EVM stores data in 32 byte chunks. If we standardize that the least significant 16 bytes are Real and the most significant 16 bytes are Imaginary then any higher level language (Solidity/Vyper/etc.) can follow this implementation. If this were just a Solidity standard then other contracts written in Vyper would have difficulty understanding and interacting with these
bytes32
objects.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @xinbenlv's point was that this should be proposed as a feature either on the solidity or vyper (or both) repos. I think this could be an EIP, but the fact that it doesn't support floating point is a major hurdle to getting this adopted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is at a language independent level, but as long as the standard is set with real numbers in the lower 16 bytes and imaginary numbers in the upper 16 bytes then I'm not that bothered where it lives.
Neither fixed nor floating point are specified by the EIP. As currently defined, any number representation can be supported, so long as it fits inside the 16 bytes space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was unclear when reading the EIP. I would highly suggest indicating this in the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarification added to the spec