On Fri, 21 Mar 2025, Simon Sobisch wrote: > > Now a question on COBOL: > > > > 77 var8 PIC 999V9(8) COMP-5 > > > > what precision/digits does this specify? When then doing > > > > add 0.00000001 TO var555 giving var8 rounded > > > > what's the precision/digit specification for the literal floating > > point values and how does that or that of var555 or var8 > > "promote" or "demote" to a common specification for the arithmetic > > operation? > > > > Does the COBOL standard expect a literal floating point value to > > be represented exactly? Maybe rounding then only applies at the > > "giving var8 rounded" point, forcing the exact value to the > > specification of var8? > > > > Richard. > > That's NOT a floating-point in COBOL, but a fixed-point numeric literal. > It is best understood with the following explanation from the standard: > > > An integer literal is a fixed-point numeric literal that contains no > decimal point. > > --> it is to be used as integer with an implied decimal point after the > first position, as if it would be defined with a PIC 9v99999999 > > > floating-point literals in COBOL would have the following most important > difference: > > > A floating-point numeric literal is formed from two fixed-point > numeric literals separated by the letter 'E' without intervening spaces. > > > The requested *minimal* precision - "stored exactly" is: > * 31 digits for fixed-point numeric literals (and effectively all > calculations with those, before rounding/truncation applies) > * up to 36 digits of significand with up to 4 digits in exponent for > floating-point literals
OK, and "digits" are for a base-10 representation? > Back to your arithmetic question: COBOL standard expects that to be exact for > an intermediate value up to these sizes. > If the sizes get bigger and cannot be stored (the maximum is > implementor-defined = "should be documented in the user-documentation") then > there's the option to specify which INTERMEDIATE ROUNDING should apply (= per > program), which includes ROUNDING/TRUNCATION/PROHIBITED (=an exception > raised). > > The default for INTERMEDIATE ROUNDING dependens on which arithmetic is in > effect (also per program defined, NATIVE is default where rounding is > implementor-defined, STANDARD-BINARY and STANDARD-DECIMAL can be chosen). Where STANDARD-BINARY and STANDARD-DECIMAL roughly correspond to binary vs decimal floating-point? > > If the NATIVE phrase is specified [or implied], the techniques used > in handling arithmetic expressions and intrinsic functions shall be those > specified by the implementor, [as well as] the techniques used in handling > arithmetic statements [mostly for rounding/truncation]. And NATIVE for whatever a CPU implements when using its native floating-point facilities? > --> note that STANDARD-DECIMAL arithmetic is no optional feature, so for > full compliance that has to be considered - but can also be "ignored in > detail" for now; note that the OPTIONS paragraph (support for the paragraph is > required since COBOL2002) is only supported by GnuCOBOL (neither IBM nor Micro > Focus nor Fujitsu support it and all go with "native arithmetic" only). > > also mind that COBOL2014 has a note: > > Implementors are strongly encouraged to provide support for the > STANDARD-DECIMAL phrase of the ARITHMETIC clause > > > ... sorry for another "background-drift", getting to your question again: > > * intermediate values need to cover at least the sizes outlined above > * for bigger sizes truncation/rounding may apply - the rules that IBM, > MF and GnuCOBOL applies are different (with GnuCOBOL being nearly > infinite using GMP with an internal scale as intermediate > representation) > * the truncation/rounding that applies for a statement can be specified > at the statement (as in your example where "rounded" only applies to > this final "store to the receiving item") with the default being able > to be configured in the OPTIONS paragraph "DEFAULT ROUNDED MODE" OK, so I guess I have to look into gcobol.1 to see what's documented there for the implementation-defined bits. It seems to me that with all this "digit" stuff using decimal floating point internally would be more natural here? From saying that GnuCOBOL uses GMP I suppose you're representing fixed-point arithmetic with integers? As maybe obvious from the thread I'm trying to deal with the choice of using _Float128 as internal representation for COBOL "numbers". > Hope this helps with some background and answers your questions, Yes - thanks a lot. Richard. > Simon > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
