[yt-dev] Proposed change to how YTArray handles sums and differences with zero

[Nathan Goldbaum]

On Thu, Mar 31, 2016 at 2:57 PM, Cameron Hummels <chummels at gmail.com> wrote:

> So to be explicit, since you never actually say it, you are proposing to
> change the YTArray behavior to allow for adding a dimensionless 0 to a
> unitful array without erroring?
>

Sorry, yes. I want to make this script run without erroring out:

from yt.units import km

3*km + 0


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


>
> On Thu, Mar 31, 2016 at 12:39 PM, Nathan Goldbaum <nathan12343 at 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:
>>
>> http://paste.yt-project.org/show/6378/
>>
>> 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 at 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
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160331/d3c8e0e7/attachment.html>