Add EIP-5850: Complex Numbers stored in Bytes32 types

[genkifs]

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

A critical exception has occurred:
Message: pr 5850 is already merged; quitting
(cc @alita-moore, @mryalamanchi)

[xinbenlv]

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

[genkifs]

Could you help give more concrete examples of real world usage of on-chain imaginary numbers?

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.

proposed as a Solidity/Vyper language feature

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.

[Pandapip1]

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.

[genkifs]

should be proposed as a feature either on the solidity or vyper (or both) repos

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.

the fact that it doesn't support floating point is a major hurdle

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.

[Pandapip1]

As currently defined, any number representation can be supported, so long as it fits inside the 16 bytes space.

This was unclear when reading the EIP. I would highly suggest indicating this in the spec.

[genkifs]

Clarification added to the spec

[Pandapip1]

I really feel this standard is too under-specified to be useful as it stands right now, but this meets the minimum requirements of a draft.

[genkifs]

I really feel this standard is too under-specified to be useful as it stands right now,

If the community evolves this into a stronger, more detailed specification then that is fine by me.

My preference would be for a signed fixed point, 18 decimal place number format but I don't want to force this as other representations may be better suited.