Proposed change to how YTArray handles sums and differences with zero
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
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 <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:
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
On Thu, Mar 31, 2016 at 2:57 PM, Cameron Hummels <chummels@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@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@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
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@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@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
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:
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
+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 <nathan12343@gmail.com> wrote:
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:
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
participants (3)
-
Cameron Hummels -
John ZuHone -
Nathan Goldbaum