[Cfp-interest] DFP: Conversions among FP types

[Jim Thomas]

Fred, thanks for the explanation. Here's a minor modification of what you suggested:

Replace 6.3.1.5#1 with:

[1] When a value of real floating type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. 

[2] When a value of real floating type is converted to a generic floating type, if the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined. 

[3] When a value of real floating type is converted to a decimal floating type, if the value being converted cannot be represented exactly, the result is correctly rounded with exceptions raised as specified in IEC 60559

[4] Results of some implicit conversions (6.3.1.8, 6.8.6.4) may be represented in greater range and precision than that required by the new type.

We might also need a statement somewhere that conformance to Annex F means conversions from decimal floating types to generic floating types are correctly rounded. Do we already have words that imply this?

-Jim

On Dec 4, 2012, at 1:14 PM, Fred J. Tydeman wrote:

> On Tue, 4 Dec 2012 09:16:29 -0800 Jim Thomas wrote:
>> 
>> i believe what you're trying to do is separate conversions 
>> to generic from conversions to decimal. Right? What do you 
>> see that's wrong with the current spec?
> 
> Correct.
> 
> Current spec:
> 
> Suggested change to C11:
> Add after 6.3.1.5#1.
> [2] When a value of real floating type is converted to a real 
> floating type and one or both of the types are decimal types, 
> if the value being converted cannot be represented exactly, 
> the result is correctly rounded with exceptions raised as 
> specified in IEC 60559.
> 
> Consider:
> float f = 0.1DF;  
> Since one of the types is decimal, the above words require that
> it be correctly rounded.  Yet, 'float' might be  IBM S/360 hex
> FP which only supports truncate to zero rounding (if I remember
> correctly).  So, it cannot always be correctly rounded.
> 
> Or, consider
> float f = DEC_INFINITY;
> Again, the above words require correctly rounded results.  Yet,
> if 'float' is IBM S/260 hex FP (which has no infinity), the 
> correct thing is undefined behavior.
> 
> Only conversions to decimal FP must be correctly rounded.
> 
> Conversions to generic FP must allow for implementation-defined
> rounding and undefined behavior.
> 
> The behavior (correct rounding, implementation rounding, undefined) 
> depends upon the type being converted to, not the type being converted 
> from.
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 287-5904      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest