How common is "Common"? Remember there is stuff like
> Astro::FITS::CFITSIO (also a good example of why C
> interfaces suck in perl) under that namespace.

CC uses these functions throughout both solar and lunar calculations:

  julian_centuries
  nutation
  obliquity
  aberration

The rest of the stuff involves converting datetime based on location, ephemeris correction, etc. I'm not sure where they would go:

  # things I think DateTime already handles (I just used CC's
  # algorithms straight from th book for now):
  standard_from_universal()
  universal_from_standard()
  standard_from_local()
  local_from_standard()
  universal_from_local()
  local_from_universal()

  # requires ephemeris correction
  universal_from_dynamical()
  dynamical_from_universal()

  # miscellaneous
  rata_die() - just return DT at 1/1/1
  binary_search()
  search_next()

  local_from_apparent()
  equation_of_time()
  ephemeris_correction()

  # miscellaneous constants
  RD_MOMENT_1900_JAN_1
  RD_MOMENT_1810_JAN_1
  RD_MOMENT_J2000
  MEAN_TROPICAL_YEAR
  MEAN_SYNODIC_MONTH

I've tentatively separated out the mathematical stuff out to Astro::CalcUtils (eek, there's *got* to be a better naming). This involves things like polynomial(), angle(), sin_deg()/cos_deg() (trignometric calculations based on degrees).

I've also removed Astro::BigFloat in favor of functions in above mentioned Astro::CalcUtils, currently (tentatively) called:

  bigfloat()
  bf_downgrade()

to handle creation of Math::BigFloat objects (which can be toggled on/off to just return the original value) and downgrade to simple scalars.

 Astro::Earth::Location  - simple structure
       to store latitude/longitude, etc.

Do you know how accurate the algorithm is? Our local guru has a 308 term polynomial. :)

Hmm? this was just to store position. No accuracy involved.


I can't much speak for the accuracy of CC's algorithms, but seeing the error margin I would use it for datetime calculation, but not for rocket science.

--d



Reply via email to