Integer float

From IHO Nautical Information Processing Working Group
Revision as of 10:10, 9 July 2010 by Jens (talk | contribs) (New page: Raphael by email<br> About integer vs. float - what I was thinking about is this: floating point representations in computers cannot represent all possble numbers within their nominal ran...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Raphael by email

About integer vs. float - what I was thinking about is this: floating point representations in computers cannot represent all possble numbers within their nominal range. Wikipedia has a good explanation (see the "Accuracy Problems" section).

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

Given the provisions S-100 and S-57 make for floating point representations, it may be all right. But in general, instead of trying to think whether hidden problems like this might turn up in actual practice (and what happens if someone revises the design later? what happens if someone uses someting other than ISO8211 encoding?), it is better to make watertight design decisions.

jens 10:10, 9 July 2010 (UTC) oops, that knocked me out.

I discussed that point with Martin thins morning in length. Important is to not leave the conjunction to the reality. You know, all is possible if stated in subjunctive mood.

It seems to be realistic that information on draught, tdw, beam and length is given in not more than 3 decimal places. That is one more than commonly in use today. It considers the thinkable need for more accuracy. (personally I think that is bullshit with 3 decimals, but who knows) Information about NT and GT is given in Integer.

We have to state the resolution. We can either do this by xx.xxx or we transform to Integer and say xxxxx. Both are workable for me. Integer allows one entry form for "value". That is one reason why I like the integer idea. Using Integer exclusively where to state that the machine will either calculate the 3 decimal or not?