<p dir="ltr"><br>
On Sep 29, 2012 2:38 PM, "Guido van Rossum" <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
><br>
> On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> ><br>
> ><br>
> > On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> >><br>
> >> On 29 September 2012 10:17, Stefan Krah <<a href="mailto:stefan@bytereef.org">stefan@bytereef.org</a>> wrote:<br>
> >> > Tim Delaney <<a href="mailto:timothy.c.delaney@gmail.com">timothy.c.delaney@gmail.com</a>> wrote:<br>
> >> >> If those numbers are similar in other benchmarks, would it be accurate<br>
> >> >> and/or<br>
> >> >> reasonable to include a statement along the lines of:<br>
> >> >><br>
> >> >> "comparable to float performance - usually no more than 3x for<br>
> >> >> calculations<br>
> >> >> within the range of numbers covered by float"<br>
> >> ><br>
> >> > For numerical programs, 1.4x (9 digits) to 3x (19 digits) slower would<br>
> >> > be<br>
> >> > accurate. On Windows the difference is even less.<br>
> >> ><br>
> >> > For output formatting, cdecimal is faster than float (at least it was<br>
> >> > when<br>
> >> > I posted a benchmark a couple of months ago).<br>
> >><br>
> >> To me, this means that the key point is that for the casual user,<br>
> >> float is no longer the "obvious" choice. You'd choose float for the<br>
> >> convenience of a built in type, and Decimal for the more natural<br>
> >> rounding and precision semantics. If you are sufficiently interested<br>
> >> in performance for it to matter, you're no longer a "casual" user. (Up<br>
> >> until now, I'd have said use float unless your need for the better<br>
> >> behaviour justifies the performance loss - that's no longer the case)<br>
> ><br>
> ><br>
> > Does this mean we want to re-open the discussion about decimal constants?<br>
> > Last time this came up I think we decided that we wanted to wait for<br>
> > cdecimal (which is obviously here) and work out how to handle contexts, the<br>
> > syntax, etc.<br>
><br>
> I think that ought to be a Python 4 feature if we ever want it to be a<br>
> feature. And I'm not saying this to kill the discussion; I just think<br>
> it will be a huge change that we have to consider very carefully.<br>
> While the existing float definitely has problems for beginners, it is<br>
> incredibly useful for advanced users. Consider e.g. the implications<br>
> for numpy / scipy, one of the fastest-growing specialized Python user<br>
> communities.<br>
><br>
> Now if you want to introduce a new notation for decimals, e.g. 3.14d<br>
> and 1e42d, that would be a fine thing. (Should we also have complex<br>
> decimals? 1jd anyone?)</p>
<p dir="ltr">That's actually what I meant and not replacing floats (unless a command line flag was used); sorry if that wasn't clear.</p>
<p dir="ltr">-brett</p>
<p dir="ltr">><br>
> --<br>
> --Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>
</p>