[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IEEE rounding and COBOL

I've been looking closely at the rounding rules in IEEE Std 754-2008, particularly in the conversion of Binary128 and Decimal128 formats into decimal character sequences, and it seems to me there's a fundamental difference between them and COBOL conventions. 
Standard COBOL only "acquired" any sort of standardized floating-point declarations, and floating-point arithmetic, in the 2002 (current) standard, and just about everything involving both is defined by the implementor.  IEEE floating-point formats and arithmetic are new to the FCD, in what we hope will be the next COBOL standard in the relatively near future. 
For fixed-point arithmetic, COBOL has always operated under what I will call the "window of significance" principle.  For example, if the intermediate result of an operation is +99990000 (= +9.9990000...e+7), and the receiving field is described as having five decimal digits with the implied decimal point on the left (PICTURE V9999 USAGE DISPLAY), the result is ZERO, regardless of any rounding specification, with no exception condition raised.  It is my belief that this result is what COBOL users have come to expect, and I am reluctant to change it for the 2002 floating-point mechanisms at all, and wish to change it as little as possible for the "new" mechanisms and formats.  
As I see it, for strict conformance to IEEE rules, the overflow exception would be raised for all rounding modes.  I'm OK with that, and with COBOL reflecting that exception condition categorized as "fatal", with syntax provided to handle it without crashing and burning at run time. 
But it seems to me that at least some of the IEEE rounding-direction attributes would produce a value of +(0.)9999.  
Similarly, when the intermediate result is like +0.0099 (= +9.9e-4) and the receiving field is a four-digit integer (PIC 9999 USAGE DISPLAY), the result historically expected from COBOL is ZERO, with no exception condition raised, and regardless of the presence of the ROUNDED phrase (or any specification of modes of rounding).   
And in this case, I think the underflow exception would be raised, leading to an equivalent COBOL exception condition, and the IEEE rounding-direction attributes would result in a return value of 0001 in some cases. 
I do expect COBOL to raise a (fatal) exception condition (which the user can handle programmatically) in both these cases.  But I need to know what the "pitfalls" are in our current proposal to leave the results "defined by the implementor".
Have I understood these rules correctly?  Which rounding attributes produce which sets of results? 
    -Chuck Stevens
    -Chuck Stevens 

754 | revision | FAQ | references | list archive