Changes for 15 Dec 2010:

   * I wanted to be able to output dates without spaces in
'full_ctime( )',  so I added a FULL_CTIME_NO_SPACES macro
in date.h and added a few corresponding lines to 'miscell.cpp'.
This was done to support some things going on in 'astcheck.cpp',
a new program that reads 80-column MPC astrometry data and looks
for corresponding objects.  'astcheck' is now included with this
code,  since it's a decent demonstration of some of the things
in this library.

Change for 1 Oct 2010:

   * Realized that 'get_time' handled decimal year input
relative to J2000 = JD 2451545,  i.e.,  1.5 January 2000.
Integer years were handled relative to 1 January,  which
makes more sense.  So I redefined J2000 to be JD 2451544.5.
Now,  entering a value such as 1999.99999 gives a value
shortly before 1 January 2000,  instead of just before midday
on that day.

Changes for 19 Sep 2010:

   * Added observed Delta-T data for January 2010 to the array of
Delta-T values in 'delta_t.cpp'.  Also added three projected leap
seconds for 2013,  2016,  and 2019,  to keep UTC-UT1 close to zero
over the next decade.  (Those projected leap seconds will almost
certainly prove to be wrong.)

Changes for 13 May 2010:

   * Martin Ettl kindly passed on some results from 'cppcheck'
(http://sourceforge.net/projects/cppcheck/), which revealed
the following issues:

[phases.cpp:295]: (Error) Resource leak: log_file
[phases.cpp:295]: (Error) Resource leak: data_file
[de_plan.cpp:299]: (Error) Resource leak: ifile
[persian.cpp:216]: (Error) Memory leak: jds
[mpcorb.cpp:29]: (Error) Uninitialized variable: rval
[rckin.cpp:75]: (Error) Resource leak: ifile
[elp82dat.cpp:383]: (Error) Deallocating a deallocated pointer: ifile
[colors.cpp:275]: (Error) Resource leak: ifile

   As it happens,  none of these are particularly worrisome.  In
certain processing programs,  I've relied on the fact that files
are closed and memory freed when the program terminates.  All of
these issues,  except for the one in 'elp82dat',  are of that sort.
I am reasonably certain that the 'elp82dat' reflects a problem in
cppcheck.

   Still,  I'm impressed with the fact that 'cppcheck' was able to
find such issues,  and would like to be able to use it in the
future.  So I've fixed all of the above issues (except the elp82dat
one),  in hopes of getting a clean bill of health from cppcheck in
the future.

Changes for 28 Mar 2010:

   * showelem.cpp:  All calendar conversions were being done with the
Gregorian calendar only.  I revised it so that the Julian calendar is
used before October 1582.  (Basically just meant using
CALENDAR_JULIAN_GREGORIAN rather than the default.)

Changes for 2 Feb 2010:

   * 'date.h':  added some macros demonstrating how one can set the
precision and format for date output.

Changes for 15 Feb 2010:

   * 'chinese.dat':  Following a question from Mark Sims,  I realized
that certain years in the data file for the Chinese calendar were set
incorrectly.  Specifically,  any year in which the preceding year had
an '11i' or '12i' intercalary month was stored with garbage data.  This
occurred in 68 years over the 5990-year range of the original
'chinese.dat'.  This was due to a small bug in the processing programs.
I've fixed this,  and generated a new 'chinese.dat' covering the years
-3000 to +7000 Gregorian (the previous one covered -3000 to +2990).

   Be advised that,  since the Chinese calendar is an observational one,
the extrapolations into the past and future get to be iffy as uncertainty
in Delta-T grows.  If the time of New Moon is very close to midnight
Chinese time (zone UT+8 hours),  a small change in Delta-T may cause a
month to begin a day earlier or later.  The first such case is the
lunar month corresponding to a New Moon at 28 Sep 2057 16:00:17 UT,
just after midnight in the UT+8 zone.  But some sources (including the
Hong Kong observatory) have this occurring just _before_ midnight.  The
uncertainty in Delta-T for 2057 is such that either of us could be right.
As one goes further into the future (or past),  uncertainty in Delta-T
grows,  and so does uncertainty about the calendar.

   Similar issues plague the Jalali calendar and the French Republican one
(sort of;  note that it's unclear if the Republican calendar was intended
to be algorithmic or observational).

Changes for 29 Jan 2010:

   * 'triton.cpp'/'marsuran.cpp':  Realized that 'marsuran' was essentially
no longer in use,  and in some cases shouldn't be used (the Uranian and
Martian satellite solutions were abysmal).  Ideally,  I'd just drop this
file completely.  But it also contains an algorithm for Triton's position,
which I need to keep because the 'rocks' solution is wrong (see comment
below for 'rocks.cpp'.)

   So I removed most of 'marsuran.cpp' and renamed it to 'triton.cpp'.
The renaming seemed wise,  given that all Martian and Uranian satellites
had been completely removed!

   * 'rocks.cpp':  realized that the data for Triton must be wrong somewhere;
the orbit given in this file (from JPL's NEP050 solution) results in
prograde motion.  I've not puzzled it all out yet,  but it's definitely
wrong.  Added a suitable comment to warn about this.

   Also,  Uranians are all based on URA091 now (instead of,  mostly,
URA086X.)

   * 'get_time.cpp':  Removed the 'scan_for_time' variable,  which was
occasionally set,  but never actually used anywhere.

   * 'cospar.cpp':  Realized that errors were mis-handled.  There's
code to extract the planet orientation and spin rate from 'cospar.txt',
then save it for the next call... but the error code was _not_ saved
for the next call.  Some of my code was therefore thinking it was getting
a perfectly decent orientation matrix,  even though it wasn't.

   Also,  added orientation data for the Plutonian moons Hydra and Nix.
No 'official' model exists for these,  but as described in 'cospar.txt',
I was able to make a reasonable rotation model for them.

Changes for 11 Jan 2010:

   * 'showelem.cpp':  now supports more digits of precision,  enough to
support the full range of 64-bit floats.  This isn't apt to be very useful
to anyone;  I added it to simplify some debugging I was doing in Find_Orb.

Changes for 24 Nov 2009:

   * Fixed some loss-of-precision problems in 'classel.cpp'.  Specifically,
I noticed that the argument of perihelion was computed using arcsin,
so that if sin(arg_per) was near +/-1,  you'd lose precision.  In fact,
one could get a result slightly outside the -1 <= sin(arg_per) <= 1 range.
Also did a lot of cleanup.

Changes for 21 Oct 2009:

   * Made a lot of small changes to evade gcc and MinGW compiler warnings.
I also investigated an old optimization bug in 'de_plan.cpp',  but was
unable to replicate it.  For the nonce,  at least,  I'm leaving optimizations
fully enabled.

Changes for 20 Sep 2009:

   * Fixed a bug in 'date.cpp' wherein a 'month_data' buffer of 13
bytes was subjected to the line

   memset( month_data, 0, 14);

   I think this got by because the extra byte was blank anyway.  But
the latest gcc caught this bug and considered it to be 'stack smashing'.
In the investigation of this bug,  I cleaned up some of the date.cpp and
jd.cpp code: no changes in functionality,  but it's easier to read.

Changes for 9 Apr 2009:

   * Added some comments to 'integrat' explaining how the integration
scheme works.

Changes for 4 Apr 2009:

   * Added a 'make' file for MinGW (gcc for Windows).  Everything compiled
Just Fine,  except for an issue with the use of asinh() in astfuncs.cpp.
That source file now recognizes that asinh is only needed with Microsoft
Visual C/C++.

   * COM_FILE.CPP:  when extracting a periodic comet name,  preference
now goes to the permanent designation.  So if given P/Van Ness (213P)
(P/2005 R2),  the name extracted would be (213P).  This should help
to evade some problems with certain comets appearing twice.

Changes for 21 Mar 2009:

   * Various files:  This code does a fair bit of direct reading of structures
from files on disk.  To do that,  it relies heavily on sizeof(short) = 2
and sizeof( long) = 4.  This is,  of course,  stupid,  and means any
64-bit compiles will break.  Where structures are read from disk,  they
now use int16_t and int32_t,  instead of short and long.

Changes for 16 Mar 2009:

   * GET_TIME.CPP:  If the input date/time has a field with a decimal
point,  you can be pretty sure that that is the day of the month. The
code now makes use of this fact for puzzling out the formats.  (For
example,  both '9.75/4' and '4/9.75' would be interpreted as 9 April
18:00.)

Changes for 13 Feb 2009:

   * ROCKS.CPP:  Got data for Deimos and Phobos from Bob Jacobson at JPL.
Rearranged the rock elements slightly,  and they're now in numerical order.
Also wrote a little 'rckin' program to take the JPL format and convert it
into C code,  fixed a mistake of long standing in the numbering of
Uranus XXV = Perdita,  and enabled certain satellites that had been
disabled (simply because Guide wasn't using them).

   * BIG_VSOP.CPP:  Added a file 'big_vsop.txt',  which describes how this
function and the data are set up.

   * INTEGRAT.CPP:  Improvements to handling input dates in various formats,
fix to allow Pluto to be in the file.  See 'integrat.htm' for details.

   * GUST86.CPP:  Code to compute positions for five main satellites of
Uranus (Miranda = Uranus V, Ariel = Uranus I, Umbriel = Uranus II,
Titania = Uranus III,  Oberon = Uranus IV).  Thanks are due to Chris
Marriott,  the author of _SkyMap Pro_,  for the original version of this
code.  I've had this sitting on my hard drive for an embarrassingly long
time.  See 'uranus1.cpp' and 'uranus2.cpp' for usage demonstrations.

Changes for 23 Oct 2008:

   * ASTFUNCS.CPP:  the kepler( ) function has gone unchanged for about
a decade,  so I was surprised to find _two_ bugs in it.  For certain
hyperbolic,  very high mean anomaly cases,  it failed to exit a loop,
because it looked for fabs( err) < thresh .  In reality,  delta_curr
was becoming suitably small,  and that was the value that should have
been tested.

   Also,  for elliptical cases,  the mean anomaly really ought to be
kept in the range -pi < mean_anom < pi.  For M slightly outside that
range,  you lose a little precision and waste an iteration or two.
For M far outside that range (i.e.,  "many orbits completed"),  you
lose _lots_ of accuracy.

   This also caused me to see some possibilities for loss of precision
with nearly-parabolic orbits,  resulting in a new 'near_parabolic'
function that does essentially the same math,  but in a way that avoids
subtracting nearly-equal quantities.

   * DELTA_T.CPP:  added newly announced leap second for end of 2008.

   * ROCKS.CPP: Updated orbital elements for Pan and Daphnis,  from
SAT276 to SAT291.

   * GET_TIME.CPP: added better handling of offsets,  so one can have
'13:14-10m +3h' interpreted as 16:04,  for example.  Also,  days of the
week can be entered (which meant I had to add some day-of-week functions
to 'date.cpp').

Changes for 6 Apr 2008:

   * GET_TIME.CPP: function mostly extracted from Guide that parses
time strings, sort of an inverse of 'full_ctime'.  It attempts to handle
odd inputs 'logically' (i.e.,  "2007-10-17" will be understood even if
those three values are in an odd order,  because 17 is clearly a day
of the month and 2007 a year,  leaving 10 as the month).

   * GET_TEST.CPP runs assorted tests of the above function.

   * MISCELL.CPP: fixed a rather stupid series of bugs in 'full_ctime'
which caused instants a few microseconds shy of midnight to appear as
2:24:00 (i.e., one-tenth of a day).

   * DIST_PA.CPP now has a "reverse" function:  given a point and
distance and position angle,  it computes the resulting point.

   * VISLIMIT.CPP was set up so that the instant the moon went below
the horizon,  its contributed light went to zero.  I'm not sure what
the actual behavior should be,  but that was definitely wrong.  I
revised it to have a fairly sudden exponential decrease as it goes
below the horizon.

   * JD.CPP shows Delta-T for the selected time.  That just provided
me with a convenient testing mechanism.  It also now uses the 'get_time.cpp'
function,  so the date on the command line can be more flexible (and
so I can test the 'get_time.cpp' functions.)

Changes for 2 Feb 2008:

   * ROCKS.CPP:  Updated most of the rocks and added some new ones.

   * COSPAR.CPP:  Revised so it gets data from 'cospar.txt'.  This
allows it to generate correct rotation data,  including the previously
neglected smaller terms,  for all planets and satellites,  including
many previously ignored as "insufficiently important".

   From time to time,  changes may be made to the COSPAR data in
'cospar.txt'.  (For example,  the model for Mercury was recently
improved,  and one matching the average rotation rate of the clouds
of Venus was added.)  Those changes will be described at the end of
that file,  in the comments section.

   The previous implementation is still provided,  as 'cospar2.cpp',
just for reference;  I don't expect to be making any use of it.

   * DELTA_T.CPP:  Updated the Delta-T lookup table.

   * EASTER.CPP:  23 Mar 2008 is Easter,  and a neighbor of mine asked
about when Easter would be so early again.  I revised the test routine
so you can find out in which years Easter will fall on a given day
(in addition to the previous,  more common "when will Easter be this
year").

   * SHOWELEM.CPP:  Epochs with precision greater than .01 day were
"shifted" to the nearest .01 day and the mean anomaly adjusted
accordingly.  This is fixed:  if you specify the "usual" sort of
epoch (i.e.,  midnight UT for some date),  the output will look as
it always did (truncated to one decimal place),  but otherwise,
decimal places will all get shown.

Changes for 3 July 2007:

   * JD.CPP:  Added code so that most cases where day/month/year
is entered on the command line,  instead of year/month/day,  will
be corrected.

Changes for 8 June 2007:

   * ROCKS.CPP:  Converted some variables to type 'const' to
help me see what the heck is going on.

   * INTEGRAT.CPP:  Made some small revisions because MPC altered
the 'mpcorb' format very slightly,  so that when the program looked
for the names 'Ceres',  'Pallas',  and 'Vesta',  it didn't find them.
Now it will,  whether the input is in the old or new format.

Changes for 23 April 2007:

   * JD.CPP:  Added an error message for cases where no date is
specified on the command line,  removed some unused macros and
variables,  and changed certain "variables" to be of type const.
(This is largely cosmetic:  if a particular "variable" is,  in
fact,  constant,  I like to make that fact obvious.)

   * ASTEPHEM.CPP:  This program now gets orbital elements from
'mpcorb.dat' (or 'mpcorbcr.dat'),  rather than from Guide-format
elements.  As before,  it uses those elements to generate
asteroid ephemerides.

   * COSPAR.CPP,  MISCELL.CPP:  compiling with gcc -Wall caused
a few warning messages to appear,  mostly for cases where things
defined as 'int' should have been 'long int' or vice versa.
Again,  cosmetic (unless one were on a system wherein 'int'
differs from 'long'.)

Mid-2006 changes:

   * ASTFUNCS.CPP:  A couple of lines in the 'kepler' function for
handling "hyperbolic, large-mean-anomaly cases".  Such cases caused
overflow problems (when _really_ hyperbolic and large-MA... but such
cases arose with objects in planetary encounters.) */

   * DIST_PA.CPP:  As comments in the source indicate,  there was a
roundoff problem with certain position angles where the RAs were
identical, or nearly so.  I essentially had to do a total rewrite,
abandoning the haversine-based approach.

   * SHOWELEM.CPP:  Distances are now shown in kilometers (not AU)
whenever they are less than 400000 km (roughly the distance from the
earth to the moon).

   * DELTA_T.CPP: Added leap second for 1 January 2006,  plus comments
on which leap second is which.

Changes for 29 March 2005:

   * SHOWELEM.CPP:  The 'decimal_day_to_dmy' function now takes a
'calendar' argument,  instead of assuming Gregorian.  That allows
use of the function by assorted calendar-dependent routines in Guide.
Most other uses will just pass in a 0 (Gregorian) value.

   * REFRACT4.CPP:  Some code for a 'reverse_integrated_refraction'
function,  which inverts the 'integrated_refraction' function.

Changes for 3 Feb 2005:

   * DATE.CPP:  Found and fixed a bug in the 'is_hebrew_leap_year' function.
   * SOLSEQN.CPP:  Added some error handling for cases where the 'big_vsop.bin'
file isn't found.
   * Generally:  Switched use of asin( ) to asine( ),  i.e.,  the version that
protects against domain errors.  I was getting such errors in Find_Orb,
and was trying to track them down.  It turned out to have nothing to do
with asin( ) calls in this library... but they're a good idea anyway,
just on general principle.

Changes for 16 Dec 2004:

   * DATE.CPP:  Changed a lot of variables to be of type 'const'.
This has no bearing on the actual operation of the code,  but it
does mean that a human reading the code can say:  "OK,  I know
these variables aren't going to change within the function."

Changes for 1 Dec 2004:

   * DELTA_T.CPP:  Previously,  there was an adjustment to Delta-T
within the code now marked by "#ifdef TRY_OMITTING",  for years before
1620.  The idea was that the formulae for Delta-T were originally
derived with an assumed lunar secular acceleration of 26 arcseconds
per century^2.  If you use a theory such as VSOP or ELP,  which
assume a secular acceleration of -23.8946 arcsec/cy^2,  then you
have to assume the earth's spin is,  in the long run,  decelerating
at a different rate... after all,  if the moon is receding at a different
rate,  it's soaking up the earth's angular momentum at a different rate,
too.

   However,  I'm now using DE-405 and DE-406 for just about everything.
I could have made sure that Delta-T was adjusted for DE-40*,  or the
other way around.  I chose the latter.  (Dealing with these assorted
time systems is a heck of a mess!)

   * ALT_AZ.CPP:  Some new code to add "supergalactic" transformations
as a parallel to the galactic ones.

Changes for 7 April 2004:

   * DATE.CPP:  the "modern Persian" calendar is now supported.  This
corresponds quite closely to the traditional Jalaali calendar,  but
instead of being a purely observational calendar,  683 leap years are
spread evenly over a 2820-year span.

Changes for 17 Dec 2003:

   * MISCELL.CPP:  the 'full_ctime' has been mostly rewritten to allow
handling of different calendars,  and more flexible formats and setting
of levels of precision.  Most of this was required by my Guide software,
to support a new feature wherein people could specify exactly how times
and dates are to be formatted (see
http://www.projectpluto.com/update8.htm#time_format .)  All this also
meant some changes to the FULL_CTIME macros in 'date.h'.

   * DATE.CPP:  the code for setting/storing month names used to copy
in the month names provided to set_month_name(),  which meant you
couldn't have excessively long names (more than six bytes plus a
trailing NUL). Now,  instead,  set_month_name() maintains a table of
pointers to the user-specified month names,  and provision is made
for a thirteenth month name (useful for the Hebrew and French
calendars).  All this was required for the same 'time_format' dialog
described in the URL given in the previous paragraph.

   * DELTA_T.CPP: brought the table of delta_t values up to date.
Values for late 2003 were off by about 1.2 seconds!

   * INTEGRAT.CPP: this code used to assume that the first,  second,
and fourth asteroids in an 'mpc_orb.dat' file were Ceres,  Pallas,  and
Vesta.  It then assumed that it could compute positions for these three
asteroids,  and compute perturbations caused by them.  That was a bad
move,  since there are 'mpc_orb'-formatted files that don't contain these
four objects.  The code now looks for the actual asteroid names "Ceres",
etc. instead.

   * NUTATION.CPP: fixed an erroneous coefficient reported by James
Miller and Mark Huss;  that repair required me to clarify the code a
bit. It's not quite as cryptic as previous versions were.

Changes for 12 Dec 2002:

   * Added REFRACT4.CPP,  code to compute a truly "accurate" refraction
value via numerical integration.  Compare to the code in REFRACT.CPP
(which is much simpler,  but not quite as precise.)

   * COLORS.CPP was fixed to read 'loneos.pho' properly (it was getting
confused by lines where the RA was given to .001-second precision).

   * The Republican calendar code in DATE.CPP was returning weird
values (and sometimes just locking up!) for dates prior to
JD 2007729.5 or after JD 2598322.5.  The values outside that range
are still not necessarily exact,  but should at least be close,
with more "graceful" degradation of accuracy.

   * REFRACT.CPP had an error,  where I thought the input value was
in degrees,  but it was really in arcminutes.

   * INTEGRAT.CPP and SHOWELEM.CPP had slightly "bad" planetary masses
(in particular,  that for Earth was off by about .5%!)

Changes for 6 June 2002:

   * There's now a LUNARDLL.MAK file,  for creating a 32-bit Windoze DLL.

   * The #defines for AU_PER_DAY and AU_IN_KM were moved into
'afuncs.h'.  I hadn't realized this,  but there were a few places
where both were defined with fewer digits than one might ideally like.
This affects a slew of files.

   * DATE.CPP:  the method for handling the French Revolutionary
(Republican) calendar was changed a bit.  You can still use the
"algorithmic" methods,  but there's some new code that allows you
to use the original ugly scheme in which the year begins on the
autumnal equinox,  so leap years occur at either four or five-year
intervals.  (#define's can switch you back to the other methods.)
The code looks much like that for the Persian Jalaali calendar,
and I used the same program,  PERSIAN.CPP (q.v.),  slightly modified,
to generate the lookup table.

   * DELTA_T.CPP now contains a table of values of Delta-T to .01
second,  not .1 second,  precision.  I made the size of the table a
#define,  since I keep increasing it a bit from time to time. There
are some new notes at the bottom of the file,  because at some point,
I want to include some code to give,  not just Delta-T = TDT - UT1,
but TDT - UTC.  For the latter,  I'll mostly just need a table of
leap seconds.  But none of this affects the code yet.

   * DIST_PA.CPP:  in reply to an inquiry as to how this function
works,  I added some comments and revised a bug in how the PA was done.

   * EASTER.CPP:  mostly cosmetic change of some values to type 'const'.

   * PERSIAN.CPP:  code added to do a similar analysis for the French
Revolutionary (Republican) calendar.  See DATE.CPP.  (I also switched
to use of the "full VSOP" as used in BIG_VSOP.CPP,  rather than the
"small VSOP" used previously.  That gave better accuracy,  but also
meant I had to make some minor changes to the make files.)

   * PRECESS.CPP:  Jordi Mas reported that the function
'setup_ecliptic_precession( )' was broken,  and has probably been
so since it was first written.  (I never actually had a situation
where I used it.)  It's fixed now.

   * SSATS.CPP:  After I got an inquiry about these formulae,  I added
some comments near the top,  and made some cosmetic changes such as
converting some values to be of type 'const'.