Welcome to the NavList Message Boards.


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

Compose Your Message

Add Images & Files
    Re: Impossible lunar example. was: Clearing lunars
    From: Frank Reed
    Date: 2010 Aug 29, 07:20 -0700

    I wrote previously:
    "George, how generous. You gonna pat the "lady" on the head, too?? :>"

    George, you replied:
    "Wihout such heavy sarcasm, this list would be a rather more pleasant

    Sorry, George. Your sexism is well-known, and in fact I thought you were rather proud of it! You should not be surprised to be called out on it once in a while. I don't approve of your sexism at all. But am I mistaken? Do you NOT consider women inferior in mathematics and navigation more generally? If you do not consider women inferior, for tasks involving mathematics and/or seamanship and/or navigation, then I apologize profusely...

    I wrote previously,
    "It's an error to call it an error, without qualification."

    And you asked:
    "Why so?"

    I'll say it again:
    FIRST: Because this problem is not a navigation solution. It's merely a demonstration of a mathematical method. A student learning from the example as given would have all that it is necessary to work other cases from real data. There are no "bad habits" that would be formed. There are no "errors" that would arise from following this example while working with real observations. I DO AGREE that it is flawed and should have been dropped (and it eventually was) because there are students, like yourself, who will find this sort of thing disturbing and confusing. It's bad pedagogy.
    SECOND: Because the triangle DOES NOT HAVE TO CLOSE IN REAL LUNARS PROBLEMS!! You went on for several sentences about triangles and how they must close, but you're wrong. REAL observations might not yield closed triangles and yet they can still yield excellent navigational data. I remember a few years back when Alex Eremenko and I first pointed this out to you. You were shocked then, but you seemed to accept it (then). Have you regressed since??

    You wrote:
    "In this example, there was a discrepancy of 13 degrees, in the apparent triangle. Yes, it's easy to envisage a discrepancy of the odd minute or two; the result of measurement error, but Frank concedes that it's way outside that range."

    Oh yes. Absolutely. This 13 degree discrepancy could not possibly arise from observation. Maskelyne eventually blamed it on a transcription error. But, as anyone with a clue should realize, this error has no bearing on the usefulness of the example EXCEPT for those students who become obsessed over it. It's bad pedagogy, definitely, for those specific students. But it is wrong to call it an error without qualification.

    You suggest that an "odd minute or two" is all that could be accepted for observational error in the altitudes. THAT IS WRONG. I have written about the issue of altitude accuracy MANY TIMES in NavList posts. Especially when the measured distance is close to 90 degrees, the altitude of the Moon is subject to great freedom in observational accuracy. The Moon's altitude can be wrong by DEGREES (not just the "odd minute or two") in those cases, and there will be no significant error in the clearing of the lunar observation.

    Of the T. Reqs. you wrote:
    "The second edition is not presently available on Google"

    Yes it is. You can download or read it here:
    I am aware that some books are available by different rules in the UK. Can you access it at this url? If not, let me know, and I will be happy to make a copy available separately.

    And you wrote:
    "but Frank has informed us of one such example; the one that Moore presumably copied. And now he tells us there were SEVERAL such cases. More details, please, Frank."

    Ok. I've got one more (and it might not be "several" more --possibly just this one more). There's an example with the following data: Moon alt = 88d 46', star alt = 5d 6', lunar distance = 89d 58' 6". As you can see, this example ALSO fails the triangle test: the sum of the zenith distances exceeds the lunar distance. But does it matter?? Try clearing this with the data as given. What do you get? Now try clearing it again with the altitude of the Moon reduced by a few degrees. What do you get?

    And George, you wrote:
    "And when he tells us that "the process of clearing the lunar is still valid", what on Earth can "valid" mean, in such an impossible situation?"

    It means that the process is still valid. I am really quite amazed that you can't see this. Let's try a different tack: suppose a student learns from the example(s) as given in the Tables Requisite with these cases where the triangles don't close. How will those students be affected? Do you contend that they would become incompetent navigators?? Do you claim that they would sail blindly onto the rocks having learned from these "erroneous" examples??

    And George, you wrote:
    "The side-track, about the relative insensitivity of the lunar distance to Moon altitude, was irrelevant to the example we were discussing."

    No, that is SO PROFOUNDLY WRONG. You have done your damnedest over the past few years to avoid all discussion of this issue. It's something that I discovered and brought to the attention of NavList years ago... It's such a shame you've gone to such lengths to ignore it.

    George, you wrote:
    "Frank points out that if the zenith angle had been calculated as an intermediate step, then that would have shown up an impossibility straightaway, and indeed it would have brought the procedure to a premature end; no bad thing, in this case. But the usual solution works by eliminating the zenith angle from the expression, in which case that safety-test has been lost."

    No, George, you are ABSOLUTELY WRONG on this. The standard triangle solutions work by eliminating COS(Z), NOT the zenith angle independently, and the difference is very deep. It is quite possible for cos(Z) to be greater than unity --which should be a mathematical impossibility in the real numbers-- and yet you will still get a valid analysis. This is a GOOD thing. It means that the process of clearing lunars is "robust" with respect to errors. Of course if there is a HUGE error in the Moon's altitude, you will not get useful navigational information, but you will still get a valid mathematical solution.

    George, you wrote:
    "Frank simply tells us to proceed, "just calculate cos(Z) and continue", even though the value of cos(Z) is significantly greater than 1. And he says "The math works out fine, and the results are accurate". Well, in the impossible example we are considering, I ask him to justify that statement, that "the results are accurate"? What can it mean?"

    I am sorry, George, but you are displaying your lack of experience in this subject. You should really try the example that I proposed to you in my previous post. You'll only get over this by working some examples.

    And you concluded:
    "Frank told us "Whatever the reasons, you'll find more lunars in old logbooks taken within 30 degrees of the equator (yes, a bit broader than the tropics) than outside those limits." I wonder what those statistics were based on?"

    As I have said AGAIN AND AGAIN AND AGAIN, I have examined over a hundred actual logbooks with lunar observations. Furthermore, there is nothing controversial in my statistical comment previously. Is this REALLY an issue for you??


    NavList message boards and member settings: www.fer3.com/NavList
    Members may optionally receive posts by email.
    To cancel email delivery, send a message to NoMail[at]fer3.com

    Browse Files

    Drop Files


    What is NavList?

    Join NavList

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

    You can also join by posting. Your first on-topic post automatically makes you a member.

    Posting Code

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

    Email Settings

    Posting Code:

    Custom Index

    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