NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Index Card for Trig/Log Table
From: George Huxtable
Date: 2009 Sep 10, 11:15 +0100
From: George Huxtable
Date: 2009 Sep 10, 11:15 +0100
Andres Ruiz commented, about Greg Rudzinski's index-card method For Lat = 34�10'=34.1667� LOG(COS(RAD(Lat))) = -0.0823 And table vlue is: 100000*LOG(10*COS(RAD(Lat))) = 91771.9422 = 91772 Where LOG is the logarithm to base 10 ====================== from George- There's nothing wrong here, in that a log of a number less than one, such as -0.0823, is in navigator's convention turned into a positive value by adding 10.0 to it, (equivalent to multiplying the original cosine by 10,000,000,000. ), so it becomes 9.9177. Greg omits the integer preceding the decimal point, just concerning himself with the "mantissa" part, which becomes .9177, or actually, as Greg quotes an additional digit, .91772. ================================ But difficulties can arise with the simplifications and short-cuts that Greg has adopted, in certain circumstances. For example, in [9685], Greg wrote- "The result is accurate to four places even when the the SIN product is calculated by slide rule.". Only sometimes (most times, perhaps] will that be the case. Let's assume that the multiplication can be done to one part in 1000 by slide-rule (is that fair?). The formula used is - sin h = cos lat cos dec cos (LHA) + sin lat sin dec. In the case Greg showed, that second term, product-of-sines, is much smaller than the product-of-cosines first term, so finding it to 1 part in 1000 is quite adequate for getting the overall sum to 1 part in 10,000. In many cases where the Sun is observed from low latitudes that will be true, as sin dec never exceeds 0.4. But if the first term happens to be small, such as it will if LHA gets near to 90�, (with the Sun near 6am or 6pm, for longitude) , or with a star of high declination, then the second term will dominate, and then a slide-rule calculation will be insufficiently precise. ======================== Also, Greg seems to have ignored the whole-number prefix that precedes the decimal point in his logs, a procedure which has worked for the example he chose. For each of the log-cosines, there should be a 9 before the decimal point, and when those logs are summed, they should come to 29.88205, not 2.88205 as he indicated. By discarding two 10's, as the navigators-log convention allows, we get it to 9.88205, and by looking up that number in inverse logs, the result will be 0.7622, as shown. Greg has discarded his 2. and in its place has somehow substituted a 9. before looking up that antilog., which has happened to give the right answer. But if his sum-of-cosines had happened to be somewhat less, so the result summed to 28.xxxxx rather than 29.xxxxx, then he would have had to search in quite a different part of his antilog tables, the part commencing with 8.xxxxx rather than with 9.xxxxx. So if he fails to take account of those "characteristic" numbers, before the decimal point, he will sometimes get into serious trouble. I invite Greg to try a calculation using a LHA of 85�, for which the cosine is .08716, and the log cosine is either -1.05970 or, in navigator's parlance (adding 10.0) 8.94030. Unless he takes account of that prefix being 8. rather than 9., his answers will be very wrong. Those prefix integers need to be accounted for, not just ignored, as Greg appears to have done. If I've misunderstood his procedure, perhaps he will put me right. George. contact George Huxtable, at george@hux.me.uk or at +44 1865 820222 (from UK, 01865 820222) or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK. --~--~---------~--~----~------------~-------~--~----~ NavList message boards: www.fer3.com/arc Or post by email to: NavList@fer3.com To , email NavList-@fer3.com -~----------~----~----~----~------~----~------~--~---