Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

[Tim H. <tim...@co...>]

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:

# baseline
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.

Thoughts?

-tim

> 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.
>
> -Travis
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>