These are excuses for the unreliability of the search engine that I programmed to find the date of a planet when the location is known. With the easy availability of cheap ram now, it wouldn't be much of a problem to just let the code continue to grow (so long as someone doesn't decide to invent a new operating system every few years making the old code obsolete). But when I did this, it was pretty much imperative to keep it as small as possible (Dude: I once reduced 210 lines to 2 lines, but I ain't bragging). The underlying problem is frustration caused when consolidation of 2 or 3 procedures causes others to get wacky. There's like 72 of them & they're not sweet virgins.

(excuses Num. 6 to 72):
The basic solution is to choose the degree where the planet should be (A), and subtract that degree from wherever it presently is (at the date of the given chart) (B), multiply that difference by the average speed of the planet per day (C). The result is a multiplier converted into seconds, added to the origional start date (B), to estimate the date of where you want the planet to be (A). A chart is compiled for that date and the process is reprated until A = B. There are 6 variations of this loop for the 6 functions of planet location, there are 11 planets (including the sun, moon & north node) each planet moves at a unique average speed, and has a unique cycle of retrogradation. The interior planets are harder to manage because their speeds vary more per day, and they retrograde less predictably.

(2 to 5):
There is a changeover from 360 to 1 deg. (or 359 to zero deg). For example: when the engine is searching for a location with an estimated date greater than the present but in a degree less than the present degree, a unique algorithm is required. This algorithm has 4 variations.
  • later date and lesser degree.
  • earlier date and greater degree.
  • earlier date and lesser degree.
  • later date and greater degree. (an earlier date / greater degree would be: say the moon is in 10 of aries and I want to find the past date when it was in 10 degrees of aquarius (= 310 from 0 aries).
    At present I'm only using two booleans to decide this, because each boolean can give either true or false (which is 4 options, eh?).

    When the engine is searching for a date at the speed of a planet reaching its extreme in retrograde, the next degree may be several years, and plus one cycle, away but the rate of search may be in minutes beause the planet is slowing down & about to go direct. So the search finds the planet in the opposite direction and produces a false location for the estimated date, or if the error is rectified, the new date may be calculated at the slowed rate of movement which could place it several planetary cycles in the future. i.e. : if movement (at retro extreme) is so slow that it appears to be 1 degree per year, the multiplier (C) will multiply the difference between A & B by 1 year, instead of the true average speed of say 1/2 degree per day, or whatever it is. ok? ok. Get a life geek.

    While I'm sick of rewriting the same code and having the next rewrite undo the previous solution, the final bottom line is that I (currently) doubt if any graphs and numbers will ever change anyones mind about astrology.

    If you want to mess with any of these problems, email me & I'll send you a link. The deal is that it'll be open source freeware, and I get a source credit. Please be warned that this is a dumpster of spaghetti. It needs to be finished, de-bugged & adapted for PC. It's currently in Think Pascal 4. for 68k mac.