<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 10, 2014 at 10:48 AM, Wolfgang Maier <span dir="ltr"><<a href="mailto:wolfgang.maier@biologie.uni-freiburg.de" target="_blank">wolfgang.maier@biologie.uni-freiburg.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Montag, 10. März 2014 14:53:42 UTC+1 schrieb Stefan Krah:<br>
<br>
> [My apologies for being terse, I don't have much time to follow this<br>
discussion right now.]<br>
<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> I think users of decimal literals will just need to deal with the risk of<br>
unexpected rounding, as the alternatives are even more problematic.<br>
<br>
> That is why I think we should seriously consider moving to IEEE semantics<br>
for a decimal literal.  Among other things:<br>
> - Always round the literal inputs.<br>
> - Supply IEEE contexts.<br>
> - Make Decimal64 the default.<br>
> - Add the missing rounding modes to sqrt() and exp().<br>
> - Keep the ability to create exact Decimals through the constructor when<br>
no context is passed.<br>
> - Make the Decimal constructor use the context for rounding if it is passed.<br>
> - ...<br>
<br>
While I find this discussion about decimal literals extremely interesting,<br>
in my opinion, such a literal should have an underlying completely new<br>
numerical type, if it is really supposed to be for inexperienced users.<br>
<br>
Most of the discussions right now concern rounding issues that occur after<br>
the decimal point, but I think an at least equally big problem is rounding<br>
*to the left* of it as in (using current float):<br>
<br>
>>> 1e50 + 1000<br>
1e+50<br>
<br>
Importantly, Decimal is no cure here:<br>
<br>
>>> Decimal(10**50) + Decimal(100)<br>
Decimal('1.000000000000000000000000000E+50')<br>
<br>
(of course, you can debate context settings to make this particular example<br>
work, but, in general, it happens with big enough numbers.)<br>
<br>
The solution for this example is using ints of course:<br>
<br>
>>> 10**50 + 100<br>
100000000000000000000000000000000000000000000000100<br>
<br>
, but obviously this works only for whole numbers, so there currently is no<br>
built-in way to make this example work correctly:<br>
<br>
>>> 10**50 - 9999999999999999.5<br>
1e+50<br>
<br>
(or with Decimal:<br>
>>> Decimal(10**50) - Decimal('9999999999999999.5')<br>
Decimal('1.000000000000000000000000000E+50')<br>
).<br>
<br>
If we are discussing a new number literal I would like to have it cope with<br>
this and my suggestion is a new numeric type that's sort of a hybrid between<br>
int and either Decimal or float, i.e., a type that behaves like int for<br>
digits left of the decimal point, but may truncate to the right.<br>
In pure Python, something similar (but not a literal form of course) could<br>
be implemented as a class that stores the left digits as an int and the<br>
right digits as a float/Decimal internally. Calculations involving this<br>
class would be slow due to the constant need of shifting digits between the<br>
integer´and the float part, and might be too slow for many users even when<br>
written in C, but its behavior would meet the expectation of inexperienced<br>
people better than the existing types.<br>
Going back to Mark Harris' initial proposal of unifying numeric types (which<br>
I am not trying to support in any way here), such a type would even allow to<br>
unify int and float since an ints could be considered a subset of the new<br>
type with a fractional part of zero.<br></blockquote></div><br></div><div class="gmail_extra">I think what you're proposing here is variant of fixed-point numbers. The representation you seem to be looking for is an arbitrary-precision integer plus an exponent. A question for you: how would you treat results like 1/3?<br clear="all">

</div><div class="gmail_extra"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>