Front page | perl.perl5.porters |
Postings from July 2001
Re: [hom00@utsglobal.com: Re: Redef of MAX_UV fixes half of UTSproblems]
Thread Previous
|
Thread Next
From:
Dominic Dunlop
Date:
July 4, 2001 00:17
Subject:
Re: [hom00@utsglobal.com: Re: Redef of MAX_UV fixes half of UTSproblems]
Message ID:
p04320400b7686c24b379@[192.168.1.4]
At 11:32 -0500 2001-07-02, Jarkko Hietaniemi wrote:
>----- Forwarded message from Hal Morris <hom00@utsglobal.com> -----
>> > ===================== op/sprintf ====================
>> > not ok 8 >%E< >123456.789< >1.234568E+05< >1.234567E+05<
>>=> >1.234567E+5< # Like %e, but using upper-case "E"
>>
>> > not ok 162 >%-13g< >1234567.89< >1.23457e+06 < >1.23456e+06 <
>>=> >1.23456e+6 <
>>
>> I hope Hugo or Jarkko know more about this test, as I've not looked at it
>> [yet]
>>
>
>Well, this is the way our sprintf works, apparently, by truncation.
>I would appreciate any reference to a POSIX, ANSI, or other standards
>document that says it should NOT work that way. If they exist, I'll
>see that UTS conforms (or at least can be made to conform with a
>POSIX flag set or some such -- we don't want to break our customer's
>applications if they've been compensating for it.
>
>
>Thanks, Hal Morris, UTS Global, LLC
>
>----- End forwarded message -----
Sorry for delay in reply: I'm somewhat out of the loop being a boring
banker at the moment. Anyway, sorry Hal. but I'd say your
implementation doesn't follow the standard, which says
e,E The double argument is converted in the style [-]d.ddde+/-dd
... The value is rounded to the appropriate number of digits. ...
(ANSI X3.159-1989, section 4.9.6.1, page 134, lines 25-32. I have not
forked over $225 for the latest version of the standard -- ISO/IEC
9899:1999, but a late draft I have has the same wording as the 1989
version.)
Note that, although the standard specifies that rounding should
occur, it doesn't specify a rounding algorithm. Having worked on
standards committees, I'd say that this was intentional. When first I
cooked up the expanded sprintf.t, I included tests which assumed IEEE
754-style rounding, but it quickly became clear that this was not
portable.
While I'm here, the late draft adds a clause to the description of
the e,E format: "The exponent always contains at least two digits,
and only as many digits as are necessary to represent the exponent."
That second clause is new, and effectively says that Microsoft's (and
maybe others') C is wrong always to produce three exponent digits --
see
<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00071.html>
and enclosing thread. I wonder if the Redmond faction was alert
enough to prevent that from making it to the final document.
--
Dominic Dunlop
Get Your Private, Free Internet Access from FREE INTERNET at http://www.free-internet.lu
Thread Previous
|
Thread Next