> On Mar 21, 2025, at 11:44 PM, Robert Dubner <rdub...@symas.com> wrote:
> 
> [I am going to try to maintain a grip on my professionalism.  A
> professional does not give in to the urge to say, "I told you so".]
> 
> This program, compiled with the most recent level of patching, is
> generating the result
> 
>        IDENTIFICATION DIVISION.
>        PROGRAM-ID. float-sub1.
>        DATA DIVISION.
>        WORKING-STORAGE SECTION.
>        01 S1 PIC 999V99 DISPLAY        VALUE 111.11 .
>        01 D1 PIC 999V99 DISPLAY        VALUE 666.66 .
>        PROCEDURE DIVISION.
>            DISPLAY "S1 should be 111.11"
>            DISPLAY "S1        is " S1.
>            DISPLAY "D1 should be 666.66"
>            DISPLAY "D1        is " D1.
>        END PROGRAM float-sub1.
> 
>    S1 should be 111.11
>    S1        is 111.10
>    D1 should be 666.66
>    D1        is 666.66
> 
> Those values are NumericDisplay.  They are each stored as five ASCII
> characters.  They are not floating point numbers.  They never are floating
> point numbers.  They are operated on as the smallest binary integers I can
> make them be.  I do that partly for speed, although the actual operations
> are swamped by the conversions from string to binary.  Mainly I operate on
> them as fixed-point values for the sake of accuracy.  In fixed-point, 0.1
> is 0.1
> 
> But, many months back, I allowed my concerns about having them
> *initialized* from the _Float128 "value" member of the cbl_field_t to be
> overridden.  
> 
> I worked out ways of making that work, but I have never been happy about
> it, and now those chickens have come home to roost. 
> 
> So.  Anyway.  Jim and I may end up discussing this again, and I may well
> end up refactoring the code so as to *not* use the floating-point "value"
> member for 
> initialization of fixed-point variables.  But I can't try to do that while
> you are trying to fix the front-end arithmetic.

I was wondering this too.  It looks like what's needed is for GCC at compile 
time to use decimal arithmetic when working with expressions intended as COBOL 
decimal values.  Depending on what COBOL allows that might just mean literal 
values, or it might include compile-time expressions if those can appear in 
source text.

        paul

Reply via email to