On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore <p.f.moore at gmail.com> wrote: > On 29 September 2012 10:17, Stefan Krah <stefan at bytereef.org> wrote: > > Tim Delaney <timothy.c.delaney at gmail.com> wrote: > >> If those numbers are similar in other benchmarks, would it be accurate > and/or > >> reasonable to include a statement along the lines of: > >> > >> "comparable to float performance - usually no more than 3x for > calculations > >> within the range of numbers covered by float" > > > > For numerical programs, 1.4x (9 digits) to 3x (19 digits) slower would be > > accurate. On Windows the difference is even less. > > > > For output formatting, cdecimal is faster than float (at least it was > when > > I posted a benchmark a couple of months ago). > > To me, this means that the key point is that for the casual user, > float is no longer the "obvious" choice. You'd choose float for the > convenience of a built in type, and Decimal for the more natural > rounding and precision semantics. If you are sufficiently interested > in performance for it to matter, you're no longer a "casual" user. (Up > until now, I'd have said use float unless your need for the better > behaviour justifies the performance loss - that's no longer the case) > Does this mean we want to re-open the discussion about decimal constants? Last time this came up I think we decided that we wanted to wait for cdecimal (which is obviously here) and work out how to handle contexts, the syntax, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120929/b49d9830/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4