skyfielders / python-skyfield

Elegant astronomy for Python
MIT License
1.41k stars 211 forks source link

Please allow users to decide the number of significant digits of distance in AU or KM by themselves. #467

Closed reza-ghazi closed 3 years ago

reza-ghazi commented 3 years ago

Hi Brandon,

Precisions of the angular and cartesian positions are very precise, but I don't know why you chose to show the distance only with six significant digits!?

All calculations are based on the same data, and with these data, we can have way more significant digits for distance in AU or KM. I believe somewhere in your code, you decided to round it up, but it's better to let the users choose the significant digits by their purpose like the other positions.

Thank you,

brandon-rhodes commented 3 years ago

You can control the precision by taking the numbers in position.au and formatting them using Python's standard formatting operators. What output are you seeing that concerns you? What does it look like?

reza-ghazi commented 3 years ago

I know we can use different units, but my concern is in, for example, AU unit, we only have 6 decimal digits, while we can have almost 14 digits. How can I increase the precision of the distance?

brandon-rhodes commented 3 years ago

Python offers several mechanisms — % formatting, the .format() method, and f-strings in the most recent Python versions — for getting a float value and printing it however you want. I can't recommend an approach unless I see the output you are concerned about, though, because if you are printing a whole array then you instead need to consult the NumPy documentation about setting output precision, which is outside of Skyfield's control. What output are you seeing that concerns you? What does it look like?

reza-ghazi commented 3 years ago

Please let me give you an example:

kernel = ''ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/de430t.bsp''
ephemeris = load(kernel)
earth = ephemeris[399]
sun = ephemeris[10]

tt = ts.tt(2020, 1, 1, 0, 0, 0)

astrometric_gca = earth.at(tt).observe(sun)
apparent = astrometric_gc.apparent()
ra, dec, req = apparent.radec(epoch='date')

print(f'Apparent Geocentric, the epoch of date:\n'
      f'---------------------------------------\n')
print(f'α: {ra.hstr(places=6)}\t\tδ: {dec.dstr(places=6)}\td_obs: {req}')

The above codes give us the following output:

Apparent Geocentric, the epoch of date:
---------------------------------------

α: 18h 43m 33.112474s       δ: -23deg 03' 31.983219"    d_obs: 0.983293 au

As you can see, the distance output has only six decimal digits. So, how can I increase the decimals as I want?

Numpy has an option np.set_printoptions(precision=value) which with defining value gives you more precision in print. I tried all possible formatting (format strings) and numpy options, but I still get six decimal digits.

Thank you,

brandon-rhodes commented 3 years ago

As you can see, the distance output has only six decimal digits. So, how can I increase the decimals as I want?

Thanks for offering an example! Since this is a single value, and not an array of values (which would be surrounded by [ ] characters indicating a NumPy array), you can format it using Python format characters. For example, to always show 17 digits of precision:

print(f'd_obs: {req.au:.17f}')

Or to show the same number of digits necessary to type the float back in to a Python program without losing any precision:

print(f'd_obs: {req.au!r}')

Where in the documentation might I include a link to more information about programming Python and about Python formatting options, so that folks trying to display distance values are led to the correct documentation?

reza-ghazi commented 3 years ago

Thank you.

Frankly, I thought the default output is always in AU, so I never realize we should include the AU attribute for better precision.

As you see in my code, I used the formating, and I tried any format string on it, but the only problem was, I didn't mention, .AU. I believe you should say it in the documentation. Honestly, it's a little bit confusing, though.

Anyway, thank you and have a great time.

brandon-rhodes commented 3 years ago

I believe you should say it in the documentation.

I am happy to add it to the documentation! Where should it go, so that you would have seen it? What section were you reading?

reza-ghazi commented 3 years ago

Hi, Brandon

Thank you for caring for all requests.

These details can be mentioned during the calculation of a planet position or maybe in the Position section. For example, the following areas are good choices:

Positions and Coordinates

or

distance

Having different examples is very useful, though.

Finally, why are you still working with DE421 in the Skyfield examples, and you are not shifting to DE430 or, a more accurate one, the DE438? Skyfield is fully compatible with the new Series.

DE438t is based on DE430 with the same coverage and more significant improvement for accuracy.

Note, I have heard, but I am not sure that their interpolation techniques are different. DE430 is based on Chebychev polynomials, and DE438 is based on Hermite polynomials. But as I checked, they use the same structure and nomenclature in their BSP files.

I am using DE438, and it works perfectly with Skyfield.

Thank you,

brandon-rhodes commented 3 years ago

Finally, why are you still working with DE421 …

Correct me if I am wrong, but so far as I have read:

  1. All of the ephemerides in the DE4xx series are equivalent in accuracy for the purposes of the examples in Skyfield. The position of Mars in the sky, for example, should be the same.
  2. So the choice can be made on other criteria.
  3. And the criteria I have chosen are (a) stability — Skyfield's documentation and examples stay stable — and (b) size, since I commit the ephemeris to Skyfield's repository to avoid the CI systems having to download the ephemerides all the time and using lots of NASA bandwidth. DE421 is a very nice size, and I like to encourage users to use it for that reason. Encouraging them to use ephemerides whose accuracy they don't need would use even more NASA bandwidth, without benefiting most users.

I had not heard of Hermite polynomials, I'll have to look them up sometime.

reza-ghazi commented 3 years ago

Of course, it was just a suggestion. From the point of view of the size and uploading time for the first time, you are absolutely right. But after the first time, users can keep the file and use their local files.

Anyhow, Skyfiled has the ability to support the professionals too. At least some examples can be made by new ephemerides to demonstrate the implementation's powerfulness, maybe on the first page.

At last, this is your child, and you are the person who makes the final decisions.

Extra: I am using python 3.8 and 3.9, and I didn't find any compatibility issues so far, just for the record.

Best,

brandon-rhodes commented 3 years ago

Anyhow, Skyfiled has the ability to support the professionals too. At least some examples can be made by new ephemerides to demonstrate the implementation's powerfulness, maybe on the first page.

I will see whether one or two prominent examples could be moved to a new ephemeris. And I can cheat: I can commit to the repository an ephemeris with the right name, but that is actually an excerpt of only a few weeks from the real ephemeris, and the front-page example could still come out fine.

Extra: I am using python 3.8 and 3.9, and I didn't find any compatibility issues so far, just for the record.

Thanks for letting me know!

reza-ghazi commented 3 years ago

Carlos Fernando Flores Labra, a Chilean entrepreneur and politician, has a famous quote:

Great work is done by people who are not afraid to be great.

And I believe you are great.

Regards,

brandon-rhodes commented 3 years ago

I have updated the documentation so that the Distance object talks more about itself and illustrates how formatting works. We will see whether future users have similar questions or not!

And thanks for the very encouraging words, I hope you continue to enjoy Skyfield!