Re: Re: floating point representation

On Wed, 21 Feb 2001, you wrote:
> At 10:19 21/02/01 +0100, Robert Schrem wrote:
> >The advantage would be, that we only generate as much ASCII data
> >as absolutly neccessary to rebuild the original data exactly.
> >At least this is what I would expect from pg_dump.
> 
> pg_dump is only one side of thre problem, but the simplest solution might
> be to add an option to dump the hex mantissa, exponent & sign. This should
> be low-cost and an exact representation of the machine version of the number.

The hex dumps should be done in a machine independant way - I think
that's what you ment when stating mantissa, exponent & sign seperatly,
right? I think this whould be a good solution...

> The other issues, like what is sent to psql & via interfaces like odbc
> (currently text) should be application/DBA based and setable on a
> per-attribute basis. 

You think of an additional tag in a CREATE TABLE instruction like

CREATE TABLE temperature (   id             id,   messure_time   timestamp default now() formatted as "hhmmmdd",
value         float formatted as "%3.2f"
 
);

or maybe

CREATE TABLE temperature (   id                       id,   messure_time("hhmmmdd")  timestamp default now(),
value("%3.2f")          float
 
);

or is there something in SQL99 ?

> eg. some applications want 1.0000 because the data
> came from a piece of hardware with a know error, and 1.0000 means 1.0000+/-
> 0.00005 etc. Maybe this is just an argument for a new 'number with error'
> type...

I think a float value in a database column has no known error 
range and therefore we should not care about the 'physical' error 
of a value in this context. Just think of a computed column in a 
VIEW - how can we know for shure how percise such a result is if
we don't have any additional information about the messurement 
errors of all operands (or constants) involved.

If you would introduce a new type - 'number with error' - this 
would be totally different and a big contribution to the solution 
of this. Then you can also handle errors like 1.0000+/-0.00002 
percisely - witch you can't by only formatting 1.0000.

robert schrem