NavList:

   

Reply

A few comments about Greg's posting [9697].

He wrote- "I choose to drop the characteristics on the index card then keep 
track of the decimal by approximation."

Fair enough. That's a perfectly valid way to do the job, though it adds 
quite a lot of complication; which he didn't mention when introducing us to 
his procedure. That explains why he had to look up, and note down, the 
cosines of the three angles, as well as the log-cosines, which would 
otherwise have been sufficient. Then he can multiply them together, to get a 
rough idea of the product. Simply estimating the product in-his-head should 
suffice. That then allows him to put the decimal point in the right place 
when the antilog gives the precise product-of-cosines.

But isn't that a bit long-winded and unnecessary, when it can be bypassed, 
simply by working the log calculations to include the integer before the 
decimal place?

That calls for writing down fully the log-cosines of the three angles, as 
9.91772, 9.99804, and 8.94030, as he has done below, summing them to give 
28.85606, as he has done below. Then discarding two tens from the result, to 
arrive at 8.85606 (not 2.85060, as he has shown). Then the next step is to 
use inverse logs, of 8.85606, to arrive at 0.07179, automatically. It's just 
what such logs were invented for.


For LHA 85� :
                                   appx(.07)  appx(.05)
             Log Cos      Log       Cos       Sin (by slide rule)
Lat 34� 10'  9.91772      91772     .8274     .5616
Dec  5� 26'  9.99804      99804     .9955     .0947
MA  85� 00'  8.94030      94052     .0872     +.0532
            28.85606    2.85628  ............. .0718
 Inv Log      .07179     .07183                .1250  Inv Sin
                                             Hc 7� 11'
===============================

Then the next step is to add to that the product of sines of lat and dec. In 
this case, it can be seen that the two terms in this sum are of similar 
magnitude, so a 1 in 1000 error (if that's accepted as reasonable, from a 
slide rule) ends up as 1 in 2500 error in the sum, which would create an 
overall error of well over a minute in the result, from that cause alone. 
It's why slide rules are not really acceptable for such calculations. 
Instead of multiplying those sines by a side rule, log sines could be 
extracted instead, added, then the result found by an inverse log (antilog) 
table. Then that has to be summed with the product-of-cosines, found 
previously, and then the inverse sine obtained as before.

Those log sin calculations could be completed in the time saved by not 
having to work, and multiply, those cosines. And the result would not have 
lost any of its precision. What I'm trying to point out is that in this case 
the old ways were the best, and Greg hasn't saved time, but has lost 
precision, by doing it differently.

Of course, better ways of working that calculation, by logs, were developed 
to avoid that awkward addition.

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