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: Obtaining Azimuths. was: Re: Burdwood's Tables
    From: George Huxtable
    Date: 2007 Oct 11, 13:38 +0100

    I've been pondering a bit further about how azimuth tables might be improved
    a bit. This was triggered by realising in an earlier posting, that it was
    equally valid to tabulate log (cos X sin y)  as it was to tabulate 1000 (cos
    X sin Y) in the two sets of tables being compared. Mathematically, this is
    because we are solving the equation-
    .cos Alt sin Az = cos Dec sin LHA
    and it would be equally valid instead to solve the equation-
    log ( cos Alt sin Az ) = log (cos Dec sin LHA), which is equally true. That
    is what HO171 sets out to do, in tabulating log (cos X sin Y).
    
    But it's just struck me that any other simple single-valued function of
    (cos Dec sin LHA) could be used instead, and might offer advantages in
    manipulating the tables. The difficulty with (cos X sin Y) is that it's
    changing very slowly as it approaches 1, which occurs toward the bottom left
    of Bennett's table. What if, instead, we tabulated the angle whose sine had
    the value (cos X sin Y)? Or better (if the arc sine was calculated in
    degrees) then mutiplying that angle (in the range 0 to 90) by 11.11, and
    rounding to the nearest integer, would give a result, up to maximum of 1000,
    that increased smoothly and steadily throughout the table. If arc sine is
    calculated in radians, as in most computer programs, it would involve
    multiplying by 2000/pi, or 636.6, instead.
    
    We would be solving the equation-
    11.11 arcsine( cos Alt sin Az ) = 11.11 arcsine (cos Dec sin LHA)
    where arcsine is calculated in degrees.
    
    Can anyone see any snags in doing that? I must admit to not having thought
    out the matter in any detail.
    
    All we are doing here is improving the precision of the internal
    manipulations, over part of the range. It would do nothing to resolve the
    difficulty of the extreme senstivity of the method to small changes in
    altitude or LHA, when the azimuth is anywhere near East or West, especially
    when these have to be rounded to the nearest integer. To overcome that, it's
    necessary to work instead in terms of lat, dec, and LHA, avoiding the use of
    a calculated altitude.
    
    George.
    
    contact George Huxtable at george@huxtable.u-net.com
    or at +44 1865 820222 (from UK, 01865 820222)
    or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK.
    
    
    --~--~---------~--~----~------------~-------~--~----~
    To post to this group, send email to NavList@fer3.com
    To , send email to 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