On Thu, Mar 31, 2016 at 3:07 PM, Cameron Hummels <chummels@gmail.com> wrote:
 
 

If that is what you're suggesting, it seems fine to me, but couldn't we just turn off the `start` argument to solve this problem without your proposed change?

Since sum is a python builtin, we have no control over it.

But I thought you said that the python builtin sum had an *optional* start argument, which defaults to zero.  Isn't it possible to (1) make it not used or (2) default it to the first value of the YTArray?


It's optional, but if you don't specify it, `sum` uses 0. See: https://docs.python.org/2/library/functions.html#sum

We have no control over this, it all happens at the C level in python itself. If you step though the test script I attached in my original e-mail you'll see this for yourself.
 

Cameron

 
 

On Thu, Mar 31, 2016 at 12:39 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,

Today a student I am working with ran into an issue illustrated by the following test script:

    from yt.units import cm

    arr = [1, 2, 3]*cm
    sum(arr)

Right now this errors out with the following traceback:


The reason for this is that the python builtin sum command has an optional `start` argument, which defaults to 0. The error is happening because the first element of the array (1 km) has different units from 0.

Sum is probably not the best way to do this, but I think erroring out here is an overly harsh user experience, especially for a user who is new to python and might not be aware of the possible performance implications of using sum on a large array.

Incidentally, an analogous script with astropy quantities does work:

    from astropy.units import cm

    arr = [1, 2, 3]*cm
    sum(arr)

This is because astropy's quantities let you add zero (and just zero, no other float or integer will work) to an array or quantity with any units.

On a philosophical level, the difference between 0 cm and 0 is not particular useful in practice, and operationally allowing 0 to be added or subtracted from YTArray instances without erroring out should not have any concrete implications for real programs, since until now it has raised an error. To be honest, I'm now regretting not thinking carefully about this until now....

Since this is a change to how YTArray, which is fundamental to yt's internals, I wanted to check with the list before proposing a pull request that implements this change.

Does anyone have any objections?

Thanks!

-Nathan

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org




--
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org




--
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org