Okay, I'll try to explain.
The job of a parser is to perform the opposite of stringification as precisely as possible. That string source is not always a human typing on a keyboard.
If your stringifier doesn't output scientific notation, then you reject scientific notation because it's invalid data, plain and simple. It's completely irrelevant that to a human it still looks like it could be some number. It's like picking up the wrong baby at the hospital. It might be lovely and all, but it wasn't what you were supposed to get, and that matters. It's a sign that someone screwed up, potentially badly, and your job is to hunt down where the bug was and how to address it, not just roll with whatever came your way and win some competition on how long you can ignore problems.
If you want to parse natural language then sure, it makes sense. That's what flags and different functions are good for. It doesn't mean that has to be the default. As far as programming languages go, the default assumption is that your Parse() is parsing whatever your ToString() produced on the same type.
(Chances are ‘fromString’ accepts strings with very long prefixes of zeroes)
Having said that, I do think accepting “1E9” may go too far. If you accept that, why would you disallow “12E3”, “1.23E4”, “12300E-2”?
If you’re going to widen what the function accepts, I would add support for hexadecimal (“0x34”) and binary (“0b1001”) before adding this.
Is it though? String-to-float parsers are quite flexible in the range of inputs they allow. "1000", "1E3", "10E2", "0.1E4", "1000.0", "00000001000.00000000000000" all return the same float value. https://dotnetfiddle.net/K08vk5
(See also sibling comment by "someone".)
If your question is "Is this string the canonical representation of some number?" then a parser function on its own is the wrong tool.
I like this idea but I think it should be "HE" for hexadecimal exponent.
Imagine you ad a standard library string-to-integer parser that didn't know about minus signs. Sure, you could write your own function that wrapped the parser to allow for negative numbers, but wouldn't it be better if the standard library one did it?
I was operating under an unfounded assumption that the blog post existed instead of the code to do the thing for your particular use case rather than in addition to it, which isn’t entirely fair given we have had no prior interactions and I have not investigated your work at all.
pwg•6mo ago
billpg•6mo ago
For a 32 bit signed integer the limit is 2E9. This means that the exponent is fine 0-8, or if the exponent is 9, then only if the mantissa is 1 or 2. This only works with a single digit mantissa.
For adding more digits to the mantissa, while a robust range check can be done, it gets more complicated. String-to-Integer functions are very conservatively written pieces of code designed to be quick.