Hi Ben,

Thank you. Given the message below, and the details you sent privately from
'more info', a light begins to dawn...

I think I've fixed this. I have two more fixes to do before I post another "in
testing" update (to a problem with finding conjunctions/occultations, and to a
problem in determining the angular separation of two objects using their refracted
positions instead of their airless positions). Once I've made those fixes, I'll
be ready to post.

I'm not surprised that some people don't see this bug (including me, at first).
The bug would affect certain NEOs when using MPCORB, but would be easy to overlook
or to simply have it not happen, depending on how you were running Guide.

(The following describes a lot of minute detail of how Guide shows asteroids.
Some people will probably find it very interesting. But don't worry if you skip
it; it doesn't actually affect how any user uses Guide.)

The issue you found would affect certain close-approach objects when using
MPCORB-type data. In that situation, Guide does some optimizations for speed.
It has to do this because computing the positions of a half million objects can
be pretty slow, even on modern hardware. (Moore's Law states that computers will
get to be about twice as fast every 1.5 years, but it seems as if the number of
known asteroids has doubled at about that rate, too. So asteroid display was
pretty slow in Guide 1.0, and remains about as slow in Guide 9.0.) The problem
you see is that one of the optimizations had a bug in it.

Anyway. When Guide "sees" that MPCORB has changed, it computes a file that
contains, for each asteroid, an RA/dec rectangle around the path of that object
for a 50-day period, and the maximum brightness reached over those 50 days. It
takes a little bit of time to compute all that, of course. But once it's done,
you can do a lot of zooming and panning and re-centering, and Guide can just
say (for 99% of the asteroids): "No, that one can't be in the current field
of view... no, that one doesn't get bright enough over the current 50-day
period to appear on this chart", for most asteroids, most of the time. It
makes things a lot faster, since 99% of the objects can be skipped for any
given field.

NEOs pose a challenge to this scheme. For them, Guide says: "Set the rectangle
to cover the full sky and the maximum mag reached to 5.0. It's just too tricky
to determine the real limits for this object over the current 50 days." Therein
lay the bug: the mag limit wasn't set to 5.0, and the actual computed mag
limit could be off. That's what I fixed.

As you might expect, one problem with this scheme is that if you reset Guide's
date/time by 50 days or more, it has to recompute all that data. The hope is that
this won't happen too often. In practice, it seems to work pretty well.

-- Bill