Feature: Allow scientific notation for literals#1721
Feature: Allow scientific notation for literals#1721fubuloubu merged 7 commits intovyperlang:masterfrom
Conversation
b4b35b1 to
f5473ad
Compare
9376f9b to
94b01e3
Compare
|
Note: 3 of the failures are from #1681, looks like a few others are falling out due to something about using |
98925b7 to
7a15883
Compare
|
So I took a look at the failing tests and it looks like this PR is somehow picking up bad literals that were previously passing. Which I think is a good thing. I want to look at each one of them in more detail though. |
|
Yeah, my thoughts exactly. It seems like there was some fallout of this change, which is good we're catching it now. I'll fix the lint issue. |
216d6bb to
602e949
Compare
|
I think I'm getting this tracked down... looks like the following phrase could be the cause? "Substituting negative values for unary subtractions" Perhaps on this substitution, there is something about constants where the unary substraction isn't being respected, ergo constant folding ignores the negative sign. |
602e949 to
1e35e6f
Compare
2fa2bfe to
03bf59c
Compare
|
G2G once #1741 is merged (will rebase then) |
03bf59c to
91c3a15
Compare
|
Actually, scratch that... missing test cases! |
|
Waiting for 2 reviews |
This reverts commit fd9f3d0.
Note: when using literals, it used to be acceptable to have >10
decimal places, giving the false impression that you could
specify a decimal literal as having >10 decimal places. It
would silently drop the extra digits in that case.
Note: changed test case to gwei from szabo to "fix" the new
conversion error
623e2dd to
96ef9f9
Compare
|
Whoops, forgot to remove the WIP label. Ready for review! |
charles-cooper
left a comment
There was a problem hiding this comment.
I'm pretty happy with this. Thanks!
What I did
Actual solution to #1680, allowing scientific notation literals (e.g.
3e6,1e-10) to be used in vyper programs.See: https://python-reference.readthedocs.io/en/latest/docs/float/scientific.html
Work remaining
Need to work out semantics. Does a positive exponent get translated to an integer literal, or remain a decimal? Should it always be parsed a decimal?Parsing as a decimal always worksNeeds significant test cases to prove equivalency of constant expressions to their runtime equivalent (avoid issues like Modulo at compile time differs from modulo at runtime #1693)Increased precision in fde6d2b avoids floating point issuesDescription for the changelog
Added support for decimal literals using scientific notation
Cute Animal Picture