Support for scientific notation when parsing coin amounts in ParseCoin

[aspect]

Summary

Support for scientific notation such as 1.23e+6stake when parsing coins

Problem Definition

When specifying coin amounts (especially during user input), it is extremely convenient to be able to use scientific notation such as 12.345e9 instead of 1234000000. This is especially useful when working with coins that have very large numerical values (i.e. 1mycoin == 1e12mysmallest).

Proposal

Solution should support numbers such as 123e6, 1.23E+6 and reject 1e-2.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

@aspect not totally sure we want to further complicate the parsing of coins. It would be ideal, imho, that input to parsing coins would be of only one form and clients would have to perform an necessary conversion. In other words, you'd always provide e.g. 25atom as a client instead of 25000000uatom.

/cc @rigelrozanski

[rigelrozanski]

I'm more indifferent either way, however if the feature is clean/well-implemented/well-tested and doesn't seem to make the code base more confusing I don't see it as necessarily a bad addition - but agree in principle with what you're saying, we don't want to increase code complexity unnecessarily. The availability of this feature could reduce the possibility of typos errors in clients... I do think it's easier to read and confirm 1E10 than 10000000000 - also one could simply phrase all inputs in as "atoms" kinda (aka 1.23E6uatoms)... which actually seems to be the middle ground for allowing for actual decimal atom inputs from clients which @faboweb is interested in (which btw I think is horrible idea due to namespacing concerns to allow for multiple denoms for the same token)... so I dunno for what it's worth it doesn't seem like a half bad idea to me!

Either way, I'd recommend @aspect halt development (or risk of wasted effort) until some form consensus is reached in this issue's conversation

[alessio]

@aspect dixit:

it is extremely convenient to be able to use scientific notation

@alexanderbez dixit:

It would be ideal, imho, that input to parsing coins would be of only one form and clients would have to perform an necessary conversion

I very much agree with @alexanderbez here. The SDK should provide only primitives, therefore we should avoid introducing additional convenience parsers. They would come with the extra burden of maintaining different user input formats and their respective sanitization and validation functions.

In other words, additional nice-to-haves introduce unnecessary security risks and are not worth their cost.

[fedekunze]

I think there's enough consensus that this parsing should not be implemented on the SDK atm. I suggest implementing this on the client side instead.

Closing this for now.