Closed Bernmeister closed 3 years ago
It took a bit of searching to find where it was happening, but it was down at the lowest-level call to interpret a float that the 0.0
value was being generated. I've added a little check to the C code that detects the case of an empty string manually and sets the result to nan
instead of 0.0
. It doesn’t break any tests, so hopefully doesn’t break any other corners of PyEphem that might use that routine.
It might be a while before the next release, but when it happens, this fix should be included!
When running both PyEphem and Skyfield to produce apparent magnitude for comets and minor planets, sometimes PyEphem gives me a magnitude for a minor planet but Skyfield does not (I have not seen this happen with comets, but I suspect this is just luck).
To clarify, PyEphem computes the apparent magnitude using the H,G or g,k model, depending on the data format. In Skyfield, I take the H,G (or g,k) values and use those to calculate my own apparent magnitude. All data files for comets and minor planets are sourced from the Minor Planet Center.
Digging deeper it seems when the data file is missing the H value, PyEphem will insert a value of zero for the H value into the computed body. Skyfield on the other hand inserts a
nan
. This is not an issue in Skyfield because I can remove spurious data from the dataframe:(or remove from the data file itself prior to passing in to Skyfield).
I'm not sure what PyEphem can do as
readdb
function looks to me as a stub into the C library. I'm happy enough to screen the incoming data for missing bits (before passing toreaddb
), but I would like to know please if my analysis is correct.See test code below: