Re: Proposal for resolving casting issues

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Yes, that is the case where the new behavior would imho not be good (but you 
> say spec compliant). I loose precision even though there is room to hold it.
>> 
>> Lose what precision?  It seems silly to imagine that the product of

> Have you seen my example ? If calculated in float4 the result of
> 1.00000000000001*1000.0-1000.0 would be 0.0, no ? 

So?  If you are storing one input as float4, then you cannot rationally
say that you know the result to better than 6 digits, because you don't
know the input to better than 6 digits.  Claiming that 1000.00000000001
is a more accurate answer for the product than 1000.0 is simply wishful
thinking on your part: nothing to the right of the sixth digit actually
means a darn thing, because you don't know whether the input was really
exactly 1000, or should have been perhaps 1000.001.

> Do they really mean, that an approximate calculation with one float4 must be 
> calculated in float4 arithmetic ? If you e.g. calculate in float8 it would still 
> be an approximate result and thus imho conform.

And still the output would be illusory: if you think you'd get 16 digits
of precision that way, then you are failing to grasp the problem.

>> (Unless of course the value in the float4 happens to be exact, eg,
>> an integer of not very many digits.  But if you are relying on that
>> to be true, why aren't you using an exact format for storing it?)

> Probably because the approximate is more efficient in storage size,
> or the designer knew he only wants to store 6 significant digits ?

Seems an exceedingly uncompelling scenario.  The only values that could
be expected to be stored exactly in a float4 (without very careful
analysis) are integers of up to 6 digits; you might as well store the
column as int4 if that's what you plan to keep in it.
        regards, tom lane