Define non-integer type #124
Conversation
|
@liamsi is there anything to worry about w.r.t. overflowing on the multiplication? I assume that a simple "if it overflows, the tx is invalid" check is sufficient? Edit: I think it should be fine as-is for now without explicitly dealing with width of intermediate results and overflows. We can think about that in #108 (though admittedly python uses unlimited-width integers, so...) |
| | `numerator` | uint64 | Rational numerator. | | ||
| | `denominator` | uint64 | Rational denominator. | | ||
|
|
||
| Represents a (potentially) non-integer number. |
There was a problem hiding this comment.
This will be a relatively big change compared to the SDK. I guess switching from the current implementation to this rational type is really low priority, right?
There was a problem hiding this comment.
Right, it doesn't affect the devnet at all. We can argue that with proper abstractions it doesn't even need to be done for first testnet. Both Decimal as it currently exists in the SDK and Rational (i.e. our Decimal type) would produce similar numbers, so it wouldn't even change the state transitions in anything but in some cases that required lots of precision.
There was a problem hiding this comment.
Notes under "optional to implement until we there is nothing left to crunch on" :-D (tagging @evan-forbes s.t. he is also aware of this.
Fixes #120.
Defines the Decimal non-integer type as a rational number.