[Proj] Numerical Precision in Proj, WKT, and everywhere

[Gerald I. Evenden]

On Thursday 01 April 2010 8:42:25 pm Craig Bruce wrote:
> "Gerald I. Evenden" <geraldi.evenden at gmail.com> wrote:
> > Au contraire. When you have a number with few significant figures that
> > have trailing zeroes such as "0.999600....000" any format that has
> > sufficient width to contain the significant figures will preserve the
> > significance. There is no rounding nor trucation problem.
>
> Obviously, but I'm not talking about specific values that happen to
> be round.

But this was the example you used in your first example.

> > The only hassle occurs when the the fractions are irrational such as pi,
> > then there is a problem.
>
> There's also a problem with rational fractions, like 1/60, as I showed
> in the WMS example.  You can easily write x = 1/60.0 in a program get a

I'm discussing decimal fractions--- xx.02935729350

> fully precise value for whatever representation you are using, but you
> can't put this expression on the proj command line (AFAIK).

No need to.

> > But in these situations (and probably others) the continual bouncing
> > back and forth between decimal and binary should be avoided. I strongly
> > suspect that there is no good reason for it anyway.
>
> I agree that it's best to avoid unnecessary conversions, but there are
> many interfaces that require text, such as the proj command-line or OGC
> web interfaces.  The same issue occurs with the database/application
> interface with BCD.  We are forced to obey the interfaces of the various
> systems we wish to chain together.

BCD? Binary Coded Decimal? Just that I have not heard the term in maybe 25 
years. Seriously. I am not being sarcastic.

In most cases there is an acceptible precision for representing a number. For 
example pi may only be needed as 3.1415927. It is assumed that zeroes are 
appended indefinitely. As long the the intermediate formating retains a 7 
digit significance, the number will be preserved regardless of binary/decimal 
conversions.

As I recall, the only place you demonstrated precision problems was an example 
that went to full mantissa precision where I admit there may be problems. 
*But* I know of no place in cartography where such precision is required.

Lastly, if one is involved with "round tripping" geographic/Cartesian 
coordinates there will be a problem but this problem more likely to be a 
hassle with the inverse projection nor exactly producing original value in 
addition. Formatting may also create a problem and this is why all my program 
proj versions had a binary pipe so that a round trip could be made without 
going through the formatter. But this round tripping should be avoided at all 
costs.

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist