Date: Wed, 13 Aug 2003 12:51:33 -0500
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: Anomaly in printf()
In-reply-to: <Pine.OSF.4.51.0308131046310.2694@sirppi.helsinki.fi>
To: djgpp-workers AT delorie DOT com
Message-id: <3F3A7AA5.3080108@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
X-Accept-Language: en,pdf
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
References: <46 DOT 3c4de930 DOT 2c6a2e90 AT aol DOT com>
 <Pine DOT OSF DOT 4 DOT 51 DOT 0308131046310 DOT 2694 AT sirppi DOT helsinki DOT fi>
X-MailScanner-Information: Please contact the ISP for more information
X-MailScanner: Found to be clean
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Esa A E Peuha wrote:

>I agree.  This should definitely divide by ten to produce as accurate
>result as possible.  Multiplying by 0.1 will cause errors when the
>number has large absolute value.  Could someone test the following patch
>before I commit it?
>-    tmp = modfl(integer * 0.1L , &integer);
>+    tmp = modfl(integer / 10.0L , &integer);
>     *p-- = tochar((int)((tmp + .01L) * 10));
>
I haven't had the time to examine this in detail, but the addition of 
0.01L is also not exact, so the patch, though it fixes one source of 
error, may not be sufficient.  By the way, Stephen Moshier wrote some 
code for a long double printf that he claims "passes tests for 
compliance with IEEE 754 and 854 standards".  I haven't examined it, 
either, but I have a high opinion of his work in general, so the code 
may be useful, whether it is used as-is, or if the techniques are 
adapted to the purpose at hand:

   http://www.moshier.net/smldbl12.zip

-Eric Rudd
rudd AT cyberoptics DOT com