From ghang.naoc at gmail.com Thu Nov 1 08:46:08 2012 From: ghang.naoc at gmail.com (gonghang.naoc) Date: Thu, 1 Nov 2012 20:46:08 +0800 Subject: [AstroPy] how to make density plot and contour via python? Message-ID: hi,anybody knows the details?I have about 1e+7 discrete points. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrianmpw at gmail.com Thu Nov 1 10:36:58 2012 From: adrianmpw at gmail.com (Adrian Price-Whelan) Date: Thu, 1 Nov 2012 10:36:58 -0400 Subject: [AstroPy] how to make density plot and contour via python? In-Reply-To: References: Message-ID: <5F383074-C760-4E8A-95C3-C4F0B7D6AAA6@gmail.com> Check out this example: http://micropore.wordpress.com/2011/10/01/2d-density-plot-or-2d-histogram/ And also this code: https://gist.github.com/3993992 - Adrian On Nov 1, 2012, at 8:46 AM, gonghang.naoc wrote: > hi,anybody knows the details?I have about 1e+7 discrete points. Thanks! > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Adrian Price-Whelan Department of Astronomy Columbia University -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.parejko at yale.edu Thu Nov 1 11:32:47 2012 From: john.parejko at yale.edu (John K. Parejko) Date: Thu, 1 Nov 2012 11:32:47 -0400 Subject: [AstroPy] how to make density plot and contour via python? In-Reply-To: <5F383074-C760-4E8A-95C3-C4F0B7D6AAA6@gmail.com> References: <5F383074-C760-4E8A-95C3-C4F0B7D6AAA6@gmail.com> Message-ID: <319B974C-F374-4243-B004-56EFDE0A38F5@yale.edu> I am a big fan of the hexbin matplotlib module. http://matplotlib.org/examples/pylab_examples/hexbin_demo.html Setting mincnt=1 gets rid of the "last" contour, and you can change the alpha level to overlay histograms on the same plot and have underlying layers visible. John On 1Nov 2012, at 10:36, Adrian Price-Whelan wrote: > Check out this example: > http://micropore.wordpress.com/2011/10/01/2d-density-plot-or-2d-histogram/ > > And also this code: > https://gist.github.com/3993992 > > - Adrian > > On Nov 1, 2012, at 8:46 AM, gonghang.naoc wrote: > >> hi,anybody knows the details?I have about 1e+7 discrete points. Thanks! >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > -- > Adrian Price-Whelan > Department of Astronomy > Columbia University > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- ************************* John Parejko john.parejko at yale.edu http://www.astro.yale.edu/~jp727/ 203 432-9759 JWG 465 Department of Physics Yale University New Haven, CT ************************** From vanderplas at astro.washington.edu Thu Nov 1 14:22:04 2012 From: vanderplas at astro.washington.edu (Jake Vanderplas) Date: Thu, 01 Nov 2012 11:22:04 -0700 Subject: [AstroPy] Announcing astroML version 0.1 Message-ID: <5092BDCC.8030606@astro.washington.edu> Hello, I've just released a new Python astronomy package called astroML: machine learning and data mining for astronomy & astrophysics. It's built on numpy, scipy, scikit-learn and matplotlib, and implements several more astronomical data mining and machine learning techniques from the literature. It also includes loaders for several interesting data sets (many from SDSS, but there are others as well). Importantly, it has an extensive set of example code & plots showing how these data & algorithms can be used & visualized. You can download the released code and see all 200+ examples at: http://astroML.github.com/ My hope is for astroML to become a community repository for well-written algorithms & examples of data analysis in astronomy, and be a useful resource for both research and teaching. I think this vision is complementary to the vision of astropy, and I hope the two packages can together encourage Python as the lingua franca of astronomical research. The development version of the astroML code can be found on github at http://github.com/astroML/. I would appreciate any feedback or suggestions - thanks! Jake VanderPlas From marquett at iap.fr Thu Nov 1 15:06:55 2012 From: marquett at iap.fr (Marquette Jean-Baptiste) Date: Thu, 1 Nov 2012 20:06:55 +0100 Subject: [AstroPy] Announcing astroML version 0.1 In-Reply-To: <5092BDCC.8030606@astro.washington.edu> References: <5092BDCC.8030606@astro.washington.edu> Message-ID: Hi Jake, > Hello, > I've just released a new Python astronomy package called astroML: > machine learning and data mining for astronomy & astrophysics. It's > built on numpy, scipy, scikit-learn and matplotlib, and implements > several more astronomical data mining and machine learning techniques > from the literature. It also includes loaders for several interesting > data sets (many from SDSS, but there are others as well). Importantly, > it has an extensive set of example code & plots showing how these data & > algorithms can be used & visualized. You can download the released code > and see all 200+ examples at: > > http://astroML.github.com/ > > My hope is for astroML to become a community repository for well-written > algorithms & examples of data analysis in astronomy, and be a useful > resource for both research and teaching. I think this vision is > complementary to the vision of astropy, and I hope the two packages can > together encourage Python as the lingua franca of astronomical research. > > The development version of the astroML code can be found on github at > http://github.com/astroML/. I would appreciate any feedback or > suggestions - thanks! > > Jake VanderPlas > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy GREAT job! Congrats! Cheers, Jean-Baptiste From sebas0 at gmail.com Thu Nov 1 16:34:21 2012 From: sebas0 at gmail.com (Sebastian) Date: Thu, 1 Nov 2012 17:34:21 -0300 Subject: [AstroPy] AstroPy Digest, Vol 74, Issue 1 In-Reply-To: References: Message-ID: On a followup hexbin question that I'm having some trouble with: Is there a simple way to rescale the zmin and zmax values for the colorscale in the z dimension? For example i have the following hexbin map: " https://dl.dropbox.com/u/28810956/hexbin.png", and wish to re-scale the Z data counts to 0 --> 600, instead of ~-370 --> 900? many thanks in advance, - Sebastian On Thu, Nov 1, 2012 at 2:00 PM, wrote: > Send AstroPy mailing list submissions to > astropy at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/astropy > or, via email, send a message with subject or body 'help' to > astropy-request at scipy.org > > You can reach the person managing the list at > astropy-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of AstroPy digest..." > > > Today's Topics: > > 1. how to make density plot and contour via python? (gonghang.naoc) > 2. Re: how to make density plot and contour via python? > (Adrian Price-Whelan) > 3. Re: how to make density plot and contour via python? > (John K. Parejko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 1 Nov 2012 20:46:08 +0800 > From: "gonghang.naoc" > Subject: [AstroPy] how to make density plot and contour via python? > To: astropy at scipy.org > Message-ID: > JuSZqpjXijNwSiTBJyw3LUiz490Q at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hi,anybody knows the details?I have about 1e+7 discrete points. Thanks! > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/astropy/attachments/20121101/27f0d5f9/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 1 Nov 2012 10:36:58 -0400 > From: Adrian Price-Whelan > Subject: Re: [AstroPy] how to make density plot and contour via > python? > To: gonghang.naoc > Cc: astropy > Message-ID: <5F383074-C760-4E8A-95C3-C4F0B7D6AAA6 at gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Check out this example: > http://micropore.wordpress.com/2011/10/01/2d-density-plot-or-2d-histogram/ > > And also this code: > https://gist.github.com/3993992 > > - Adrian > > On Nov 1, 2012, at 8:46 AM, gonghang.naoc wrote: > > > hi,anybody knows the details?I have about 1e+7 discrete points. Thanks! > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > -- > Adrian Price-Whelan > Department of Astronomy > Columbia University > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/astropy/attachments/20121101/cf5cf0d9/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Thu, 1 Nov 2012 11:32:47 -0400 > From: "John K. Parejko" > Subject: Re: [AstroPy] how to make density plot and contour via > python? > To: Adrian Price-Whelan > Cc: astropy > Message-ID: <319B974C-F374-4243-B004-56EFDE0A38F5 at yale.edu> > Content-Type: text/plain; charset=us-ascii > > I am a big fan of the hexbin matplotlib module. > > http://matplotlib.org/examples/pylab_examples/hexbin_demo.html > > Setting mincnt=1 gets rid of the "last" contour, and you can change the > alpha level to overlay histograms on the same plot and have underlying > layers visible. > > John > > On 1Nov 2012, at 10:36, Adrian Price-Whelan wrote: > > > Check out this example: > > > http://micropore.wordpress.com/2011/10/01/2d-density-plot-or-2d-histogram/ > > > > And also this code: > > https://gist.github.com/3993992 > > > > - Adrian > > > > On Nov 1, 2012, at 8:46 AM, gonghang.naoc wrote: > > > >> hi,anybody knows the details?I have about 1e+7 discrete points. Thanks! > >> _______________________________________________ > >> AstroPy mailing list > >> AstroPy at scipy.org > >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > > Adrian Price-Whelan > > Department of Astronomy > > Columbia University > > > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > -- > ************************* > John Parejko > john.parejko at yale.edu > http://www.astro.yale.edu/~jp727/ > 203 432-9759 > JWG 465 > Department of Physics > Yale University > New Haven, CT > ************************** > > > > > > > > > ------------------------------ > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > End of AstroPy Digest, Vol 74, Issue 1 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.parejko at yale.edu Thu Nov 1 16:44:18 2012 From: john.parejko at yale.edu (John K. Parejko) Date: Thu, 1 Nov 2012 16:44:18 -0400 Subject: [AstroPy] AstroPy Digest, Vol 74, Issue 1 In-Reply-To: References: Message-ID: <6E8CB9E4-8AE3-4F22-949A-95ECC1BE7B05@yale.edu> You can specify the bins argument as the lower bound of each bin: bins = np.arange(0,600) matplotlib's help for hexbin is quite good, accessible via help within python, or the matplotlib api website: http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.hexbin John On 1Nov 2012, at 16:34, Sebastian wrote: > On a followup hexbin question that I'm having some trouble with: > Is there a simple way to rescale the zmin and zmax values for the colorscale in the z dimension? > > For example i have the following hexbin map: "https://dl.dropbox.com/u/28810956/hexbin.png", and wish to re-scale the Z data counts to 0 --> 600, instead of ~-370 --> 900? > > many thanks in advance, > - Sebastian From mrdavis at stsci.edu Thu Nov 1 16:50:06 2012 From: mrdavis at stsci.edu (Matt Davis) Date: Thu, 1 Nov 2012 16:50:06 -0400 Subject: [AstroPy] AstroPy Digest, Vol 74, Issue 1 In-Reply-To: <6E8CB9E4-8AE3-4F22-949A-95ECC1BE7B05@yale.edu> References: <6E8CB9E4-8AE3-4F22-949A-95ECC1BE7B05@yale.edu> Message-ID: I haven't tried this with hexbin specifically but it may be possible to change the colorbar limits either via the norm keyword or the vmin/vmax keywords. Best, Matt On Nov 1, 2012, at 4:44 PM, John K. Parejko wrote: > You can specify the bins argument as the lower bound of each bin: > > bins = np.arange(0,600) > > matplotlib's help for hexbin is quite good, accessible via help within python, or the matplotlib api website: > > http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.hexbin > > John > > On 1Nov 2012, at 16:34, Sebastian wrote: > >> On a followup hexbin question that I'm having some trouble with: >> Is there a simple way to rescale the zmin and zmax values for the colorscale in the z dimension? >> >> For example i have the following hexbin map: "https://dl.dropbox.com/u/28810956/hexbin.png", and wish to re-scale the Z data counts to 0 --> 600, instead of ~-370 --> 900? >> >> many thanks in advance, >> - Sebastian > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From demitri.muna at gmail.com Wed Nov 14 17:03:49 2012 From: demitri.muna at gmail.com (Demitri Muna) Date: Wed, 14 Nov 2012 17:03:49 -0500 Subject: [AstroPy] Coordinates subpackage - request for help Message-ID: <449FE904-3386-4300-AD3C-26A44DEF4583@gmail.com> Hi, We are in the process of testing the new astropy coordinates package. One test that I think would be useful is this (which Tom also mentioned): * generate 1000 ra/dec J2000 random points on the sky * convert them to, in steps, - galactic - B1950 - ecliptic - equatorial J2000 Can someone do this in IDL? The result should be * the file containing 1000 points * the resulting points at the end of the conversions * the IDL script The aim is to write a script using the coordinates package and see if there are any discrepancies. We will add this to the testing suite. I thought I'd cc the astropy list as I'm sure there are lots of people who are proficient in IDL and can probably do this pretty quickly. Cheers, Demitri _________________________________________ Demitri Muna Center for Cosmology and Particle Physics New York University http://scicoder.org _________________________________________ Demitri Muna Center for Cosmology and Particle Physics New York University http://scicoder.org From d.berry at jach.hawaii.edu Thu Nov 15 03:29:28 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 15 Nov 2012 08:29:28 +0000 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: Message-ID: On 14 November 2012 22:01, Demitri Muna wrote: > Hi, > > We are in the process of testing the new astropy coordinates package. One test that I think would be useful is this (which Tom also mentioned): > > * generate 1000 ra/dec J2000 random points on the sky > * convert them to, in steps, > - galactic > - B1950 > - ecliptic > - equatorial J2000 > > Can someone do this in IDL? The result should be > > * the file containing 1000 points > * the resulting points at the end of the conversions > * the IDL script > > The aim is to write a script using the coordinates package and see if there are any discrepancies. We will add this to the testing suite. > > I thought I'd cc the astropy list as I'm sure there are lots of people who are proficient in IDL and can probably do this pretty quickly. 1) Different conversion algorithms are always (or nearly always) going to produce different answers. So do you have a target accuracy for the astropy coordinates package? Do you want arcseconds accuracy or milli-arcsecond accuracy? The more accuracy you want, the more sophisticated the algorithms need to be. 2) Why does it need to be IDL? It's proprietary software, so many people will not use it. There are many tools in many freely available languages for creating tables of corresponding positions in different coordinate systems. For instance, I could create such a table quickly using PyAST, which since we're talking Python seems an obvious choice. 3) You include ecliptic in the list. Does the coordinates package support ecliptic? I could not see it in the code. 4) Your list of coordinate systems starts at " ra/dec J2000" and ends at "equatorial J2000" - are you making a distinction between these? And I presume you mean FK5 J2000 (there is a common usage of "J2000 RA/Dec" which uses the mean dynamical equator and equinox of the J2000 epoch as reference, which is different to FK5)? 5) Was the omission of ICRS intentional? 6) No mention of the epoch of observation. As I mentioned in another message you need to specify the epoch of observation, to be able to convert accurately to and from an FK4 RA/Dec system (which I presume is what you mean by "B1950"). Strictly, you also need the epoch of observation when converting between FK5 and ICRS, albeit the dependency on the epoch is much weaker. 7) You need to specify an equinox for the ecliptic coordinates. David From beaumont at hawaii.edu Thu Nov 15 08:04:16 2012 From: beaumont at hawaii.edu (Chris Beaumont) Date: Thu, 15 Nov 2012 08:04:16 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: Message-ID: Hi, I uploaded a script here https://gist.github.com/4078531 I made it a gist, since it sounds like it may need to be refined. cheers, chris On Thu, Nov 15, 2012 at 3:29 AM, David Berry wrote: > On 14 November 2012 22:01, Demitri Muna wrote: > > Hi, > > > > We are in the process of testing the new astropy coordinates package. > One test that I think would be useful is this (which Tom also mentioned): > > > > * generate 1000 ra/dec J2000 random points on the sky > > * convert them to, in steps, > > - galactic > > - B1950 > > - ecliptic > > - equatorial J2000 > > > > Can someone do this in IDL? The result should be > > > > * the file containing 1000 points > > * the resulting points at the end of the conversions > > * the IDL script > > > > The aim is to write a script using the coordinates package and see if > there are any discrepancies. We will add this to the testing suite. > > > > I thought I'd cc the astropy list as I'm sure there are lots of people > who are proficient in IDL and can probably do this pretty quickly. > > 1) Different conversion algorithms are always (or nearly always) going > to produce different answers. So do you have a target accuracy for the > astropy coordinates package? Do you want arcseconds accuracy or > milli-arcsecond accuracy? The more accuracy you want, the more > sophisticated the algorithms need to be. > > 2) Why does it need to be IDL? It's proprietary software, so many > people will not use it. There are many tools in many freely available > languages for creating tables of corresponding positions in different > coordinate systems. For instance, I could create such a table > quickly using PyAST, which since we're talking Python seems an obvious > choice. > > 3) You include ecliptic in the list. Does the coordinates package > support ecliptic? I could not see it in the code. > > 4) Your list of coordinate systems starts at " ra/dec J2000" and ends > at "equatorial J2000" - are you making a distinction between these? > And I presume you mean FK5 J2000 (there is a common usage of "J2000 > RA/Dec" which uses the mean dynamical equator and equinox of the J2000 > epoch as reference, which is different to FK5)? > > 5) Was the omission of ICRS intentional? > > 6) No mention of the epoch of observation. As I mentioned in another > message you need to specify the epoch of observation, to be able to > convert accurately to and from an FK4 RA/Dec system (which I presume > is what you mean by "B1950"). Strictly, you also need the epoch of > observation when converting between FK5 and ICRS, albeit the > dependency on the epoch is much weaker. > > 7) You need to specify an equinox for the ecliptic coordinates. > > David > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- ************************************ Chris Beaumont Graduate Student Institute for Astronomy University of Hawaii at Manoa 2680 Woodlawn Drive Honolulu, HI 96822 www.ifa.hawaii.edu/~beaumont ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Thu Nov 15 11:05:48 2012 From: demitri.muna at gmail.com (Demitri Muna) Date: Thu, 15 Nov 2012 11:05:48 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: Message-ID: <1FA8BF0C-C3DA-480B-969E-1E2CA684276D@gmail.com> Hi, Chris, thanks for the script! A few modifications need to be made though (see comments below). On Nov 15, 2012, at 3:29 AM, David Berry wrote: > 1) Different conversion algorithms are always (or nearly always) going > to produce different answers. So do you have a target accuracy for the > astropy coordinates package? Do you want arcseconds accuracy or > milli-arcsecond accuracy? The more accuracy you want, the more > sophisticated the algorithms need to be. To first order I'd like to see where our accuracy is and go from there. I think for a first release arcsec accuracy is probably good enough (to get this thing out the door), with the aim of better accuracy as an improvement. But let's see where we are. > 2) Why does it need to be IDL? It's proprietary software, so many > people will not use it. There are many tools in many freely available > languages for creating tables of corresponding positions in different > coordinate systems. For instance, I could create such a table > quickly using PyAST, which since we're talking Python seems an obvious > choice. This is purely for testing purposes and not meant to be released for use by anyone. I specifically chose IDL since the libraries are well-trusted and well-tested by the community. I think a selling feature would be to show that our code compares favorably with what people trust. > 3) You include ecliptic in the list. Does the coordinates package > support ecliptic? I could not see it in the code. Erik implemented the actual systems; I'll let him address that. > 4) Your list of coordinate systems starts at " ra/dec J2000" and ends > at "equatorial J2000" - are you making a distinction between these? > And I presume you mean FK5 J2000 (there is a common usage of "J2000 > RA/Dec" which uses the mean dynamical equator and equinox of the J2000 > epoch as reference, which is different to FK5)? Admittedly, the list was hastily written. Basically any routines for any systems available, we want to test. > 5) Was the omission of ICRS intentional? See above. > 6) No mention of the epoch of observation. As I mentioned in another > message you need to specify the epoch of observation, to be able to > convert accurately to and from an FK4 RA/Dec system (which I presume > is what you mean by "B1950"). Strictly, you also need the epoch of > observation when converting between FK5 and ICRS, albeit the > dependency on the epoch is much weaker. > 7) You need to specify an equinox for the ecliptic coordinates. You are correct (see "hastily written" :). The request should have included a note to randomly generate any additional information needed. As for the output, it would be ideal to generate the random points and save that as a file. Another script could then convert those points into various systems and either write out each result as a separate file or convert from one system to another, and write the results out to a new file. Thanks again for the help! Cheers, Demitri _________________________________________ Demitri Muna Center for Cosmology and Particle Physics New York University http://scicoder.org From thomas.robitaille at gmail.com Thu Nov 15 12:27:28 2012 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 15 Nov 2012 18:27:28 +0100 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: <1FA8BF0C-C3DA-480B-969E-1E2CA684276D@gmail.com> References: <1FA8BF0C-C3DA-480B-969E-1E2CA684276D@gmail.com> Message-ID: >> 2) Why does it need to be IDL? It's proprietary software, so many >> people will not use it. There are many tools in many freely available >> languages for creating tables of corresponding positions in different >> coordinate systems. For instance, I could create such a table >> quickly using PyAST, which since we're talking Python seems an obvious >> choice. > > This is purely for testing purposes and not meant to be released for use by anyone. I specifically chose IDL since the libraries are well-trusted and well-tested by the community. I think a selling feature would be to show that our code compares favorably with what people trust. I think it would be great to have a PyAST version of the testing script in addition to the IDL one. I think it's fair to say that people trust AST (possibly even more than the IDL routines!). As for accuracy, I think we should aim for <0.01" initially - the rationale being that 1" accuracy won't be very useful for e.g. HST observations. In the long term, I would argue that microsecond accuracy would be desirable. Cheers, Tom >> 3) You include ecliptic in the list. Does the coordinates package >> support ecliptic? I could not see it in the code. > > Erik implemented the actual systems; I'll let him address that. > >> 4) Your list of coordinate systems starts at " ra/dec J2000" and ends >> at "equatorial J2000" - are you making a distinction between these? >> And I presume you mean FK5 J2000 (there is a common usage of "J2000 >> RA/Dec" which uses the mean dynamical equator and equinox of the J2000 >> epoch as reference, which is different to FK5)? > > Admittedly, the list was hastily written. Basically any routines for any systems available, we want to test. > >> 5) Was the omission of ICRS intentional? > > See above. > >> 6) No mention of the epoch of observation. As I mentioned in another >> message you need to specify the epoch of observation, to be able to >> convert accurately to and from an FK4 RA/Dec system (which I presume >> is what you mean by "B1950"). Strictly, you also need the epoch of >> observation when converting between FK5 and ICRS, albeit the >> dependency on the epoch is much weaker. > >> 7) You need to specify an equinox for the ecliptic coordinates. > > > You are correct (see "hastily written" :). The request should have included a note to randomly generate any additional information needed. > > As for the output, it would be ideal to generate the random points and save that as a file. Another script could then convert those points into various systems and either write out each result as a separate file or convert from one system to another, and write the results out to a new file. > > Thanks again for the help! > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > > Center for Cosmology and Particle Physics > New York University > > http://scicoder.org > > From d.berry at jach.hawaii.edu Thu Nov 15 12:32:04 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 15 Nov 2012 17:32:04 +0000 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: <1FA8BF0C-C3DA-480B-969E-1E2CA684276D@gmail.com> References: <1FA8BF0C-C3DA-480B-969E-1E2CA684276D@gmail.com> Message-ID: Hi Demitri, My offering is at http://www.jach.hawaii.edu/~dberry/convert.py (the script) http://www.jach.hawaii.edu/~dberry/pyast.txt.gz (the output table) The script reads the FK5 J2000 values from Chris' table and converts them to FK4 B1950, ICRS, Galactic and Ecliptic. It assumes J2000 for the epoch of observation (as specified at http://idlastro.gsfc.nasa.gov/ftp/pro/astro/bprecess.pro). The RMS discrepancies in arc-seconds between my table and Chris' table are 3.6E-4 (ecliptic) and 3.6E-7 (galactic). I'm sure you didn't mean to suggest that astronomers only trust software written in IDL :-) AST has been around for more than a decade. It's based on the SLALIB library that was created by Pat Wallace, the author of the SOFA library (who was also involved in writing AST), and is used in very trusted tools such as DS9. David -------------- next part -------------- A non-text attachment was scrubbed... Name: convert.py Type: application/octet-stream Size: 2480 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pyast.txt.gz Type: application/x-gzip Size: 68118 bytes Desc: not available URL: From d.berry at jach.hawaii.edu Thu Nov 15 12:32:57 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 15 Nov 2012 17:32:57 +0000 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: <1FA8BF0C-C3DA-480B-969E-1E2CA684276D@gmail.com> Message-ID: Accident - I didn't mean to attach the files to the message! David On 15 November 2012 17:32, David Berry wrote: > Hi Demitri, > > My offering is at > > http://www.jach.hawaii.edu/~dberry/convert.py (the script) > http://www.jach.hawaii.edu/~dberry/pyast.txt.gz (the output table) > > The script reads the FK5 J2000 values from Chris' table and converts > them to FK4 B1950, ICRS, Galactic and Ecliptic. It assumes J2000 for > the epoch of observation (as specified at > http://idlastro.gsfc.nasa.gov/ftp/pro/astro/bprecess.pro). The RMS > discrepancies in arc-seconds between my table and Chris' table are > 3.6E-4 (ecliptic) and 3.6E-7 (galactic). > > I'm sure you didn't mean to suggest that astronomers only trust > software written in IDL :-) AST has been around for more than a > decade. It's based on the SLALIB library that was created by Pat > Wallace, the author of the SOFA library (who was also involved in > writing AST), and is used in very trusted tools such as DS9. > > David From stsci.perry at gmail.com Thu Nov 15 12:43:45 2012 From: stsci.perry at gmail.com (Perry Greenfield) Date: Thu, 15 Nov 2012 12:43:45 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help References: <00C1A9D1-C35D-4C03-9D0C-CE0F18201D00@gmail.com> Message-ID: <0DA2EB72-DA20-4F76-88AA-00E8ED480EB8@gmail.com> On Nov 15, 2012, at 12:27 PM, Thomas Robitaille wrote: > > I think it would be great to have a PyAST version of the testing > script in addition to the IDL one. I think it's fair to say that > people trust AST (possibly even more than the IDL routines!). > > As for accuracy, I think we should aim for <0.01" initially - the > rationale being that 1" accuracy won't be very useful for e.g. HST > observations. In the long term, I would argue that microsecond > accuracy would be desirable. > > Cheers, > Tom > Agreed! And if David can help contribute to that (in any way), I think that would be great (there is obviously a wealth of experience there). The nice thing about the pyAST comparison is that this can all be done in Python without needing an IDL License. Perry From sransom at nrao.edu Thu Nov 15 21:41:49 2012 From: sransom at nrao.edu (Scott Ransom) Date: Thu, 15 Nov 2012 21:41:49 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: <0DA2EB72-DA20-4F76-88AA-00E8ED480EB8@gmail.com> References: <00C1A9D1-C35D-4C03-9D0C-CE0F18201D00@gmail.com> <0DA2EB72-DA20-4F76-88AA-00E8ED480EB8@gmail.com> Message-ID: <50A5A7ED.5060706@nrao.edu> Hey All, Many of you probably know this, but there I made a f2py wrap of the Fortran version of SLALIB several years ago which is available here. It would be a good 2nd (or 3rd or 4th) check... https://github.com/scottransom/pyslalib Scott On 11/15/2012 12:43 PM, Perry Greenfield wrote: > > On Nov 15, 2012, at 12:27 PM, Thomas Robitaille wrote: >> >> I think it would be great to have a PyAST version of the testing >> script in addition to the IDL one. I think it's fair to say that >> people trust AST (possibly even more than the IDL routines!). >> >> As for accuracy, I think we should aim for <0.01" initially - the >> rationale being that 1" accuracy won't be very useful for e.g. HST >> observations. In the long term, I would argue that microsecond >> accuracy would be desirable. >> >> Cheers, >> Tom >> > Agreed! And if David can help contribute to that (in any way), I think that would be great (there is obviously a wealth of experience there). The nice thing about the pyAST comparison is that this can all be done in Python without needing an IDL License. > > Perry > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sransom at nrao.edu Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From tim.jenness at gmail.com Thu Nov 15 21:43:26 2012 From: tim.jenness at gmail.com (Tim Jenness) Date: Thu, 15 Nov 2012 16:43:26 -1000 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: <50A5A7ED.5060706@nrao.edu> References: <00C1A9D1-C35D-4C03-9D0C-CE0F18201D00@gmail.com> <0DA2EB72-DA20-4F76-88AA-00E8ED480EB8@gmail.com> <50A5A7ED.5060706@nrao.edu> Message-ID: and I can probably do palpy (rewrite of SLALIB in C with matching API using SOFA): https://github.com/Starlink/palpy On Thu, Nov 15, 2012 at 4:41 PM, Scott Ransom wrote: > Hey All, > > Many of you probably know this, but there I made a f2py wrap of the > Fortran version of SLALIB several years ago which is available here. It > would be a good 2nd (or 3rd or 4th) check... > > https://github.com/scottransom/pyslalib > > Scott > > On 11/15/2012 12:43 PM, Perry Greenfield wrote: > > > > On Nov 15, 2012, at 12:27 PM, Thomas Robitaille wrote: > >> > >> I think it would be great to have a PyAST version of the testing > >> script in addition to the IDL one. I think it's fair to say that > >> people trust AST (possibly even more than the IDL routines!). > >> > >> As for accuracy, I think we should aim for <0.01" initially - the > >> rationale being that 1" accuracy won't be very useful for e.g. HST > >> observations. In the long term, I would argue that microsecond > >> accuracy would be desirable. > >> > >> Cheers, > >> Tom > >> > > Agreed! And if David can help contribute to that (in any way), I think > that would be great (there is obviously a wealth of experience there). The > nice thing about the pyAST comparison is that this can all be done in > Python without needing an IDL License. > > > > Perry > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Scott M. Ransom Address: NRAO > Phone: (434) 296-0320 520 Edgemont Rd. > email: sransom at nrao.edu Charlottesville, VA 22903 USA > GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon at rhodesmill.org Thu Nov 15 22:24:29 2012 From: brandon at rhodesmill.org (Brandon Rhodes) Date: Thu, 15 Nov 2012 22:24:29 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: (David Berry's message of "Thu, 15 Nov 2012 08:29:28 +0000") References: Message-ID: <8762568c2a.fsf@asaph.rhodesmill.org> David Berry writes: > 2) Why does it need to be IDL? It's proprietary software, so many > people will not use it. There are many tools in many freely available > languages for creating tables of corresponding positions in different > coordinate systems. For instance, I could create such a table quickly > using PyAST, which since we're talking Python seems an obvious choice. Several of the coordinate transforms mentioned in the post (maybe all?) are also implemented by the Naval Observatory's NOVAS library, which requires no license and for which they now support an official Python wrapper - though I will grant you that the API can take a bit of getting used to: http://pypi.python.org/pypi/novas/ http://www.usno.navy.mil/USNO/astronomical-applications/software-products/novas/novas-python -- Brandon Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon From demitri.muna at gmail.com Fri Nov 16 00:50:10 2012 From: demitri.muna at gmail.com (Demitri Muna) Date: Fri, 16 Nov 2012 00:50:10 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: <8762568c2a.fsf@asaph.rhodesmill.org> References: <8762568c2a.fsf@asaph.rhodesmill.org> Message-ID: <1AAC664D-F91B-46D5-87AD-5BFF147D6182@gmail.com> Hi, On 15 Nov 2012, at 12:32, David Berry wrote: > I'm sure you didn't mean to suggest that astronomers only trust > software written in IDL :-) AST has been around for more than a > decade. It's based on the SLALIB library that was created by Pat > Wallace, the author of the SOFA library (who was also involved in > writing AST), and is used in very trusted tools such as DS9. No, not at all. But I know that a lot of astronomers live by it daily, and if we can say "this code agrees with what you are using to xxx precision and has been tested against it", it will assuage some. On 15 Nov 2012, at 12:27, Thomas Robitaille wrote: > I think it would be great to have a PyAST version of the testing > script in addition to the IDL one. I think it's fair to say that > people trust AST (possibly even more than the IDL routines!). Yes, definitely. The IDL script can't be run automatically anyway. On 15 Nov 2012, at 22:24, Brandon Rhodes wrote: > Several of the coordinate transforms mentioned in the post (maybe all?) > are also implemented by the Naval Observatory's NOVAS library, which > requires no license and for which they now support an official Python > wrapper - though I will grant you that the API can take a bit of getting > used to: Hopefully our API is better. :) So... can I get a volunteer to write the code that compares the results to the new astropy coordinates package? I might argue that it shouldn't be Adrian, Erik, or myself since we wrote the code, and it would be very valuable to have someone from the community use it to see how much sense it makes. This includes reading the examples and documentation to let us know if anything is unclear. Really appreciate all the help and suggestions. Cheers, Demitri _________________________________________ Demitri Muna Center for Cosmology and Particle Physics New York University http://scicoder.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Fri Nov 16 02:55:06 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Fri, 16 Nov 2012 07:55:06 +0000 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: <1AAC664D-F91B-46D5-87AD-5BFF147D6182@gmail.com> References: <8762568c2a.fsf@asaph.rhodesmill.org> <1AAC664D-F91B-46D5-87AD-5BFF147D6182@gmail.com> Message-ID: On 16 November 2012 05:50, Demitri Muna wrote: > Hi, > > On 15 Nov 2012, at 12:32, David Berry wrote: > > I'm sure you didn't mean to suggest that astronomers only trust > software written in IDL :-) AST has been around for more than a > decade. It's based on the SLALIB library that was created by Pat > Wallace, the author of the SOFA library (who was also involved in > writing AST), and is used in very trusted tools such as DS9. > > > No, not at all. But I know that a lot of astronomers live by it daily, and > if we can say "this code agrees with what you are using to xxx precision and > has been tested against it", it will assuage some. > > > On 15 Nov 2012, at 12:27, Thomas Robitaille > wrote: > > I think it would be great to have a PyAST version of the testing > script in addition to the IDL one. I think it's fair to say that > people trust AST (possibly even more than the IDL routines!). > > > Yes, definitely. The IDL script can't be run automatically anyway. > > On 15 Nov 2012, at 22:24, Brandon Rhodes wrote: > > Several of the coordinate transforms mentioned in the post (maybe all?) > are also implemented by the Naval Observatory's NOVAS library, which > requires no license and for which they now support an official Python > wrapper - though I will grant you that the API can take a bit of getting > used to: > > > Hopefully our API is better. :) > > > So... can I get a volunteer to write the code that compares the results to > the new astropy coordinates package? I might argue that it shouldn't be > Adrian, Erik, or myself since we wrote the code, and it would be very > valuable to have someone from the community use it to see how much sense it > makes. This includes reading the examples and documentation to let us know > if anything is unclear. > > Really appreciate all the help and suggestions. I could do this (using pyast), but I think there are some issues to resolve first - the main one being the question of "epoch" versus "equinox". To get decent accuracy on FK4-FK5 conversions you need both. I suggest the coordinates package is changed to rename "epoch" as "equinox", and introduce a new "epoch" property to hold the date of observation. This may be re-visitiing old ground, but I can't help thinking that a large amount of effort would have been saved (and maybe even still could be saved) by implementing coordinates over the top of pyast. After all, there are several other C libraries in astropy. It would provide a guide to the meta-data required to describe each coordinate system, it would give you immediate support for many additional coordinate systems (ecliptic, FK4 with no E terms, geocentric apparent equatorial, helioecliptic, equatorial referred to the dynamical equator and equinox of J2000 (not the same as FK5), supergalactic). It would give you the ability to transform between horizon coords (Az,El) and all other systems. When you come to extend astropy to include spectral coordinates, it would give you immediate support for a similarly wide range of spectral coordinate systems and transformations between them. I've not looked at the current time facilities in astropy, but pyast again would give you a wide range of time systems too. And it would provide a comprehensive system of stackable numerical mappings, such as I was talking to Nadia Dencheva about at ADASS, including the all-important ability to be able to simplify complex mappings (by no means trivial). And it would give you very versatile support for WCS, including support for FITS-WCS and many "common but not quite FITS" headers, and several common forms of distortion encoding (SIP, . And it's all tried and trusted - anyone that uses DS9 uses AST. I'll grant you the pyast API is probably not very astronomer friendly, but implementing a simpler API on top of pyast may provide fast access to lots of features. Looking at the astropy coordinates package, it would probably have taken a day or two to implement it using pyast. David From thomas.robitaille at gmail.com Fri Nov 16 04:43:32 2012 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 16 Nov 2012 10:43:32 +0100 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: Message-ID: I have a suggestion - once the epoch/equinox issue is dealt with, we can create a repository (e.g. astropy-coordinates-benchmarks) in the astropy organization which would contain an input file with the 1000 random positions on the sky, and then add the scripts to test against each package (one astropy script, one IDL script, one pyAST script, one SLALIB script, etc.), and the associated output files, and then have another script to compare the results. Then, people can easily contribute scripts or updates via pull requests. I can set up the repository if there is interest. Cheers, Tom On 14 November 2012 23:01, Demitri Muna wrote: > Hi, > > We are in the process of testing the new astropy coordinates package. One test that I think would be useful is this (which Tom also mentioned): > > * generate 1000 ra/dec J2000 random points on the sky > * convert them to, in steps, > - galactic > - B1950 > - ecliptic > - equatorial J2000 > > Can someone do this in IDL? The result should be > > * the file containing 1000 points > * the resulting points at the end of the conversions > * the IDL script > > The aim is to write a script using the coordinates package and see if there are any discrepancies. We will add this to the testing suite. > > I thought I'd cc the astropy list as I'm sure there are lots of people who are proficient in IDL and can probably do this pretty quickly. > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > > Center for Cosmology and Particle Physics > New York University > > http://scicoder.org > > From demitri.muna at gmail.com Fri Nov 16 12:41:56 2012 From: demitri.muna at gmail.com (Demitri Muna) Date: Fri, 16 Nov 2012 12:41:56 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: <8762568c2a.fsf@asaph.rhodesmill.org> <1AAC664D-F91B-46D5-87AD-5BFF147D6182@gmail.com> <3C369979-B9C4-463F-8D66-67837D6D7844@gmail.com> Message-ID: Hi, I would be in favor of using AST as a back end for several reasons. * There is value to using a single piece of code over reimplementing a new one. From a user's perspective, there is no value in a pure-Python implementation over a C-based one. Those are details they should not be aware of, and our aim here is to make them agree to as high a precision as possible. Work is not duplicated - we have scant resources and a monumental task ahead (astropy). * The *most important thing to me* is a clean, easy to use API. (Aside from accuracy. :) I see no reason why this has to be sacrificed at all, so while there might be a little pain up front for us to write the glue code, I think that's fine. * The 12MB size I think is trivial, and if it takes a few more minutes to compile, I think that's fine. I would also advocate hosting/distributing prebuilt binaries. The number of versions needed for the whole Mac universe is small and easy to maintain, the more popular Linii can be made, and anything else should compile. If it doesn't, we push the issue back upstream and not fix it ourselves. David, what are the external dependencies? Can the library be built as a distributable static library? * I haven't ever used (or seen) pyast, but my knee-jerk reaction is that I don't want any layer at all between the C AST and astropy code. * Getting lots of features "for free" seems like a huge win, and even if the astropy classes don't expose them yet, it will be far easier to write a good API than to reimplement the functionality. * I would like to get Erik's thoughts on the question of providing a means to extend transformations. David, are there hooks in AST to do this? I don't know what it would entail. I think there are issues in making this work, but I think it's a good direction to investigate. If we had infinite resources to work on astropy that might be one thing, but getting a mountain of functionality that will free others to work on other things seems like a win. Cheers, Demitri _________________________________________ Demitri Muna Center for Cosmology and Particle Physics New York University http://scicoder.org From stsci.perry at gmail.com Fri Nov 16 13:19:09 2012 From: stsci.perry at gmail.com (Perry Greenfield) Date: Fri, 16 Nov 2012 13:19:09 -0500 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: <8762568c2a.fsf@asaph.rhodesmill.org> <1AAC664D-F91B-46D5-87AD-5BFF147D6182@gmail.com> <3C369979-B9C4-463F-8D66-67837D6D7844@gmail.com> Message-ID: <01A538F3-EC80-49B6-8F11-1F3B2EAEEC87@gmail.com> On Nov 16, 2012, at 12:41 PM, Demitri Muna wrote: > Hi, > > I would be in favor of using AST as a back end for several reasons. > > * There is value to using a single piece of code over reimplementing a new one. From a user's perspective, there is no value in a pure-Python implementation over a C-based one. Those are details they should not be aware of, and our aim here is to make them agree to as high a precision as possible. Work is not duplicated - we have scant resources and a monumental task ahead (astropy). > This certainly true, but it isn't always quite that simple (i.e., other factors enter into the question also). > * The *most important thing to me* is a clean, easy to use API. (Aside from accuracy. :) I see no reason why this has to be sacrificed at all, so while there might be a little pain up front for us to write the glue code, I think that's fine. > Likewise, whether a good python api can be layered sometimes is not as easy as it sounds. It depends sometimes on how one coordinates [er] activities between the two that can get complicated, particularly if there is a lot of state involved. I'm not saying it's a problem here, but it isn't always as simple as it sounds. Another complication is when you want to extend the library. Do you do that in C or Python? If in Python, will the extensions carry through to the old C code? It can get messy. [?] > > * I haven't ever used (or seen) pyast, but my knee-jerk reaction is that I don't want any layer at all between the C AST and astropy code. > ? > * Getting lots of features "for free" seems like a huge win, and even if the astropy classes don't expose them yet, it will be far easier to write a good API than to reimplement the functionality. > For other reasons (alluded to in a separate email), I'm not sure the WCS functionality is easily used the way we would like it to be. Perry From d.berry at jach.hawaii.edu Fri Nov 16 13:47:48 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Fri, 16 Nov 2012 18:47:48 +0000 Subject: [AstroPy] [astropy-dev] Coordinates subpackage - request for help In-Reply-To: References: <8762568c2a.fsf@asaph.rhodesmill.org> <1AAC664D-F91B-46D5-87AD-5BFF147D6182@gmail.com> <3C369979-B9C4-463F-8D66-67837D6D7844@gmail.com> Message-ID: On 16 November 2012 17:41, Demitri Muna wrote: > Hi, > > I would be in favor of using AST as a back end for several reasons. > > * There is value to using a single piece of code over reimplementing a new one. From a user's perspective, there is no value in a pure-Python implementation over a C-based one. Those are details they should not be aware of, and our aim here is to make them agree to as high a precision as possible. Work is not duplicated - we have scant resources and a monumental task ahead (astropy). > > * The *most important thing to me* is a clean, easy to use API. (Aside from accuracy. :) I see no reason why this has to be sacrificed at all, so while there might be a little pain up front for us to write the glue code, I think that's fine. > > * The 12MB size I think is trivial, and if it takes a few more minutes to compile, I think that's fine. I would also advocate hosting/distributing prebuilt binaries. The number of versions needed for the whole Mac universe is small and easy to maintain, the more popular Linii can be made, and anything else should compile. If it doesn't, we push the issue back upstream and not fix it ourselves. David, what are the external dependencies? Can the library be built as a distributable static library? AST uses sofa and pal (github.com/Starlink/pal). These come bundled with AST, but it is possible to use external versions of these libraries instead (that was a requirement for it going in the Debian repository). It has no other external dependencies. It can be built as a static library. > * I haven't ever used (or seen) pyast, but my knee-jerk reaction is that I don't want any layer at all between the C AST and astropy code. > * Getting lots of features "for free" seems like a huge win, and even if the astropy classes don't expose them yet, it will be far easier to write a good API than to reimplement the functionality. > > * I would like to get Erik's thoughts on the question of providing a means to extend transformations. David, are there hooks in AST to do this? I don't know what it would entail. Obviously, AST is open source, and so I'm very happy for others to contribute to it. If a new class of Mapping is needed, an option would be to write it in C and add it directly into the AST library so that other non-Python users of AST get the benefit as well. I've never given much thought to the idea of providing a scheme that allows other external libraries to extend AST classes, but it is clearly something that would be valuable, and could probably be done. David From thomas.robitaille at gmail.com Mon Nov 19 04:45:43 2012 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 19 Nov 2012 10:45:43 +0100 Subject: [AstroPy] Short survey: your scientific Python installation Message-ID: Hi everyone, I am interested in finding out what versions of a few basic Python packages (Python, Numpy, and Scipy) you are all using for everyday scientific work, and how you are installing packages. This will help developers for other packages (such as astronomy packages) determine which versions of dependencies and which distribution methods they need to support. I would be very grateful if you could take 30 seconds to answer 5 short questions in the following form: https://docs.google.com/spreadsheet/viewform?formkey=dDNzTDVTVnFqSjNCYm44aEZIdkxfNmc6MQ Once the survey closes, the data will be publicly available! Thanks, Tom From Christos.Siopis at ulb.ac.be Wed Nov 21 10:27:40 2012 From: Christos.Siopis at ulb.ac.be (Christos Siopis) Date: Wed, 21 Nov 2012 16:27:40 +0100 Subject: [AstroPy] FOSS for scientists devroom at FOSDEM 2013 Message-ID: <20121121152740.GA6241@ulb.ac.be> Dear members of the Numerical Python ecosystem (with apologies for cross-postings), A day-long session ("devroom") on Free/Libre and Open Source Software (FLOSS) for scientists will be held during the next FOSDEM conference, Brussels, 2-3 February 2013 (http://fosdem.org/2013). We aim at having a dozen or two short talks introducing projects, advertising brand new features of established tools, discussing issues relevant to the development of software for scientific computing, and touching on the interdependence of FLOSS and open science. You can find more info on the call for talks at: http://slayoo.github.com/fosdem2013/ The deadline for sending talk proposals is December 16th 2012. Please send your submissions or comments to: foss4scientists-devroom at lists.fosdem.org Please do forward this message to anyone potentially interested. Please also let us know if you have any suggestions for what would you like to hear about in the devroom. Looking forward to meeting you in Brussels. Thanks in advance. The conveners, Sylwester Arabas, Juan Antonio A?el, Christos Siopis P.S. There are open calls for main-track talks, lightning talks, and stands at FOSDEM as well, see: http://fosdem.org/2013/ -------------- I would like to add to the above general announcement, that it would be great if a main track talk were to be given at FOSDEM about the importance of scientific open source software in science and engineering today. Main track talks last 50 minutes, and are addressed to all FOSDEM participants, something that would add to the visibility of scientific software. As an extra bonus, main track speakers have their travel and hotel expenses covered by FOSDEM. I think that the numerical python "ecosystem" could serve as an excellent "case study" of the data processing and visualisation workflow, while adding an interesting historical dimension, being one of the oldest projects of its sort. If you decide to respond to the call for main track speakers, you should start here: https://fosdem.org/2013/call_for_main_speakers/ Please note the December 1 deadline. I urge you to let us (the science software devroom conveners) know about your proposed talk, so that we may send a word of recommendation to the FOSDEM committee who will make the ultimate selection. We thank you in advance for your expressions of interest and participation! _______________________________________________ foss4scientists-devroom mailing list foss4scientists-devroom at lists.fosdem.org https://lists.fosdem.org/listinfo/foss4scientists-devroom From rij at stsci.edu Fri Nov 30 11:57:20 2012 From: rij at stsci.edu (Robert Jedrzejewski) Date: Fri, 30 Nov 2012 16:57:20 +0000 Subject: [AstroPy] Problems using tables Message-ID: Hi folks, I've been playing the the tables module in astropy. I followed the examples in the documentation (http://astropy.readthedocs.org/en/v0.1/table/index.html) to create a 3 column and 3 row table. Everything seems to work OK until I try to print a single row of the table t: >>> t[1] ERROR: RuntimeError: maximum recursion depth exceeded while calling a Python object [astropy.table.table] Traceback (most recent call last): File "", line 1, in File "/home/rij/py-lib/astropy/table/table.py", line 445, in __repr__ self.index, self.data, self.dtype) RuntimeError: maximum recursion depth exceeded while calling a Python object I can assign t[1] to a new variable, creating a Row object, and access all of its methods, but calling __repr__() gives this recursion error. Looking at the code, the offending function is def __repr__(self): return "".format( self.index, self.data, self.dtype) The problem is the second argument; self.data is of type numpy.void and for some reason this doesn't format well using this kind of syntax. Casting this to np.array type seems to fix this. Does this seem like the right way to fix this, or am I missing something obvious here? (e.g. does the fact that row.data is of type numpy.void mean that something went wrong earlier?) I don't usually delve too deeply into numpy or astropy because I usually don't have to, it usually works perfectly out of the box :) Thanks for any insight, Robert J. From rij at stsci.edu Fri Nov 30 12:04:54 2012 From: rij at stsci.edu (Robert Jedrzejewski) Date: Fri, 30 Nov 2012 17:04:54 +0000 Subject: [AstroPy] Problems using tables In-Reply-To: References: Message-ID: And of course just after posting this I found Issue 341 on the github page that mentions this very problem :( https://github.com/astropy/astropy/issues/341 Sorry to waste bandwidth... Robert J. ________________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Robert Jedrzejewski [rij at stsci.edu] Sent: Friday, November 30, 2012 11:57 AM To: astropy at scipy.org Subject: [AstroPy] Problems using tables Hi folks, I've been playing the the tables module in astropy. I followed the examples in the documentation (http://astropy.readthedocs.org/en/v0.1/table/index.html) to create a 3 column and 3 row table. Everything seems to work OK until I try to print a single row of the table t: >>> t[1] ERROR: RuntimeError: maximum recursion depth exceeded while calling a Python object [astropy.table.table] Traceback (most recent call last): File "", line 1, in File "/home/rij/py-lib/astropy/table/table.py", line 445, in __repr__ self.index, self.data, self.dtype) RuntimeError: maximum recursion depth exceeded while calling a Python object I can assign t[1] to a new variable, creating a Row object, and access all of its methods, but calling __repr__() gives this recursion error. Looking at the code, the offending function is def __repr__(self): return "".format( self.index, self.data, self.dtype) The problem is the second argument; self.data is of type numpy.void and for some reason this doesn't format well using this kind of syntax. Casting this to np.array type seems to fix this. Does this seem like the right way to fix this, or am I missing something obvious here? (e.g. does the fact that row.data is of type numpy.void mean that something went wrong earlier?) I don't usually delve too deeply into numpy or astropy because I usually don't have to, it usually works perfectly out of the box :) Thanks for any insight, Robert J. _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy