NavList:

For the convenience of those interested, attached is the NN(x) Table, a "high-resolution" version of the N(x) Table, as described in Hanno's message below.  It is used in exactly the same way as the N(x) Table.

Stan

-----Original Message-----
From: Stan K <NoReply_StanK@fer3.com>
To: slk1000 <slk1000---.com>
Sent: Tue, Jul 7, 2015 2:12 pm
Subject: [NavList] Re: Another "emergency navigation" sight reductionmethod

Hanno,

I saw the message about the NN(x) Table, but I didn't give it much thought because it would not be recognizable as David's N(x) Table.  Perhaps not a good reason, but, as you said, you did not pursue the idea because, in effect, you end up with the equivalent of Ageton.  It would not be much different than comparing Mike Pepperday's and Rodger Farley's S-Tables.  But now the idea intrigues me, so I might just take a closer look.  So what if it no longer has the same entries as the N(x) Table.

Stan

-----Original Message-----
From: Hanno Ix <NoReply_HannoIx@fer3.com>
To: slk1000 <slk1000---.com>
Sent: Mon, Jul 6, 2015 11:42 pm
Subject: [NavList] Re: Another "emergency navigation" sight reduction method

Stan,

let me repeat an observation and then an idea.

The biggest number on your table is 5840. So, there are just 5841 numbers available for the entire table which means the resolution is 1 out of 5841 incl. 0, correct?

N(x) is actually an logarithm of something. Assuming you are always using the same table the absolute value of the entries in a log table are irrelevant - only  their ratios matter. So if you where to divide your table by the maximum value - here 5840, actually 0.5440 - then the biggest number would become 1.0000 or, written w/o period, 10000. The other values would grow in the same ratio.

 If you continue using just 4 digits again (except for the entry 10000 itself) all of a sudden you get a resolution 1 out of 10000 out of the  4 digits.  Therefore, you practically doubled the available resolution and, accordingly, reduced any rounding errors by abt. 50%. This is significant particularly for the very small entries.
 

So, the idea now is doing just that: divide all entries by the biggest entry, and you will exhaust the entire number space available therefore minimizing possible rounding errors. Again, that number space when 4 digits are used is now 0 to 9999 in steps of 1.
D.. Burch could have used with advantage that scaling  for his original N(x) .

Only if you are concerned about communicating the logarithms per se and not the corresponding  natural value to somebody else there would be a problem, and you would also have to communicate the type of scaling you did. This is never a problem when you do SR with the same scaled log table.

BTW: the way such scaling is communicated is by mentioning the base of the logarithm like 2, e, or 10 which are actually being used in technology.  Here you don't even have to know that.

I hope I was able to describe this in understandable terms.

H

On Mon, Jul 6, 2015 at 4:06 PM, Stan K <NoReply_StanK@fer3.com> wrote:

FWIW, attached is an N(x) Table with 10' increments, using Hanno's format.  It is barely over a half a page as is, but could be made smaller by not having three columns of minutes and by eliminating the 60' lines completely.

Stan

Attached File: 132099.n(x)-10-90d.xls (no preview available)

Attached File: 132107.n(x)-10-90d--hires.xls (no preview available)