Re: [RFC] Astro:: modules

2003-10-18 Thread Joshua Hoblitt
 Anyway, here's what I got so far with the Astro:: stuff:

   Astro::Sun- stuff related to solar position
   Astro::Moon   - stuff related to lunar position
   Astro::Common - common calculation utilities

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.

   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. 
:)

   Astro::BigFloat - Wrapper to Math::BigFloat to allow
 toggling on/off the use of Math::BigFloat

Again, I'm concerned about namespace pollution.

 I by no means declare that these are good names: I used them just so I
 could roughly divide things up. Please suggest any ideas you might have.

 Here are some points that I'm kind of pondering about:
   - naming.
   - better organization

If all the algorithms are out of the CC book would about something like 
Astro::Calendrical::* ?

   - usage? is a plain procedural interface ok?

My personal preference is class methods over exporting stuff.

   use Astro::Sun qw(solar_longitude);
   my $degrees = solar_longitude($dt);

my $degrees = Astro::Sun-solar_longitude( $dt );

I think it makes the code more readable but obviously opinions are varied on this.

   - I think Astro::Common can be separated out into smaller packages.
   - when structure is settled, optimize a bit.

 Once I get the idea of how to organize these modules, I will polish them
 up, and bring them up again...


-J

--


Re: [RFC] Astro:: modules

2003-10-18 Thread Daisuke Maki

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



Re: Re: FW: DateTime questions...

2003-10-18 Thread rickmeasham
 
 
 
 
 Matt Wright [EMAIL PROTECTED] wrote: 
 Yes, I noticed this too, but there seemed to be quite 
a few problems 
 besides 
 just the compiler issue.  The Makefile came out 
very screwy as well, 
 with a 
 lot of missing single quotes, variables without any = 
signs after 
 them, etc. 
 
 
I had this problem with RH9 also  ...  seems that perl's 
Unicode and RH9's Unicode support got all tangled 
up. I fixed it by changing LANG=en_US in my bashrc 
to just 'LANG='. I read that somewhere ... anyway it 
works! I think perl downgraded it's unicode for 5.8.1 
because of this. I can't remember it's a while since I 
researched it. You might want to search perl port. 
 
Cheers! 
Rick