[Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)
tim.hochberg at cox.net
Thu Feb 9 13:44:06 CST 2006
Travis Oliphant wrote:
> Tim Hochberg wrote:
>> That is, not only did all of the incorrect end cases go away, it
>> actually got marginally faster. Why it got faster I can't say,
>> there's not much to be gained in second guessing an optimizing
>> compiler. It's quite possible that this may be compiler dependant, so
>> I'd be interested in the results with other compilers. Also, I only
>> sampled a small chunk of the input space of arange, so if you have
>> some other failing input values, please send them to me and I can
>> test them and see if this change fixes them also.
>> I didn't mess with the complex version of fill yet. Is that just
>> there to support arange(0, 100, 2, dtype=complex), or is there some
>> other use for _fill besides arange?
> This is a simple change and one we could easily do. The complex
> versions are there to support complex arange? There are no other uses
> "currently" for fill.
Just for truth in advertising, after the last svn update I did, the
speed advantage mostly went away:
arange(10000) took 2.27355292363 seconds for 100000 reps
arange(10000.0) took 4.39404812623 seconds for 100000 reps
arange(10000,dtype=complex) took 4.01601209092 seconds for 100000 reps
# multiply instead of repeated add.
arange(10000) took 2.20859410903 seconds for 100000 reps
arange(10000.0) took 4.34652784083 seconds for 100000 reps
arange(10000,dtype=complex) took 6.02266433304 seconds for 100000 reps
I'm not sure if this is a result of the changes that you made stripping
out the unneeded 'i' or if my machine was in some sort of different
state or what.
Note that I modified the complex fills as well now and they are much
slower. Is it possible for delta to be complex? If not, we could speed
up the complex case a little by exploiting the fact that delta.real is
always zero. If in, in addition, we can assume both that start.imag is
zero and that the array is zeroed out to start with, we could speed
things up some more.
This seems like a no-brainer for floats (and a noop for ints) since it
alleviates the problem of arange(start,stop,step)[-1] sometimes being >=
stop without costing anything performance wise. (I don't know that it
cures the problem, but it seems to make it a lot less likely). For
complex the situation is more, uh, complex. I'd like to make it since in
general I'd rather be right than fast. Still, it's a signifigant
performance hit in this case.
> Although you could use it with two equal values to fill an array with
> the same thing quickly. I have yet to test a version of ones using
> fill against the current implementation which adds 1 to a zeros array.
> Thanks for the changes.
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion