NavList:

   

Reply

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
-~----------~----~----~----~------~----~------~--~---

   

Reply