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

[Cameron Hummels]

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


Cameron



>
>
>>
>> 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
>>
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160331/5b198781/attachment.html>