Welcome to the NavList Message Boards.

NavList:

A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    Name or NavList Code:
    Email:
       
    Reply
    Re: Index Card for Trig/Log Table
    From: Greg Rudzinski
    Date: 2009 Sep 10, 08:58 -0700

    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'
    
    I choose to drop the characteristics on the index card then keep track
    of the decimal by approximation.
    
    
    On Sep 10, 3:15�am, "George Huxtable"  wrote:
    > 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 �geo...@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
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

    Enter the email address associated with your NavList messages. Your NavList code will be emailed to you immediately.
    Email:

    Email Settings

    NavList ID Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site