Re: Proposal for resolving casting issues

"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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