Stefan Krah wrote:
> Precision: 19 decimal digits
>
> float:
> result: 3.1415926535897927
> time: 0.112874s
>
> cdecimal:
> result: 3.141592653589793236
> time: 0.348100s
>
> decimal:
> result: 3.141592653589793236
> time: 43.241220s
Apparently there were concerns about the correctness of the
On 9/29/2012 2:38 PM, Guido van Rossum wrote:
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.
I think that oug
On Sat, Sep 29, 2012 at 10:09 PM, R. David Murray wrote:
> On Sun, 30 Sep 2012 08:01:00 +1000, Tim Delaney
> wrote:
>> Also the example at
>> http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads:
>>
>> ... raise AttributeError(attr) from None...
>>
On Sun, 30 Sep 2012 08:01:00 +1000, Tim Delaney
wrote:
> Also the example at
> http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads:
>
> ... raise AttributeError(attr) from None...
>
> Looks like there's an elipsis there that shouldn't be.
This a
On Sep 29, 2012 2:38 PM, "Guido van Rossum" wrote:
>
> On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon wrote:
> >
> >
> > On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore wrote:
> >>
> >> On 29 September 2012 10:17, Stefan Krah wrote:
> >> > Tim Delaney wrote:
> >> >> If those numbers are similar in
In article
,
Tim Delaney wrote:
> BTW, "What's New": http://www.python.org/download/releases/3.3.0/ still
> says 80x for decimal performance.
Thanks for the report. The page has now been updated to match the final
3.3.0 release announcement post.
--
Ned Deily,
n...@acm.org
__
Also the example at
http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads:
... raise AttributeError(attr) from None...
Looks like there's an elipsis there that shouldn't be.
Tim Delaney
___
Python-Dev mail
BTW, "What's New": http://www.python.org/download/releases/3.3.0/ still
says 80x for decimal performance.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
On Sun, Sep 30, 2012 at 4:26 AM, Brett Cannon wrote:
> 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.
Just
On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon wrote:
>
>
> On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore wrote:
>>
>> On 29 September 2012 10:17, Stefan Krah wrote:
>> > Tim Delaney wrote:
>> >> If those numbers are similar in other benchmarks, would it be accurate
>> >> and/or
>> >> reasonable
On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore wrote:
> On 29 September 2012 10:17, Stefan Krah wrote:
> > Tim Delaney 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 flo
On 29 September 2012 10:17, Stefan Krah wrote:
> Tim Delaney 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
Antoine Pitrou wrote:
> > Wow! I had no idea cdecimal was that close in speed to float. That's
> > seriously impressive.
>
> I think this means the performance difference is on the same order
> of magnitude as the CPython interpretation overhead. Still, it's
> impressive indeed.
Of course, if yo
Tim Delaney 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
On Fri, 28 Sep 2012 21:51:39 +0100
Paul Moore wrote:
> On 28 September 2012 19:19, Stefan Krah wrote:
> > Brett Cannon wrote:
> >> Georg Brandl wrote:
> >> > * A C implementation of the "decimal" module, with up to 80x speedup
> >> > for decimal-heavy applications
> >>
> >>
On 29 September 2012 07:50, Tim Delaney wrote:
> On 29 September 2012 06:51, Paul Moore wrote:
>
>>
>> Wow! I had no idea cdecimal was that close in speed to float. That's
>> seriously impressive.
>>
>
> If those numbers are similar in other benchmarks, would it be accurate
> and/or reasonable t
On 29 September 2012 06:51, Paul Moore wrote:
>
> Wow! I had no idea cdecimal was that close in speed to float. That's
> seriously impressive.
>
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 flo
On 28 September 2012 19:19, Stefan Krah wrote:
> Brett Cannon wrote:
>> Georg Brandl wrote:
>> > * A C implementation of the "decimal" module, with up to 80x speedup
>> > for decimal-heavy applications
>>
>> Could you bump up the factor to 120x in the final announcement? Ther
Brett Cannon wrote:
> Georg Brandl wrote:
> > * A C implementation of the "decimal" module, with up to 80x speedup
> > for decimal-heavy applications
>
> Could you bump up the factor to 120x in the final announcement? There were
> a couple of performance improvements in t
On Fri, Sep 28, 2012 at 11:40 AM, Stefan Krah wrote:
> Georg Brandl wrote:
> > * A C implementation of the "decimal" module, with up to 80x speedup
> > for decimal-heavy applications
>
> Could you bump up the factor to 120x in the final announcement? There were
> a couple of performance impr
Georg Brandl wrote:
> * A C implementation of the "decimal" module, with up to 80x speedup
> for decimal-heavy applications
Could you bump up the factor to 120x in the final announcement? There were
a couple of performance improvements in the meantime, and this is what I'm
consistently measur
Mark Lawrence wrote:
On 24/09/2012 07:18, Georg Brandl wrote:
[snip impressive list of improvements]
Yes, but apart from all that, what have the python devs ever done for
us? Nothing :)
I'll take that kind of nothing any day of the week! ;)
~Ethan~
__
On 24/09/2012 07:18, Georg Brandl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm delighted to announce the
third release candidate of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm delighted to announce the
third release candidate of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x
24 matches
Mail list logo