These are chat archives for astropy/astropy

3rd
Jun 2014
Wolfgang Kerzendorf
@wkerzendorf
Jun 03 2014 19:09
@embray @astrofrog With the new setup_helpers the version number needs to be set in setup.py. Should/Will this be changed to setup.cfg?
Stuart Mumford
@Cadair
Jun 03 2014 19:27
@wkerzendorf I see no reason why you could't put the version in setup.cfg?
you could just pull it out of the ConfigParser object
Wolfgang Kerzendorf
@wkerzendorf
Jun 03 2014 19:29
@Cadair well you could, but that doesn't seem the standard way currently. I was wondering if there is a specific design decision to leave it in setup.py. If not we can migrate it over to setup.cfg.
Stuart Mumford
@Cadair
Jun 03 2014 19:29
yeah. I don't know
Stuart Mumford
@Cadair
Jun 03 2014 19:43
hey @eteq what is your opinion on #2586 ?
Thomas Robitaille
@astrofrog
Jun 03 2014 20:18
Hmm, I was wondering that too (about the version number). Could you open an issue on the package-template and ping @embray there?
Stuart Mumford
@Cadair
Jun 03 2014 20:37
Really need to come up with a different wheel solution
I was thinking of using binstar to host the bdists
and not using wheels at all
Thomas Robitaille
@astrofrog
Jun 03 2014 21:02
what's the issue with the wheels at the moment?
Stuart Mumford
@Cadair
Jun 03 2014 21:16
The different numpy versions thing that you folks worked around is my main motivator
I was thinking you could have a binstar 'channel' or whatever they call it for each numpy version
I just need to warm up my bash foo and give it a go
also it solves the hosting problem nicely :)
Christoph Deil
@cdeil
Jun 03 2014 21:43
I'm using the @remote_data decorator in a unit test where I call astropy.utils.data.download_file(url, cache=True).
I think this re-downloads the file every time instead of hitting the cache.
Is this intentional behaviour for tests?
Matt Craig
@mwcraig
Jun 03 2014 21:43
@Cadair -- if you go with binstar you don't need to worry about the numpy issue. If you build something that depends on numpy the package name includes the numpy version
Stuart Mumford
@Cadair
Jun 03 2014 21:43
@mwcraig even for non-conda packages?
Matt Craig
@mwcraig
Jun 03 2014 21:43
ah, no. For things built with conda build
afaik
Stuart Mumford
@Cadair
Jun 03 2014 21:44
I was planning on using binstart to build pip packages not conda
because conda is a pita
Matt Craig
@mwcraig
Jun 03 2014 21:45
i had to do some conda builds for a different project...took some getting used to
Stuart Mumford
@Cadair
Jun 03 2014 21:46
Don't get me wrong, I love the idea of conda, but I think there is still some way to go there
I think the planned CI service on binstar will help
because at least then you can hopefully cross-platform build your packages without having to have the platforms
Matt Craig
@mwcraig
Jun 03 2014 21:46
that would be nice
Stuart Mumford
@Cadair
Jun 03 2014 21:47
how are you building the numpy packages at the moment?
Matt Craig
@mwcraig
Jun 03 2014 21:47
the script is at astropy/astropy-wheels#1
I build them on an ubuntu 12.04LTS VM
Stuart Mumford
@Cadair
Jun 03 2014 21:49
fair enough
I like using travis to build them
it makes it a little easier
Erik Tollerud
@eteq
Jun 03 2014 21:49
@Cadair - re:#2586 : I’m still mulling it over (while trying to catch up on some other things). My first reaction is that I do not like it, because that makes two ways to do everything: represent_as and reassigning preferred_representation. But I also see what it might be nice, so I’m contemplating what else might make sense
Stuart Mumford
@Cadair
Jun 03 2014 21:50
@eteq while represent_as kinda does the same thing, the problem is that it dosen't return a frame
Matt Craig
@mwcraig
Jun 03 2014 21:50
I thought about using travis, but getting a vm going was easier (and faster to execute)
Erik Tollerud
@eteq
Jun 03 2014 21:50
right, but the question is whether that’s a feature or a bug :wink:
(that was to @Cadair , not @mwcraig , to be clear)
Stuart Mumford
@Cadair
Jun 03 2014 21:51
for there to be seperation between frames and representations you need to be able to have a frame with the data availible in any representation
kinda transparently
Erik Tollerud
@eteq
Jun 03 2014 21:51
right, and that’s exactly what represnt_as is meant to do
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:52
@eteq - at the moment represent_as still returns a representation, not a coordinate (SkyCoord or frame)
So it's not 2 ways of doing the same thing.
Erik Tollerud
@eteq
Jun 03 2014 21:52
right, I understand that part - what I don’t understand is why it’s necessary for it to return a SkyCoord or frame
right it’s not exactly the same thing, but it ends up similar
Stuart Mumford
@Cadair
Jun 03 2014 21:52
Can someone clarify what the purpose of preferred_representaion is ?
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:53
represent_as doesn't have to, and in fact should not.
But without being able to modify the representation of a coordinate then everything doesn't quite work.
Erik Tollerud
@eteq
Jun 03 2014 21:53
@Cadair - preferred_representaion is the representation that the frame is most-commonly represented.
Stuart Mumford
@Cadair
Jun 03 2014 21:53
what uses it?
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:54
So I've been mulling over changing the PR I put in to use a coordinate / SkyCoord attribute representation as the way that users access or change the representation of a given coord object.
Then preferred_representation would go back to being a static thing that could also be called default_representation.
Erik Tollerud
@eteq
Jun 03 2014 21:54
the biggest purposes is to allow e.g. SkyCoord(l=…,b=…, frame=‘galactic’) - without the preferred_representation, there’s no way to know that l and b are
err, that is, that they are spherical lat/lon
Stuart Mumford
@Cadair
Jun 03 2014 21:55
right
If I have a FrameX which has a preferred representaion of cartesian, can I do framex.lat?
Erik Tollerud
@eteq
Jun 03 2014 21:55
@taldcroft - I could see that idea… that’s basically equivalent except that the “current” representation is stateful
@Cadair - no
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:55
So without allowing dynamic representations for coords, there is no way to say SkyCoord(x=.., y=..., frame='galactic')
Erik Tollerud
@eteq
Jun 03 2014 21:56
you can do framex.spherical.lat, though
Stuart Mumford
@Cadair
Jun 03 2014 21:56
but I can do framex.x
Erik Tollerud
@eteq
Jun 03 2014 21:56
or, more canonically framex.represent_as(SpehericalRepresentation).lat
yes, framex.x does work
Stuart Mumford
@Cadair
Jun 03 2014 21:56
XD
So to clarify my reasoning behind this, there are two solar coordinate systems, heliocentric and helioprojective which are commonly used in two representations.
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:58
Basically #2586 puts all the representations on equal footing from the user perspective. It exactly allows what @Cadair just said.
Stuart Mumford
@Cadair
Jun 03 2014 21:58
helioprojective cartesian is the standard system which most imaging data comes in.
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:58
Otherwise the preferred_representation is the only one that is convenient to use.
Stuart Mumford
@Cadair
Jun 03 2014 21:58
However, there is also a helioprojective spherical which is used quite widely
Erik Tollerud
@eteq
Jun 03 2014 21:58
@taldcroft - yep, gotcha, but to me that makes it a lot more confusing, for only a marginal convinience gain
Stuart Mumford
@Cadair
Jun 03 2014 21:59
I want a HelioProjective class that treats the spherical and carteisan systems as equal citizens
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 21:59
Of the 4 people that have been commenting so far, 3 of them find this to be less confusing. :-)
Stuart Mumford
@Cadair
Jun 03 2014 21:59
(the same argument applies to heliocentric except that it is less used and spherical or cylinrical representations)
Erik Tollerud
@eteq
Jun 03 2014 21:59
@taldcroft - but we are a very biased sample
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:00
Are you basically arguing that having a stateful attribute is confusing?
In some sense that is why I think it makes sense as a property, because you really altering a property of the object, namely how it represents itself.
To me that it crystal clear.
Erik Tollerud
@eteq
Jun 03 2014 22:02
Yes, because it’s not physically stateful - an analogy that might help is Quantity: 1000 m and 1 km should act exactly the same in any actual calculation, until you ask for them in a specific unit
Stuart Mumford
@Cadair
Jun 03 2014 22:02
@taldcroft my favorite thing about #2586 is that it provides a simple 'mode' switch between representations
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:03
But you can change the unit of a quantity, but you can never change the preferred_repr of a coord.
Stuart Mumford
@Cadair
Jun 03 2014 22:03
@taldcroft would moving from a attribute to a property change the api?
Erik Tollerud
@eteq
Jun 03 2014 22:03
The other issue is that it makes the idea of preferred names much more difficult: right now, e.g., Galactic coordinates map l and b to lon and lat, but what do I do if I want cartesian galactic? u v w? (that’s the convnetional name used in the literature)
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:04
@eteq - that is trivial.
Erik Tollerud
@eteq
Jun 03 2014 22:04
@taldcroft - it’s trivial to implement, but it makes it more confusing for users
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:04
Why?
Or rather, why is it more confusing?
Stuart Mumford
@Cadair
Jun 03 2014 22:05
yeah, a truely representation independant system should be able to cope with all representations that make sense in that frame
Erik Tollerud
@eteq
Jun 03 2014 22:05
Because it’s an extra “dimension”, as it were: now instead of knowing l and b, they have to also know u, v, and w, and possibly much more
Stuart Mumford
@Cadair
Jun 03 2014 22:06
@eteq but if they don't know it they don't have to use it
and if you have a user who is likely to get confused, they probably wont even think of using galactic in cartesian?
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:06

I think it would be less confusing because a user can explore and find this:

sc = SkyCoord(..., frame='galactic')
sc.representation = 'cartesian'
sc
<SkyCoord Galactic w=.. v=.. w=..>

Voila, they learned about this without any docs!

Erik Tollerud
@eteq
Jun 03 2014 22:07
actually, I’m more thinking of people reading other people’s code than writing their own
@taldcroft - hmm, I guess that is a good point
Stuart Mumford
@Cadair
Jun 03 2014 22:07
@taldcroft that example is what I want
that is a fantastic API for what we need
Erik Tollerud
@eteq
Jun 03 2014 22:08
There’s one other problem: we want to release 0.4 ASAP
Stuart Mumford
@Cadair
Jun 03 2014 22:08
@eteq I will eschew my actual work to get something like this in, because it is going to cause us all manner of hell if it is left out in the cold till 1.0
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:08
And what about the user that has u, v, w values and wants to make a SkyCoord. They might have to do c = Cartesian(x=u, y=v, z=w)
Erik Tollerud
@eteq
Jun 03 2014 22:09
@taldcroft - exactly - and that’s a good thing, because then we aren’t hiding everything from the user
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:09
Instead of `SkyCoord(u=u, v=v, w=w, frame, representation='cartesian')
The other thing to say is that SunPy are basically the first people that looked at this hard, and this was their first request.
Erik Tollerud
@eteq
Jun 03 2014 22:11
that’s true
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:11
They basically can't use it out of the box without something like this.
Erik Tollerud
@eteq
Jun 03 2014 22:12
I disagree with that: they can use it, it just requires an extra .cartesian
Stuart Mumford
@Cadair
Jun 03 2014 22:12
@eteq yes, it will work, but the API will be much more user unfriendly.
with something like this, the user dosen't have to think about representation objects
they just have to think about frames in representations
Erik Tollerud
@eteq
Jun 03 2014 22:13
right, and that’s may be the key point: it’s not clear if that’s better or worse
Stuart Mumford
@Cadair
Jun 03 2014 22:13
where as doing .cartesian gets something different to a frame, something that is one step away from a list
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:13
NO .cartesian is not the same!
Erik Tollerud
@eteq
Jun 03 2014 22:14
@taldcroft - it is not the same in that it doesn’t give the same __repr__ et al, but it allows the same functionality in the end
Stuart Mumford
@Cadair
Jun 03 2014 22:15
anyway, I am going to bed.
thanks for the chat
and all the new coordiantes code, it really is very awesome
Erik Tollerud
@eteq
Jun 03 2014 22:15
So let’s just complete the idea, though: if we change to what @taldcroft is suggesting, does it make defining frame classes harder?
ah, ok - will try to get this sorted out and have a game plan so we can get a release through
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:16
No, because every single time you want to get x from your coord, you need to add the cartesian. So then you end up doing sc_cart = sc.cartesian and mostly working with sc_cart,which is not a coordinate. So you have to carry two objects instead of one.
The point is that having one preferred representation is limiting because that is just your idea of the best repr but not someone elses.
Stuart Mumford
@Cadair
Jun 03 2014 22:17
@taldcroft or in the solar case, there are two representations which are equal, saying one is preferred over the other is wrong
Erik Tollerud
@eteq
Jun 03 2014 22:18
hmm, that’s true. And I guess it still reduces to everything the same if there’s only one “usually” preferred
So I guess I can see how this can be added without upsetting the other use cases, but this is a non-trivial change on the implementation side
to do it right will require a major re-write of BaseCoordinateFrame
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:20
Yes, it did end up going a bit deep.
How do you mean?
Erik Tollerud
@eteq
Jun 03 2014 22:23
I guess it’s true that you’ve done a lot of it already…
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:23
I think that #2586 is 90% there.
Apart from tests and docs of course.
Stuart Mumford
@Cadair
Jun 03 2014 22:24
We can help with those.
Erik Tollerud
@eteq
Jun 03 2014 22:24
right, which took a lot longer to write than the code, actually… but I’m not sure that’s so much so with these changes
hmm
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:25
It helps massively that there is a good test suite in place already.
Making these changes would be hard without confidence in the existing tests.
Stuart Mumford
@Cadair
Jun 03 2014 22:25
There are more tests in .coordinates than the whole of SunPy :(
Erik Tollerud
@eteq
Jun 03 2014 22:26
hah
Stuart Mumford
@Cadair
Jun 03 2014 22:26
We only just broke 70% coverage
Erik Tollerud
@eteq
Jun 03 2014 22:27
alright, you’ve convinced me it’s worth it, but if years from now everyone is confused by constantly-changing representations in frames, I’ll say I told you so :wink:
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:27
OK!
Stuart Mumford
@Cadair
Jun 03 2014 22:28
You have that right. :p
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:28
Somebody take a screen shot of this for posterity.
I'll work on trying to get #2586 a bit more final in implementation.
Gotta run now.
Erik Tollerud
@eteq
Jun 03 2014 22:28
Ok, so should I wait to review until then
?
I have a few high-level comments to leave now (I’ll put them in the PR), but should I wait for a more detailed review?
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:29
I was holding off until getting some concurrence since I knew you wouldn't exactly be jumping at the idea. :-)
Erik Tollerud
@eteq
Jun 03 2014 22:29
hehe, I suppose I can be predictible
*predictable
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:29
The only thing I wanted to do was make the user-facing attribute be representation instead of preferred_represeation. The latter will be essentially fixed as the default.
I don't think preferred_representation makes sense for the way we will be using it.
Erik Tollerud
@eteq
Jun 03 2014 22:30
agreed
perhaps default_representation, but then it has a different meaning
(that is, it chooses the default from the dictionary in what you already have in there)
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:31
I think default_representation makes sense for the fixed one, so then preferred would go away?
Stuart Mumford
@Cadair
Jun 03 2014 22:31
I think a hidden preferred_representation makes sense
Because it is the preferred one, just irellevant to the user?
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:32
To me it is really just a default now, which is to say the one that get's used if no explicit representation is provided. That is a pretty standard use of default_..
Erik Tollerud
@eteq
Jun 03 2014 22:32
actually, if we’re going this route, I’d say it makes more sense to get rid of the preferred everything, and instead just have a representation dict like what’s in the PR (although not hidden), and default_representation just is which one to use if one isn’t given
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:33
Yes agree @eteq
Stuart Mumford
@Cadair
Jun 03 2014 22:33
Makes sense
Erik Tollerud
@eteq
Jun 03 2014 22:34
ok, cool - if you both want to go I’ll leave a bit more in the PR (nothing controversial, I think - mostly just some syntax/wording bits)
Ghost
@ghost~53638049048862e761fa0380
Jun 03 2014 22:34
My wife will be at the office door any second... now you're married @eteq you understand?? :-)
Erik Tollerud
@eteq
Jun 03 2014 22:35
hah, indeed
Stuart Mumford
@Cadair
Jun 03 2014 22:35
:)
Ttyl
Thanks a lot
Erik Tollerud
@eteq
Jun 03 2014 22:36
cya - (and as a final note: this is why gitter is awesome!)