From parthasarathi.pal at gmail.com Wed Sep 9 13:27:47 2020 From: parthasarathi.pal at gmail.com (Partha Sarathi Pal) Date: Wed, 9 Sep 2020 22:57:47 +0530 Subject: [AstroPy] Enquiry about origin change in wcs.all_world2pix Message-ID: Hi, I have a query about wcs.all_world2pix I am trying to make a skymap plot. see the attached files. I made the wcs projection. In wcs projection origin is taken as lower left corner. Now I want to plot some coordinates on skymap with wcs.all_world2pix command. see the magenta and white diamond in the plot. starloc = wcs.all_world2pix([[Ra_obj, Dec_obj]],0,maxiter=20, tolerance=1.0e-4, adaptive=False, detect_divergence=False, quiet=False) https://docs.astropy.org/en/stable/api/astropy.wcs.WCS.html#astropy.wcs.WCS.all_world2pix see this link/ screen shot. The origin is upper left in all_world2pix code. In wcs plot or skymap plot origin is lower left corner. This can give wrong value of coordinates to pixels. For this reason some standard sources are placed in different places. Am I correct? Partha -- Partha Sarathi Pal Room No- 106, Haibinhonglou - 18 School of Physics & Astrophysics Sun Yat Sen University, Zhuhai Campus Da Xue Lu, Tangjia, Zhuhai, Guangdong, 519082, China -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2020-09-09 at 21.48.54.png Type: image/png Size: 173493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2020-09-09 at 21.43.47.png Type: image/png Size: 288971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2020-09-09 at 21.43.39.png Type: image/png Size: 147826 bytes Desc: not available URL: From erik.tollerud at gmail.com Thu Sep 17 00:42:28 2020 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 17 Sep 2020 00:42:28 -0400 Subject: [AstroPy] Astropy v4.1rc2 ready for testing Message-ID: Hello all, At long last the second release candidate (RC) for Astropy v4.1 is ready for testing. Astute observers may have seen this was out in source form a few weeks ago, but the wheels-building infrastructure is back in action, and the RC is is now available for general testing via: https://pypi.python.org/pypi/astropy/4.1rc2 You should be able to install the RC by doing: pip install astropy --pre or pip install astropy==4.1rc2 You can find the documentation corresponding to this release at: https://docs.astropy.org/en/v4.1rc2/ including the 'What's new in v4.1?' page. We would appreciate if you could try out this RC and report back any success or failure via the following wiki page (note the RC2 section is where you should report now): https://github.com/astropy/astropy/wiki/astropy-v4.1-release-candidate-(RC)-Testing#rc2 For example, you can try running the test suite as mentioned on the wiki page. In addition, if you maintain any packages that use astropy, please check that your package(s) works well with this RC and let us know if there are any issues or whether everything works fine. There is a section to list packages that work/don't work at the bottom of the wiki page. Please also open an issue in the astropy core package issue tracker for any issues you encounter (and open separate issues for separate problems you run into). If you use conda, be sure to either remove the existing conda astropy package or make a new environment before installing the RC. Note that there are no conda packages for the RC. If all goes well we should have the long-delayed 4.1 out the door very soon! --- Erik T -------------- next part -------------- An HTML attachment was scrubbed... URL: From kellecruz at gmail.com Fri Sep 18 15:45:04 2020 From: kellecruz at gmail.com (Kelle Cruz) Date: Fri, 18 Sep 2020 15:45:04 -0400 Subject: [AstroPy] Fwd: Learn to work with astronomical data with SQL and Pandas In-Reply-To: <2146048D-48DA-48AA-8A27-FB0A192883F8@ucdavis.edu> References: <2146048D-48DA-48AA-8A27-FB0A192883F8@ucdavis.edu> Message-ID: See below for an exciting new workshop opportunity for astronomers! - Kelle ---------- Forwarded message --------- From: K. Azalee Bostroem Date: Wed, Sep 16, 2020 at 2:42 PM Dear Colleagues, The Astronomy Curriculum Development Committee (ACDC) is excited to announce a community pilot of the Data Carpentry workshop for Astronomers. We invite you to join the pilot by applying here . What is Data Carpentry for Astronomers? The astronomy-tailored curriculum is designed to provide astronomers with essential skills for data-intensive analysis and visualization. The curriculum focuses on: - building complex SQL queries using Astroquery - working with the retrieved data in Astropy Tables and Pandas data frames - storing the data locally for future use - communicating the results with clear and compelling figures using Matplotlib Who can attend the pilot workshop? This pilot workshop is designed to vet and improve the curriculum before the lessons are prepared for wider distribution. In particular, we seek participation from learners: - at all stages of their education and careers - with knowledge equivalent to the Software Carpentry Python Curriculum : - the ability to write a function in Python - familiarity with Python built-in types such as lists and dictionaries - the ability to navigate directories using the command line. In addition, we welcome participants who are familiar with the concepts presented and would like to provide comprehensive feedback on the lessons. How do I participate? The workshop will occur over five half days, from Monday, November 16th to Friday November 20th, from 1 - 5 PM Eastern Time daily. We request that all applicants plan to attend the entirety of the workshop and expect to complete follow-up surveys and feedback requests. We invite you to apply to join the pilot by submitting the following form: https://www.eventbrite.com/e/astronomy-pilot-data-carpentry-workshop-tickets-119504125055 We expect to support 15 learners, on a first come first serve basis with preference given to people involved in The Carpentries community. First round applicants will be notified of their acceptance on October 1. If you have any questions, please feel free to email Azalee Bostroem ( kabostroem at ucdavis.edu). The curriculum development is supported by an American Institute of Physics Venture Partnership Fund awarded to the AAS. Sincerely, ACDC Azalee Bostroem (Project Lead; co-PI) Allen Downey (Lead Developer) Erin Becker (Carpentries Liaison) Rodolfo Montez (AAS Liaison; co-PI) Phil Rosenfield (Development Team) Brett Morris (Development Team) -------------- next part -------------- An HTML attachment was scrubbed... URL: From long at stsci.edu Sat Sep 19 12:22:19 2020 From: long at stsci.edu (Knox Long) Date: Sat, 19 Sep 2020 16:22:19 +0000 Subject: [AstroPy] Updating WCS Message-ID: Given an image containing a set of Gaia stars for which I know their image position, are there astropy routines for getting the plate solution and creating a proper WCS for the image. A linear solution should be quite sufficient. Thanks, Knox -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrianmpw at gmail.com Sat Sep 19 15:13:39 2020 From: adrianmpw at gmail.com (Adrian Price-Whelan) Date: Sat, 19 Sep 2020 15:13:39 -0400 Subject: [AstroPy] Updating WCS In-Reply-To: References: Message-ID: Hi Knox, This routine might help: https://docs.astropy.org/en/stable/api/astropy.wcs.utils.fit_wcs_from_points.html But others should chime in -- I'm definitely not a WCS expert! best, Adrian On Sat, Sep 19, 2020 at 12:43 PM Knox Long wrote: > Given an image containing a set of Gaia stars for which I know their image > position, are there astropy routines for getting the plate solution and > creating a proper WCS for the image. A linear solution should be quite > sufficient. > > > > Thanks, > > Knox > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adrian M. Price-Whelan Flatiron Institute, NYC http://adrn.github.io (he / him) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihail.cara at gmail.com Sun Sep 20 12:12:37 2020 From: mihail.cara at gmail.com (AGN Gazer) Date: Sun, 20 Sep 2020 16:12:37 +0000 Subject: [AstroPy] AstroPy Digest, Vol 168, Issue 4 In-Reply-To: References: Message-ID: To the best of my knowledge, there no such astropy routines. I suggest you try https://github.com/spacetelescope/tweakwcs Mihai ________________________________ From: AstroPy on behalf of astropy-request at python.org Sent: Sunday, September 20, 2020 12:00:03 PM To: astropy at python.org Subject: AstroPy Digest, Vol 168, Issue 4 Send AstroPy mailing list submissions to astropy at python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman/listinfo/astropy or, via email, send a message with subject or body 'help' to astropy-request at python.org You can reach the person managing the list at astropy-owner at python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of AstroPy digest..." Today's Topics: 1. Updating WCS (Knox Long) 2. Re: Updating WCS (Adrian Price-Whelan) ---------------------------------------------------------------------- Message: 1 Date: Sat, 19 Sep 2020 16:22:19 +0000 From: Knox Long To: "astropy at python.org" Subject: [AstroPy] Updating WCS Message-ID: Content-Type: text/plain; charset="utf-8" Given an image containing a set of Gaia stars for which I know their image position, are there astropy routines for getting the plate solution and creating a proper WCS for the image. A linear solution should be quite sufficient. Thanks, Knox -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sat, 19 Sep 2020 15:13:39 -0400 From: Adrian Price-Whelan To: Astronomical Python mailing list Subject: Re: [AstroPy] Updating WCS Message-ID: Content-Type: text/plain; charset="utf-8" Hi Knox, This routine might help: https://docs.astropy.org/en/stable/api/astropy.wcs.utils.fit_wcs_from_points.html But others should chime in -- I'm definitely not a WCS expert! best, Adrian On Sat, Sep 19, 2020 at 12:43 PM Knox Long wrote: > Given an image containing a set of Gaia stars for which I know their image > position, are there astropy routines for getting the plate solution and > creating a proper WCS for the image. A linear solution should be quite > sufficient. > > > > Thanks, > > Knox > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adrian M. Price-Whelan Flatiron Institute, NYC http://adrn.github.io (he / him) -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ AstroPy mailing list AstroPy at python.org https://mail.python.org/mailman/listinfo/astropy ------------------------------ End of AstroPy Digest, Vol 168, Issue 4 *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From knoxlong at gmail.com Sun Sep 20 16:24:39 2020 From: knoxlong at gmail.com (Knox Long) Date: Sun, 20 Sep 2020 15:24:39 -0500 Subject: [AstroPy] Updating WCS In-Reply-To: References: Message-ID: Thank you, Adrian. I may have gotten this new feature In astropy to work. On Sat, Sep 19, 2020 at 2:14 PM Adrian Price-Whelan wrote: > Hi Knox, > > This routine might help: > > https://docs.astropy.org/en/stable/api/astropy.wcs.utils.fit_wcs_from_points.html > > But others should chime in -- I'm definitely not a WCS expert! > > best, > Adrian > > On Sat, Sep 19, 2020 at 12:43 PM Knox Long wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Given an image containing a set of Gaia stars for which I know their >> image position, are there astropy routines for getting the plate solution >> and creating a proper WCS for the image. A linear solution should >> >> be quite sufficient. >> >> >> >> >> >> Thanks, >> >> >> Knox >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> AstroPy mailing list >> >> >> AstroPy at python.org >> >> >> https://mail.python.org/mailman/listinfo/astropy > > >> >> >> > > -- > Adrian M. Price-Whelan > Flatiron Institute, NYC > http://adrn.github.io > (he / him) > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at python.org > > https://mail.python.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Tue Sep 22 11:11:03 2020 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 22 Sep 2020 11:11:03 -0400 Subject: [AstroPy] IDEA proposal results Message-ID: Hello all, I?m happy to announce the outcome of the Inclusion, Diversity, and Equity in Astropy proposal process. As we discussed last month, this open proposal process involved submitting proposals on github and community discussion to arrive at a conclusion which proposal to fund. You can see the full list of proposals here: https://github.com/astropy/astropy-project/labels/inclusion-diversity-empowerment and if you?re interested you can view some of the overall discussion either on the mailing list thread or in the #project channel of the Astropy Slack. In the end, those who participated in the discussion broadly arrived at a consensus of the following ranking: 1. Outreachy (https://github.com/astropy/astropy-project/pull/124) 2. WoCCode (https://github.com/astropy/astropy-project/pull/130) 3. PASEA (https://github.com/astropy/astropy-project/pull/128) 4. One-stop shop (https://github.com/astropy/astropy-project/pull/121) (Note there is one more proposal that is not listed because it did not ask for funding and thus didn?t enter into the ranking discussion.) Based on the budgets and available funding, this means the *first 2* will receive funding - congratulations to Brigitta, Lia, and their respective teams! Given the success of this process, it is quite possible there will be further calls in future years, so we encourage everyone to try again next round if possible. Also, we welcome any feedback on this collaborative selection process as we are considering using it, or something similar, for future funding decisions. For the Coordination Committee and the Interim Finance Committee, Erik Tollerud -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathaniel.j.livesey at jpl.nasa.gov Sat Sep 26 23:57:43 2020 From: nathaniel.j.livesey at jpl.nasa.gov (Livesey, Nathaniel J (US 3290)) Date: Sun, 27 Sep 2020 03:57:43 +0000 Subject: [AstroPy] Obscure question on subclassing units.Quantity Message-ID: <3B607A22-D757-4E2F-9B02-992F6A3BD30A@jpl.nasa.gov> Dear all, I?ve subclassed astropy.Quantity (following, I believe, the various rules discussed for that in the astropy and numpy documentation). Specifically, I?m implementing ?dual algebra" (for computing values and Jacobians simultaneously, see the Wikipedia article on automatic differentiation if you?re curious). It?s mostly working pretty well. However, I?m having trouble getting it to invoke my __array_ufunc__ under certain circumstances, and I think it?s defaulting to the units.Quantity method. Specifically, if ?x? is an instance of my new ?dual? class, then, saying: y = x * units.m (where units is astropy.units), my __array_ufunc__ is not invoked, thus I never get to my class? multiply or rmultiply method. The consequence is that the Jacobian information attached to x doesn?t get handled correctly before being transferred to y. If instead I do y = x * (1.0*units.m) or y = units.m * x then my __array_ufunc__ does get invoked, and everything works fine. However, while this is arguably a workaround it?s unsatisfactory, and highly undesirable to require any ?users? of my new class (mostly me I admit) to remember to do it that way. The consequences of forgetting are such that it?s hard to track down the place where the mistake was made. (I?ve not yet gotten round to overloading <<, but I still want the above to work.) Does anyone have a suggestion of how I can get my __array_ufunc__ to be invoked in this case? Thanks, Nathaniel P.S. Many thanks, again, for astropy.units/astropy.Quantity. Nathaniel Livesey Mail Stop 183-701, Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena, California 91109. Phone: +1 818 354-4214 Fax: +1 818 393-5065 From erik.m.bray at gmail.com Sun Sep 27 09:47:02 2020 From: erik.m.bray at gmail.com (E. Madison Bray) Date: Sun, 27 Sep 2020 15:47:02 +0200 Subject: [AstroPy] Obscure question on subclassing units.Quantity In-Reply-To: <3B607A22-D757-4E2F-9B02-992F6A3BD30A@jpl.nasa.gov> References: <3B607A22-D757-4E2F-9B02-992F6A3BD30A@jpl.nasa.gov> Message-ID: On Sun, Sep 27, 2020 at 6:04 AM Livesey, Nathaniel J (US 3290) wrote: > > Dear all, > > I?ve subclassed astropy.Quantity (following, I believe, the various rules discussed for that in the astropy and numpy documentation). Specifically, I?m implementing ?dual algebra" (for computing values and Jacobians simultaneously, see the Wikipedia article on automatic differentiation if you?re curious). > > It?s mostly working pretty well. However, I?m having trouble getting it to invoke my __array_ufunc__ under certain circumstances, and I think it?s defaulting to the units.Quantity method. Specifically, if ?x? is an instance of my new ?dual? class, then, saying: > > y = x * units.m > > (where units is astropy.units), my __array_ufunc__ is not invoked, thus I never get to my class? multiply or rmultiply method. The consequence is that the Jacobian information attached to x doesn?t get handled correctly before being transferred to y. > > If instead I do > > y = x * (1.0*units.m) > or > y = units.m * x > > then my __array_ufunc__ does get invoked, and everything works fine. However, while this is arguably a workaround it?s unsatisfactory, and highly undesirable to require any ?users? of my new class (mostly me I admit) to remember to do it that way. The consequences of forgetting are such that it?s hard to track down the place where the mistake was made. > (I?ve not yet gotten round to overloading <<, but I still want the above to work.) > > Does anyone have a suggestion of how I can get my __array_ufunc__ to be invoked in this case? Hello, Taking a step back a bit, it would be good to confirm that __array_ufunc__ is invoked when multiplying a Quantity by a Unit even with the Quantity base class. In fact it's not, so you can take some relief in knowing the issue is not particular to your code, nor subclassing Quantities in general. To confirm, I just ran a bit of code in PDB and set a breakpoint on Quantity.__array_ufunc__: >>> from astropy import units as u >>> import pdb >>> q = u.Quantity([1, 2, 3]) >>> pdb.run("q * u.m") > (1)() (Pdb) s --Call-- > astropy/units/quantity.py(934)__mul__() -> def __mul__(self, other): (Pdb) b Quantity.__array_ufunc__ Breakpoint 1 at astropy/units/quantity.py:434 (Pdb) c >>> pdb.run("u.m * q") > (1)() (Pdb) s --Call-- > astropy/units/core.py(683)__mul__() -> def __mul__(self, m): (Pdb) from .quantity import Quantity (Pdb) b Quantity.__array_ufunc__ Breakpoint 2 at astropy/units/quantity.py:434 (Pdb) c > astropy/units/quantity.py(457)__array_ufunc__() -> converters, unit = converters_and_unit(function, method, *inputs) (Pdb) where /usr/lib/python3.6/bdb.py(434)run() -> exec(cmd, globals, locals) (1)() astropy/units/core.py(697)__mul__() -> return Quantity(1, self) * m astropy/units/quantity.py(943)__mul__() -> return super().__mul__(other) > astropy/units/quantity.py(457)__array_ufunc__() -> converters, unit = converters_and_unit(function, method, *inputs) TL;DR, there happens to be a code path [1] in UnitBase.__mul__ (which is called in the `u.m * q` case) where the LHS is converted to a Quantity of magnitude 1 when multiplying by anything else that isn't a unit, so Quantity.__array_ufunc__ is called in this case. In the case of `q * u.m` it just goes straight through Quantity.__mul__ [2] which in effect just constructs a new Quantity (or appropriate subclass thereof) and assigns it the unit from the RHS. In this case there is no need to call the __array_ufunc__ method. This asymmetry could be considered an oversight, though a quantity expert should comment on that. In the meantime, I found a quick workaround for this *specific* case by overriding __mul__ in a Quantity subclass: >>> class Subquantity(u.Quantity): ... def __array_ufunc__(self, function, method, *inputs, **kwargs): ... print('my ufunc', function, method, inputs, kwargs) ... return super().__array_ufunc__(function, method, *inputs, **kwargs) ... def __mul__(self, other): ... if isinstance(other, (u.UnitBase, str)): ... return self * u.Quantity(1., other) ... return super().__mul__(other) ... >>> q = Subquantity([1, 2, 3]) >>> q * u.m my ufunc __call__ (, ) {} Hope that helps, Madison [1] https://github.com/astropy/astropy/blob/2f9deb3677e5ec0e1336c48030ad44d4ba20f1d4/astropy/units/core.py#L683 [2] https://github.com/astropy/astropy/blob/2f9deb3677e5ec0e1336c48030ad44d4ba20f1d4/astropy/units/quantity.py#L945 From nathaniel.j.livesey at jpl.nasa.gov Sun Sep 27 12:13:22 2020 From: nathaniel.j.livesey at jpl.nasa.gov (Livesey, Nathaniel J (US 3290)) Date: Sun, 27 Sep 2020 16:13:22 +0000 Subject: [AstroPy] [EXTERNAL] Obscure question on subclassing units.Quantity In-Reply-To: References: <3B607A22-D757-4E2F-9B02-992F6A3BD30A@jpl.nasa.gov> Message-ID: Dear Madison, Thank you so much, that did it perfectly! Shortly after I?d posted I wondered if doing something with __mul__ might be the trick, but couldn?t work out what it should do in the rest of the cases. Your answer addressed that and fixed the problem, many thanks (I did __truediv__ too). Thanks again, Nathaniel P.S. Thanks for forgiving the lack of an MWE in my posting. Nathaniel Livesey Mail Stop 183-701, Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena, California 91109. Phone: +1 818 354-4214 Fax: +1 818 393-5065 > On Sep 27, 2020, at 6:47 AM, E. Madison Bray wrote: > > On Sun, Sep 27, 2020 at 6:04 AM Livesey, Nathaniel J (US 3290) > wrote: >> >> Dear all, >> >> I?ve subclassed astropy.Quantity (following, I believe, the various rules discussed for that in the astropy and numpy documentation). Specifically, I?m implementing ?dual algebra" (for computing values and Jacobians simultaneously, see the Wikipedia article on automatic differentiation if you?re curious). >> >> It?s mostly working pretty well. However, I?m having trouble getting it to invoke my __array_ufunc__ under certain circumstances, and I think it?s defaulting to the units.Quantity method. Specifically, if ?x? is an instance of my new ?dual? class, then, saying: >> >> y = x * units.m >> >> (where units is astropy.units), my __array_ufunc__ is not invoked, thus I never get to my class? multiply or rmultiply method. The consequence is that the Jacobian information attached to x doesn?t get handled correctly before being transferred to y. >> >> If instead I do >> >> y = x * (1.0*units.m) >> or >> y = units.m * x >> >> then my __array_ufunc__ does get invoked, and everything works fine. However, while this is arguably a workaround it?s unsatisfactory, and highly undesirable to require any ?users? of my new class (mostly me I admit) to remember to do it that way. The consequences of forgetting are such that it?s hard to track down the place where the mistake was made. >> (I?ve not yet gotten round to overloading <<, but I still want the above to work.) >> >> Does anyone have a suggestion of how I can get my __array_ufunc__ to be invoked in this case? > > Hello, > > Taking a step back a bit, it would be good to confirm that > __array_ufunc__ is invoked when multiplying a Quantity by a Unit even > with the Quantity base class. In fact it's not, so you can take some > relief in knowing the issue is not particular to your code, nor > subclassing Quantities in general. To confirm, I just ran a bit of > code in PDB and set a breakpoint on Quantity.__array_ufunc__: > >>>> from astropy import units as u >>>> import pdb >>>> q = u.Quantity([1, 2, 3]) >>>> pdb.run("q * u.m") >> (1)() > (Pdb) s > --Call-- >> astropy/units/quantity.py(934)__mul__() > -> def __mul__(self, other): > (Pdb) b Quantity.__array_ufunc__ > Breakpoint 1 at astropy/units/quantity.py:434 > (Pdb) c >>>> pdb.run("u.m * q") >> (1)() > (Pdb) s > --Call-- >> astropy/units/core.py(683)__mul__() > -> def __mul__(self, m): > (Pdb) from .quantity import Quantity > (Pdb) b Quantity.__array_ufunc__ > Breakpoint 2 at astropy/units/quantity.py:434 > (Pdb) c >> astropy/units/quantity.py(457)__array_ufunc__() > -> converters, unit = converters_and_unit(function, method, *inputs) > (Pdb) where > /usr/lib/python3.6/bdb.py(434)run() > -> exec(cmd, globals, locals) > (1)() > astropy/units/core.py(697)__mul__() > -> return Quantity(1, self) * m > astropy/units/quantity.py(943)__mul__() > -> return super().__mul__(other) >> astropy/units/quantity.py(457)__array_ufunc__() > -> converters, unit = converters_and_unit(function, method, *inputs) > > > TL;DR, there happens to be a code path [1] in UnitBase.__mul__ (which > is called in the `u.m * q` case) where the LHS is converted to a > Quantity of magnitude 1 when multiplying by anything else that isn't a > unit, so Quantity.__array_ufunc__ is called in this case. In the case > of `q * u.m` it just goes straight through Quantity.__mul__ [2] which > in effect just constructs a new Quantity (or appropriate subclass > thereof) and assigns it the unit from the RHS. In this case there is > no need to call the __array_ufunc__ method. > > This asymmetry could be considered an oversight, though a quantity > expert should comment on that. > > In the meantime, I found a quick workaround for this *specific* case > by overriding __mul__ in a Quantity subclass: > >>>> class Subquantity(u.Quantity): > ... def __array_ufunc__(self, function, method, *inputs, **kwargs): > ... print('my ufunc', function, method, inputs, kwargs) > ... return super().__array_ufunc__(function, method, *inputs, **kwargs) > ... def __mul__(self, other): > ... if isinstance(other, (u.UnitBase, str)): > ... return self * u.Quantity(1., other) > ... return super().__mul__(other) > ... >>>> q = Subquantity([1, 2, 3]) >>>> q * u.m > my ufunc __call__ (, > ) {} > > > Hope that helps, > > Madison > > > [1] https://urldefense.us/v3/__https://github.com/astropy/astropy/blob/2f9deb3677e5ec0e1336c48030ad44d4ba20f1d4/astropy/units/core.py*L683__;Iw!!PvBDto6Hs4WbVuu7!dk_AZRAfxu2GW5nLMiyOirNgxwSlrBxTfCEZlnv7rVEQ-q5kCWEGcfuCms2DAkUndWuuYxuLWISp$ > [2] https://urldefense.us/v3/__https://github.com/astropy/astropy/blob/2f9deb3677e5ec0e1336c48030ad44d4ba20f1d4/astropy/units/quantity.py*L945__;Iw!!PvBDto6Hs4WbVuu7!dk_AZRAfxu2GW5nLMiyOirNgxwSlrBxTfCEZlnv7rVEQ-q5kCWEGcfuCms2DAkUndWuuY1v5ZYtM$ > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://urldefense.us/v3/__https://mail.python.org/mailman/listinfo/astropy__;!!PvBDto6Hs4WbVuu7!dk_AZRAfxu2GW5nLMiyOirNgxwSlrBxTfCEZlnv7rVEQ-q5kCWEGcfuCms2DAkUndWuuY0U0ChBb$ From erik.m.bray at gmail.com Mon Sep 28 06:52:12 2020 From: erik.m.bray at gmail.com (E. Madison Bray) Date: Mon, 28 Sep 2020 12:52:12 +0200 Subject: [AstroPy] [EXTERNAL] Obscure question on subclassing units.Quantity In-Reply-To: References: <3B607A22-D757-4E2F-9B02-992F6A3BD30A@jpl.nasa.gov> Message-ID: On Sun, Sep 27, 2020 at 6:13 PM Livesey, Nathaniel J (US 3290) wrote: > > Dear Madison, > > Thank you so much, that did it perfectly! Shortly after I?d posted I wondered if doing something with __mul__ might be the trick, but couldn?t work out what it should do in the rest of the cases. Your answer addressed that and fixed the problem, many thanks (I did __truediv__ too). > > Thanks again, > > Nathaniel > > P.S. Thanks for forgiving the lack of an MWE in my posting. Yeah, I thought of asking one, but it was just as easy to confirm that the existing behavior of `Quantity * Unit` reproduces the behavior you described. Also, based on your description of what you're doing I could picture the use case. I imagine you want to be able to track all operations performed on a Quantity in order to perform automatic differentiation (I'd be curious to see the rest of the code though). I still wonder if something shouldn't be done on the Astropy end to address this inconsistency. The current implementation of `Quantity * Unit` makes sense to me as an optimization--adding a unit to a Quantity should be fast and not go through unnecessary steps. But maybe in the case of Quantity subclasses--especially those that implement their own __array_ufunc__, it should be more generalized. > Nathaniel Livesey > Mail Stop 183-701, Jet Propulsion Laboratory > 4800 Oak Grove Drive, Pasadena, California 91109. > Phone: +1 818 354-4214 Fax: +1 818 393-5065 > > > On Sep 27, 2020, at 6:47 AM, E. Madison Bray wrote: > > > > On Sun, Sep 27, 2020 at 6:04 AM Livesey, Nathaniel J (US 3290) > > wrote: > >> > >> Dear all, > >> > >> I?ve subclassed astropy.Quantity (following, I believe, the various rules discussed for that in the astropy and numpy documentation). Specifically, I?m implementing ?dual algebra" (for computing values and Jacobians simultaneously, see the Wikipedia article on automatic differentiation if you?re curious). > >> > >> It?s mostly working pretty well. However, I?m having trouble getting it to invoke my __array_ufunc__ under certain circumstances, and I think it?s defaulting to the units.Quantity method. Specifically, if ?x? is an instance of my new ?dual? class, then, saying: > >> > >> y = x * units.m > >> > >> (where units is astropy.units), my __array_ufunc__ is not invoked, thus I never get to my class? multiply or rmultiply method. The consequence is that the Jacobian information attached to x doesn?t get handled correctly before being transferred to y. > >> > >> If instead I do > >> > >> y = x * (1.0*units.m) > >> or > >> y = units.m * x > >> > >> then my __array_ufunc__ does get invoked, and everything works fine. However, while this is arguably a workaround it?s unsatisfactory, and highly undesirable to require any ?users? of my new class (mostly me I admit) to remember to do it that way. The consequences of forgetting are such that it?s hard to track down the place where the mistake was made. > >> (I?ve not yet gotten round to overloading <<, but I still want the above to work.) > >> > >> Does anyone have a suggestion of how I can get my __array_ufunc__ to be invoked in this case? > > > > Hello, > > > > Taking a step back a bit, it would be good to confirm that > > __array_ufunc__ is invoked when multiplying a Quantity by a Unit even > > with the Quantity base class. In fact it's not, so you can take some > > relief in knowing the issue is not particular to your code, nor > > subclassing Quantities in general. To confirm, I just ran a bit of > > code in PDB and set a breakpoint on Quantity.__array_ufunc__: > > > >>>> from astropy import units as u > >>>> import pdb > >>>> q = u.Quantity([1, 2, 3]) > >>>> pdb.run("q * u.m") > >> (1)() > > (Pdb) s > > --Call-- > >> astropy/units/quantity.py(934)__mul__() > > -> def __mul__(self, other): > > (Pdb) b Quantity.__array_ufunc__ > > Breakpoint 1 at astropy/units/quantity.py:434 > > (Pdb) c > >>>> pdb.run("u.m * q") > >> (1)() > > (Pdb) s > > --Call-- > >> astropy/units/core.py(683)__mul__() > > -> def __mul__(self, m): > > (Pdb) from .quantity import Quantity > > (Pdb) b Quantity.__array_ufunc__ > > Breakpoint 2 at astropy/units/quantity.py:434 > > (Pdb) c > >> astropy/units/quantity.py(457)__array_ufunc__() > > -> converters, unit = converters_and_unit(function, method, *inputs) > > (Pdb) where > > /usr/lib/python3.6/bdb.py(434)run() > > -> exec(cmd, globals, locals) > > (1)() > > astropy/units/core.py(697)__mul__() > > -> return Quantity(1, self) * m > > astropy/units/quantity.py(943)__mul__() > > -> return super().__mul__(other) > >> astropy/units/quantity.py(457)__array_ufunc__() > > -> converters, unit = converters_and_unit(function, method, *inputs) > > > > > > TL;DR, there happens to be a code path [1] in UnitBase.__mul__ (which > > is called in the `u.m * q` case) where the LHS is converted to a > > Quantity of magnitude 1 when multiplying by anything else that isn't a > > unit, so Quantity.__array_ufunc__ is called in this case. In the case > > of `q * u.m` it just goes straight through Quantity.__mul__ [2] which > > in effect just constructs a new Quantity (or appropriate subclass > > thereof) and assigns it the unit from the RHS. In this case there is > > no need to call the __array_ufunc__ method. > > > > This asymmetry could be considered an oversight, though a quantity > > expert should comment on that. > > > > In the meantime, I found a quick workaround for this *specific* case > > by overriding __mul__ in a Quantity subclass: > > > >>>> class Subquantity(u.Quantity): > > ... def __array_ufunc__(self, function, method, *inputs, **kwargs): > > ... print('my ufunc', function, method, inputs, kwargs) > > ... return super().__array_ufunc__(function, method, *inputs, **kwargs) > > ... def __mul__(self, other): > > ... if isinstance(other, (u.UnitBase, str)): > > ... return self * u.Quantity(1., other) > > ... return super().__mul__(other) > > ... > >>>> q = Subquantity([1, 2, 3]) > >>>> q * u.m > > my ufunc __call__ (, > > ) {} > > > > > > Hope that helps, > > > > Madison > > > > > > [1] https://urldefense.us/v3/__https://github.com/astropy/astropy/blob/2f9deb3677e5ec0e1336c48030ad44d4ba20f1d4/astropy/units/core.py*L683__;Iw!!PvBDto6Hs4WbVuu7!dk_AZRAfxu2GW5nLMiyOirNgxwSlrBxTfCEZlnv7rVEQ-q5kCWEGcfuCms2DAkUndWuuYxuLWISp$ > > [2] https://urldefense.us/v3/__https://github.com/astropy/astropy/blob/2f9deb3677e5ec0e1336c48030ad44d4ba20f1d4/astropy/units/quantity.py*L945__;Iw!!PvBDto6Hs4WbVuu7!dk_AZRAfxu2GW5nLMiyOirNgxwSlrBxTfCEZlnv7rVEQ-q5kCWEGcfuCms2DAkUndWuuY1v5ZYtM$ > > _______________________________________________ > > AstroPy mailing list > > AstroPy at python.org > > https://urldefense.us/v3/__https://mail.python.org/mailman/listinfo/astropy__;!!PvBDto6Hs4WbVuu7!dk_AZRAfxu2GW5nLMiyOirNgxwSlrBxTfCEZlnv7rVEQ-q5kCWEGcfuCms2DAkUndWuuY0U0ChBb$ > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy