Recognize exponent suffix in parseWhole in ceylon.whole

[arseniiv]

I think there is also need to support reading string representations like

(a)  28e+123     // integral mantissa and nonnegative exponent
(b)  4.56789e11  // fractional mantissa, overall result is still integral

I suggest (b) be added too because it can be generated by formatting float values to convert from them if they are too big to be able to have integer to convert through.

As of the cases

(c)  28000e-2   // negative exponent but the value is integral
(d)  4.56789e3  // positive exponent but fractional part still exists

I believe (c) still isn’t needed to be accepted, and if (d) is understood as valid, then the parse result is a whole part of the actual number, that is any “invalid” digits are simply dropped.

What do you think?

[jvasileff]

IDK. This seems like it might be a job for ceylon.decimal to me. And once you have a float, you've given up exact precision anyway, so you can often just use float arithmetic. Would multiple rounding modes need to be supported?

An alternative is parseWhole(formatFloat(theFloat, 0, 0)).

[arseniiv]

And once you have a float, you've given up exact precision anyway, so you can often just use float arithmetic.

That’s so, but I’ve just thought about one specific case of converting floats to rational numbers (with Whole components) within a specified precision. In this case a conversion of at least “integral” floats could be necessary, and these may have value out of Integer’s bounds…

parseWhole(formatFloat(theFloat, 0, 0))

Ah, so I’ve still underinvestigated it. And that too:

This seems like it might be a job for ceylon.decimal

Yes, I agree if ceylon.decimal goes cross-platform, it’s a better place for the mentioned.

But I’d still be glad at least (a) to be allowed in parseWhole (and parseInteger too—I initially forgot). Maybe.