NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Longhand Sight Reduction
From: Greg Rudzinski
Date: 2014 Nov 19, 10:50 -0800
From: Greg Rudzinski
Date: 2014 Nov 19, 10:50 -0800
Hanno,
You are so right on the increased probability of errors when there are special rules, sign changes, and logs used for sight reduction. As a matter of fact I just made an error in my previous post stating same name rather than contrary name. Unfortunately we are stuck with the same name / contrary name rule.
G
From: Hanno Ix
Date: 2014 Nov 19, 09:33 -0800
Greg,
In my recent CoSi table I sent Francis I have deleted the Doniol formula. First, the universality of cos / sin goes far beyond Doniol. The other reason is the very issue you are talking about.
I hate special cases and rules for distinctions between cases. Their correct application depends on memory which can, and therefore will, fail - particularly in stress situations. I am a glider pilot and have stories to tell about navigation in stress!
Also, I can show you places in CelNav literature, even in recognized CelNav, literature, where such errors occurred AND were not corrected through several editions. This is also the reason I hate logarithms. The possibilities for errors in their CelNav applications are literally "numerous" .
RE: Doniol. The prior version used cos(x) which is insensitive to the sign of x, other than sin(x) or tan(x). This feature alone makes the it very attractive. The sign of cos(x) is however still sensitive to the absolute value of x. The haversine-Doniol kills even that error source. That, then, makes our latest version of D virtually iron-clad against sign errors. So I thought the cos-Doniol should not be even brought up any more.
You mentioned the application of the cos version for calculators. Personally, if I were to use a calculator here I'd still prefer the haversine version but replace hav(x) with [sin(x/2)]^2 and bypass any sign rules again. This alone, for me, would justify the extra keystrokes. Space on a RIC would not be an issue. And IF one uses a calculator to begin with why not one that can be programmed? Cheap enough!
Greg, this Doniol discussion with you has been very interesting. Who knows, we might not even done with it!
Hanno