Mailman 3 Proposed change to how YTArray handles sums and differences with zero - yt-dev

newer
[ANN] xs 1.0: The next generation...

Proposed change to how YTArray handles sums and differences with zero

older
Pull request triage today at 1:00...

Nathan Goldbaum

31 Mar 2016 31 Mar '16

10:39 p.m.

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

Attachments:

attachment.html (text/html — 2.1 KB)

Show replies by date

Cameron Hummels

31 Mar 31 Mar

10:57 p.m.

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? 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? On Thu, Mar 31, 2016 at 12:39 PM, Nathan Goldbaum 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@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

Nathan Goldbaum

11:01 p.m.

On Thu, Mar 31, 2016 at 2:57 PM, Cameron Hummels 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 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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Cameron Hummels

11:07 p.m.

...

...
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 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@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@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 http://chummels.org

Nathan Goldbaum

11:25 p.m.

On Thu, Mar 31, 2016 at 3:07 PM, Cameron Hummels 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
...
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@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@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 http://chummels.org

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

John ZuHone

11:52 p.m.

+1 John ZuHone Harvard-Smithsonian Center for Astrophysics 60 Garden St., MS-67 Cambridge, MA 02138 (w) 617-496-1816 (m) 781-708-5004 jzuhone@cfa.harvard.edu jzuhone@gmail.com http://www.jzuhone.com

...

On Mar 31, 2016, at 4:25 PM, Nathan Goldbaum wrote:

...
On Thu, Mar 31, 2016 at 3:07 PM, Cameron Hummels 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 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@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@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 http://chummels.org

_______________________________________________ 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

2946

Age (days ago)

2946

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Cameron Hummels
John ZuHone
Nathan Goldbaum

Proposed change to how YTArray handles sums and differences with zero

Nathan Goldbaum

Cameron Hummels

Nathan Goldbaum

Cameron Hummels

Nathan Goldbaum

John ZuHone

tags

participants (3)