Repository navigation
Add comparison operators to Time #601
Description
Allow for scalar and vectorized comparison of Time objects with other Time objects, scalars, or arrays. For comparison with non-Time objects, the comparison would use the val attribute which implies comparing the current representation instead of the absolute time.
Activity
taldcroft commentedon Jan 3, 2013
The assumption here is that equality will refer to the moment of time and not the object and its attributes. Therefore something like
t.utc == t.taiwill beTrue. The same float point precision issues discussed for coordinates may be a problem here as well since there will be non-trivial transforms required to do such a comparison.eteq commentedon Jan 29, 2013
Hmm... I think we want to try to make sure we have a consistent way to do this between both
timeandcoordinates. And for that matter, future similar packages. That is, does__eq__mean "represents same thing, abstractly", or "numbers inside are the same".The second one is actually what
coordinatesdoes right now, and you're suggesting the first. I can see both sides, but my main concern is that the first one has a lot of potential ambiguities. I'm open to ideas for how to try to do the first one consistently, but it's not obvious how to do it for coordinates and time (if the system is not the same)taldcroft commentedon Jan 29, 2013
I'm not sure I follow what the ambiguities would be, at least for
time. As long as there is a pathway to convert a givenTimeobject to any other system unambiguously, then it is possible to do the "abstract" comparison. In some cases there might be insufficient metadata available (e.g. observer location etc) to do that transformation, but that would not represent a fundamental ambiguity in the methodology, but rather an ambiguity created by the lack of information supplied by the user.Perhaps I'm missing some subtlety?
One possible difference between
timeandcoordinatesis that theTimeobject is designed to carry (and propagate) every attribute that could be needed to do system conversions, even if those attributes are "don't care" for the particular system. I'm not sure where things stand with coordinates in that regard, but having attributes like observer location, obs date, etc that are part of aCoordinatesobject should make it possible (in theory) to always do the required transformations to put any two Coordinates into the same system. This could be done in the context of an__eq__method where you don't have the opportunity to specify that metadata.eteq commentedon Jan 29, 2013
Oh, I don't mean an ambiguity in interpretation of equality - you're right that seem fairly straightforward for
time(at least, until we start including GR... :) . I was thinking about numerical ambiguity that's an artifact of the implementation.For example, lets say we have two time objects, one that is
t1 = Time(0.5,0.5,format='jd',scale='utc')and the other ast2 = Time(1, 0,scale='utc'). You're suggestingt1 == t2in that case, which is perfectly sensible. But what if I now do a bunch of transformations to t2 liket3 = Time(Time(t2.mjd,format='mjd',scale='utc').tai),scale='tai')? (No reason to do that as written, but lets assume it went through some complex pathway through a reduction pipeline or something that is equivalent.) At some point floating point errors will add up such thatt1.jd1 + t1.jd2will be just slightly different fromt3.jd1 + t3.jd2. So what do you do then? Do you say they have to be within a certain tolerance to be considered equal? And if so, how do you set that tolerance? And what if a user assumes a different tolerance than you choose?I suppose your right that this is a bit more immediate of a problem in
coordinates, because the transformations there are generally more complicated (so the fp errors add up faster), but in principal you have the same eventual ambiguities, right? So the alternative is to have__eq__be pretty dumb (e.g., justself.jd1 == other.jd1 and self.jd2 == other.jd2), and leave it to the user to decide how close is good enough.Merge pull request astropy#601 from rosteen/update-specutils-maintainers