[Oorexx-bugs] [ oorexx-Bugs-1111900 ] Wrong result from FORMAT bif

[SourceForge.net <no...@so...>]

Bugs item #1111900, was opened at 2005-01-28 20:18
Message generated for change (Comment added) made by miesfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1111900&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Interpreter
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Walter (walter-pachl)
>Assigned to: Mark Miesfeld (miesfeld)
Summary: Wrong result from FORMAT bif

Initial Comment:
/* Rexx ***********************************
ORexx:
>1000000000.00000000000000000000000000000<
>1000000000.00000000000000000000000000000<
Regina:
>1000000000.00000000000000000000000000000<
> 999999999.99999999990000000000000000000<
*****************************************/
Say '>1000000000.00000000000000000000000000000<'
    /*1234567890 12345678901234567890123456789*/
Say '>'"FORMAT"(999999999.9999999999,10,29,30,30)'<' 
     
/* Ages ORexx on my OS/2 adds 32 spaces at the end 
   as did classic Rexx in 1993 or so 
   I think that Regina is correct in this case */

----------------------------------------------------------------------

>Comment By: Mark Miesfeld (miesfeld)
Date: 2009-07-08 09:22

Message:
The test case under ooRexx 4.0.0 produces the same results.

It seems to me that ooRexx is correct in this case.  The docs for format()
say:

"The number is first rounded according to standard Rexx rules, as though
the operation number+0 had been carried out. The result is precisely that
of this operation if you specify only number."

So, take the number: 999999999.9999999999 and add 0 to it:

/* This is Rexx */
say '(999999999.9999999999 + 0) =' (999999999.9999999999 + 0)

and you get:

(999999999.9999999999 + 0) = 1.00000000E+9

Rick has stated that the ANSI spec also requires that the "num+0" step be
done first.

Then, in the format() used in the test case, we have 10 for the characters
before the decimal place and 29 for the characters after the decimal.  If
before is larger than needed, the left is padded with spaces.  But, 10 is
exactly what is needed so no padding should be done.  If after "is not the
same size as the decimal part of the number" it is extended with 0's to
fit.  The decimal part of the number is smaller than 29, so it should be
extended with 0's to 29 characters.  This gives exactly the result that the
test case shows:

1000000000.00000000000000000000000000000

Finally, the last two args are 30 and 30.  The doc says these control the
exponent part of the result.  In this case we only need to look at the very
last arg, the 30.   The docs say this last arg specifies "when the
exponential expression is used."

It then says: If the number of places needed for the integer or decimal
part exceeds the last arg or twice the last arg, respectively, the
exponential notation is used.  10 does not exceed 30 nor does 29 exceed
twice 30, so exponential notation is not used.

Therefore, the ooRexx output is exactly what is to be expected and this is
not a valid bug.

----------------------------------------------------------------------

Comment By: Mark Harsen (mharsen)
Date: 2005-06-01 14:43

Message:
Logged In: YES 
user_id=1289525

Object REXX defaults to 9 significant digits and FORMAT 
appears to honor this so it rounds up as you have indicated.  
However, if you add the statement "NUMERIC DIGITS 19" (as 
a minimum for your example), you get the same results as 
Regina.  I hope this helps. -Mark

----------------------------------------------------------------------

Comment By: Walter (walter-pachl)
Date: 2005-01-29 00:48

Message:
Logged In: YES 
user_id=1202891

Standard PDF p.121 Lines -7 and -3 ask for the blanks!
(If I read all that correctly)

----------------------------------------------------------------------

Comment By: Walter (walter-pachl)
Date: 2005-01-28 23:23

Message:
Logged In: YES 
user_id=1202891

actually I now remember why Rexx added blanks at the end...
It was to have the same width for the result whether or not 
eponenziol notation was to be used!!!
So I think ' 999.999      ' would be the correct result and both
ORexx AND Regina are wrong in this case!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1111900&group_id=119701