Skip to content

Conversation

@mhvk
Copy link
Contributor

@mhvk mhvk commented Dec 22, 2013

Another PR addressing #1924. Now:

In [1]: from astropy.time import Time, TimeDelta
In [2]: t = Time(54555.0, 0.12345, scale='utc', format='mjd', lat=30, lon=-75)
In [3]: print(t.lat, t.lon, t.tdb.jd1, t.tdb.jd2, t.tdb.delta_tdb_tt)
30d00m00s -75d00m00s 2454555.5 0.1242044693704408 [ 0.00215361]
In [4]: t += TimeDelta(0, format='sec')
In [5]: print(t.lat, t.lon, t.tdb.jd1, t.tdb.jd2, t.tdb.delta_tdb_tt)
30d00m00s -75d00m00s 2454556.0 -0.37579553062955917 [ 0.00215361]
In [6]: 0.1242044693704408 - -0.37579553062955917
Out[6]: 0.5

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at replicate we probably want to copy 'precision', 'in_subfmt', 'out_subfmt' as well:

        # Optional or non-arg attributes
        attrs = ('isscalar', '_delta_ut1_utc', '_delta_tdb_tt',   # <== These should *not* be copied
                 'lat', 'lon', 'precision', 'in_subfmt', 'out_subfmt')

Same applies for __add__.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I thought about trying to somehow use replicate to avoid this hardcoding of the relevant attributes. The problem here is that the _delta_* attributes should not be copied because they get invalidated by the arithmetic. Thus you end up with a net gain of several lines of code, although that solution would be more future-proof to the addition of attributes in the future. Something like this might work:

tai = self_time.replicate()
tai._time.jd1 = jd1
tai._time.jd2 = jd2
tai._time.scale = 'tai'
tai._delta_ut1_utc = None
tai._detla_tdb_tt = None

Anyway, just thinking out loud.

@mhvk
Copy link
Contributor Author

mhvk commented Dec 23, 2013

@taldcroft - sorry to change the ground, but as it seemed we would need to support a complete location including height anyway, I made another -- hopefully better -- attempt at keeping information around using a new location attribute -- see #1928. Could you have a look?

@taldcroft
Copy link
Member

@mhvk - I've looked at #1928 and it generally looks OK. The only thing is that I think the whole EarthLocation class is a bigger deal, with tests and user docs, and you'll want buy-in from at least @eteq and probably @astrofrog. It's the holidays so that might not be forthcoming (but who knows). So this little bug could be knocked off pretty quickly in this PR and not be dragged along in #1928.

@mhvk
Copy link
Contributor Author

mhvk commented Dec 25, 2013

@taldcroft - you're right, we can at least have this as a bug-fix in 0.3.1, while we work to ensure we have a proper location for 0.4. I updated the PR, following your revised logic about how to implement the arithmetic (and adding extra tests for other properties).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this is a very nice simplification of the logic! Just one corner case that I think it isn't handling, that of a length=1 array initializing Time:

In [4]: t1 = Time([1.], format='jd', scale='tai')

In [5]: t1.isscalar
Out[5]: False

In [6]: len(t1._time.jd1)
Out[6]: 1

By your len(jd1) == 1 test below I think this will convert a len-1 array to a scalar. I think you just need a line here with:

result_isscalar = self.isscalar and other.isscalar

So only if both the inputs are scalar then the output is scalar. Then use result_isscalar instead of len(jd1) == 1.

@taldcroft
Copy link
Member

Apart from the one comment this looks great.

@mhvk
Copy link
Contributor Author

mhvk commented Dec 28, 2013

@taldcroft - yes, indeed, was not quite right. Now use your suggestion (and added tests; I checked the new behaviour is the same as that of numpy).

@mhvk
Copy link
Contributor Author

mhvk commented Dec 28, 2013

@taldcroft - think the lon, lat preservation is ready to go in.

taldcroft added a commit that referenced this pull request Dec 28, 2013
Ensure all relevant Time attributes are passed on in Time addition/subtraction
@taldcroft taldcroft merged commit 4bdee60 into astropy:master Dec 28, 2013
@taldcroft
Copy link
Member

Thanks!

@mhvk mhvk deleted the time-keep-lon-lat-in-arithmetic branch December 28, 2013 22:42
taldcroft added a commit that referenced this pull request Feb 12, 2014
Ensure all relevant Time attributes are passed on in Time addition/subtraction
taldcroft added a commit that referenced this pull request Feb 12, 2014
Ensure all relevant Time attributes are passed on in Time addition/subtraction
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants