built-in pow() vs. math.pow()

I sometimes make use of the fact that the built-in pow() function has an optional third argument for modulo calculation, which is handy when dealing with tasks from number theory, very large numbers, problems from Project Euler, etc. I was unpleasantly surprised that math.pow() does not have thi

Re: built-in pow() vs. math.pow()

Andreas Eisele schrieb am Donnerstag, 30. März 2023 um 11:16:02 UTC+2: > I sometimes make use of the fact that the built-in pow() function has an > optional third argument for modulo calculation, which is handy when dealing > with tasks from number theory, very large numbers, prob

Tremendous slowdown due to garbage collection

he disadvantages of such a setting would be apparent. Thanks a lot for your consideration, and best regards, Andreas -- Dr. Andreas Eisele,Senior Researcher DFKI GmbH, Language Technology Lab, [EMAIL PROTECTED] Saarland UniversityComputational Linguistics Stuhlsat

Re: Tremendous slowdown due to garbage collection

I should have been more specific about possible fixes. > > python2.5 -m timeit 'gc.disable();l=[(i,) for i in range(200)]' > > 10 loops, best of 3: 662 msec per loop > > > python2.5 -m timeit 'gc.enable();l=[(i,) for i in range(200)]' > > 10 loops, best of 3: 15.2 sec per loop > > In the l

Re: Tremendous slowdown due to garbage collection

Sorry, I have to correct my last posting again: > > Disabling the gc may not be a good idea in a real application; I suggest > > you to play with the gc.set_threshold function and set larger values, at > > least while building the dictionary. (700, 1000, 10) seems to yield good > > results. > > py

Re: Tremendous slowdown due to garbage collection

> Martin said that the default settings for the cyclic gc works for most > people. I agree. > Your test case has found a pathologic corner case which is *not* > typical for common application but typical for an artificial benchmark. I agree that my "corner" is not typical, but I strongly disagr