Re: [Python-Dev] int(string) (was: DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16)

Tim Peters wrote: > ... > Someone want a finite project that would _really_ help their Uncle > Timmy in his slow-motion crusade to get Python on the list of "solved > it!" languages for each problem on that magnificent site? ... > Turns out it's _not_ input speed that's the problem here, and not ev

Re: [Python-Dev] int(string)

Fredrik Lundh wrote: >does a plain > >a = -100.0 > >still work on your machine? > D'oh - I seriously broke something, then, because it didn't. funny_falcon commented on the patch in SF and suggested a change that took care of that. I've uploaded the corrected version of the patch, wh

Re: [Python-Dev] int(string)

Alan McIntyre wrote: > When running "make test" I get some errors in test_array and > test_compile that did not occur in the build from CVS. Given the inputs > to long() have '.' characters in them, I assume that these tests really > should be failing as implemented, but I haven't dug into them t

Re: [Python-Dev] int(string)

Tim Peters wrote: >[Adam Olsen] > >>https://sourceforge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470> >> >>That patch removes the division from the loop (and fixes the bugs), >>but gives only a small increase in speed. >> >In any case, I agree it _should_ fix the bugs (a

Re: [Python-Dev] int(string)

On 10/22/05, Tim Peters <[EMAIL PROTECTED]> wrote: > [Tim] > >> I assume it's the overflow-checking that's the major time sink, > > [Adam Olsen] > > Are you sure? > > No -- that's what "assume" means <0.7 wink>. For example, there's a > long chain of function calls involved in int(string) too. > >

Re: [Python-Dev] int(string)

[Tim] >> I assume it's the overflow-checking that's the major time sink, [Adam Olsen] > Are you sure? No -- that's what "assume" means <0.7 wink>. For example, there's a long chain of function calls involved in int(string) too. >

Re: [Python-Dev] int(string)

> Tim Peters <[EMAIL PROTECTED]> writes: > > > Turns out it's _not_ input speed that's the problem here, and not even > > mainly the speed of integer mod: the bulk of the time is spent in > > int(string) (and, yes, that's also far more important to the problem > > Neal was looking at than list.app

Re: [Python-Dev] int(string)

[Tim] ... >> int('10200202220122211', 3) = 0 I should have added that all those examples simply used 2**32 as input, expressed as a string in the input base. They're not the only failing cases; e.g., this is also obviously wrong: >>> int('10200202220122212', 3) 1 ... >> The challenge (

Re: [Python-Dev] int(string)

Tim Peters <[EMAIL PROTECTED]> writes: > Turns out it's _not_ input speed that's the problem here, and not even > mainly the speed of integer mod: the bulk of the time is spent in > int(string) (and, yes, that's also far more important to the problem > Neal was looking at than list.append time).