                                                                                                                                                                                                                                                                
Path: q10ni65116189wif.0!nntp.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin2!goblin1!goblin.stu.neva.ru!news2.euro.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Mon, 08 Oct 2012 22:20:23 -0400
From: Dave Angel <d...@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Terry Reedy <tjre...@udel.edu>
Subject: =?UTF-8?B?UmU6IFRvIGdldCB0aGUgYWNjdXJhdGUgdmFsdWUgb2YgMSAtIDAuOTk=?=
	=?UTF-8?B?OTk5OTk5OTk5OTk5OSAsaG93IHRvIGltcGxlbWVudCB0aGUgcHl0aG9uIGFsZ28=?=
	=?UTF-8?B?cml0aG0g77yf?=
References: <91ff9b33-c212-4be0-8ed0-1f6b16f56865@googlegroups.com>
	<5072E7CC.2070...@davea.name>
	<CAPTjJmons5fwExNOaug0dNsym2eLe5Pduh6cVqynSAPoSow...@mail.gmail.com>
	<5072EDA6.6040...@davea.name> <k4vvjt$dt...@ger.gmane.org>
In-Reply-To: <k4vvjt$dt...@ger.gmane.org>
Cc: python-l...@python.org
Precedence: list
Reply-To: d...@davea.name
Newsgroups: comp.lang.python
Message-ID: <mailman.1977.1349749258.27098.python-l...@python.org>
Lines: 44
NNTP-Posting-Host: 2001:888:2000:d::a6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10/08/2012 09:45 PM, Terry Reedy wrote:
> On 10/8/2012 11:13 AM, Dave Angel wrote:
>
>>> Isn't it true, though, that Python 3.3 has a completely new
>>> implementation of decimal that largely removes this disadvantage?
>
>> I wouldn't know, I'm on 3.2.  However, I sincerely doubt if it's within
>> a factor of 100 of the speed of the binary float, at least on
>
> >>> import timeit as tt
> >>> tt.repeat("float('1.0')-float('0.9999999999')")
> [0.6856039948871151, 0.669049830953858, 0.668688006423692]
> >>> tt.repeat("Decimal('1.0')-Decimal('0.9999999999')", "from decimal
> import Decimal")
> [1.3204655578092428, 1.286977575486688, 1.2893188292009938]
>
> >>> tt.repeat("a-b", "a = 1.0; b=0.9999999999")
> [0.06100386171601713, 0.044538539999592786, 0.04451548406098027]
> >>> tt.repeat("a-b", "from decimal import Decimal as D; a = D('1.0');
> b = D('0.9999999999')")
> [0.14685526219517442, 0.12909696344064514, 0.12646059371189722]
>
> A factor of 3, as S. Krah, the cdecimal author, claimed

I concede the point.  But I was "sincere" in my doubt.

What I'm curious about now is 1) how much the various operators vary in
that 3:1 ratio  and 2) how much the overhead portions are using of that
time. 

I have to assume that timeit.repeat doesn't count the time spent in its
second argument, right?  Because converting a string to a Decimal should
be much faster than converting one to float.  But what about the
overhead of eval(), or whatever it uses?  Is the "a-b" converted to byte
code just once?  Or is it recompiled each time through tje loop?

I have to admit not spending much time in timeit();  I usually end up
timing things with my own loops.  So i'd really like to understand how
overhead is figured.

-- 

DaveA