From: <ams AT ludd DOT luth DOT se>
Message-Id: <200304261342.h3QDgHZc016946@speedy.ludd.luth.se>
Subject: Re: t-strtof discrepancies
In-Reply-To: <6551-Wed23Apr2003130834+0300-eliz@elta.co.il> "from Eli Zaretskii
 at Apr 23, 2003 01:08:35 pm"
To: djgpp-workers AT delorie DOT com
Date: Sat, 26 Apr 2003 15:42:17 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
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

According to Eli Zaretskii:
> > From: <ams AT ludd DOT luth DOT se>
> > Date: Sat, 22 Mar 2003 12:53:44 +0100 (CET)

-Test 12: 6.87747e-39 -> 6.87747e-39
-Test 13: 5.87748e-39 -> 5.87748e-39
-Test 14: 5.87747e-39 -> 8.81621e-39
+Test 12: 2e-39 -> 2e-39
+Test 13: 9.80909e-45 -> 9.80909e-45
+Test 14: 1.4013e-45 -> 1.4013e-45

> > 1. Tests 12, 13, 14 don't look like failures, but the numbers are
> > different! Is it broken or not? Or is it sprintf() that is broken?
> 
> Can you show us the numbers with more digits, so we could see which
> is the first one that differs?

I'm not sure you got my point. (Or I'm misunderstanding you.) It's not
the difference in the nth digit that is problem. The problem is that
with emulation a different number is displayed then with no
emulation.

E. g. Test 12 above shows 6.87747e-39 with emulation and 2e-39
without, so you don't need any more digits to see that it differs in
the first.

Nevertheles here's the same with 20 digits of precision:

--- == 386
+++ == Athlon

--- /x2/doze_scratch/STRTOF_2.TXT       Sat Apr 26 15:30:38 2003
+++ /x2/doze_scratch/strtof_winsartre2.txt      Sat Apr 26 15:28:54 2003
@@ -2,17 +2,17 @@
 Test 1: 2 -> 2
 Test 2: 20 -> 20
 Test 3: 200 -> 200
-Test 4: 1.999999936057138495e+38 -> 1.999999936057138495e+38
-Test 5: 9.999999680285692475e+37 -> 9.999999680285692475e+37
+Test 4: 1.999999936057138493e+38 -> 1.999999936057138493e+38
+Test 5: 9.999999680285692465e+37 -> 9.999999680285692465e+37
 Test 6: Inf -> Inf
 Test 7: 0.20000000298023223877 -> 0.20000000298023223877
 Test 8: 0.019999999552965164185 -> 0.019999999552965164185
 Test 9: 0.0020000000949949026108 -> 0.0020000000949949026108
-Test 10: 1.9999999821951579292e-37 -> 1.9999999821951579292e-37
-Test 11: 2.000000010221127215e-38 -> 2.000000010221127215e-38
-Test 12: 6.877471969416770789e-39 -> 6.8774698674690743008e-39
-Test 13: 5.8774766586560626691e-39 -> 5.8774801619022234841e-39
-Test 14: 5.8774724547606696946e-39 -> 8.8162055292194598122e-39
+Test 10: 1.999999982195157931e-37 -> 1.999999982195157931e-37
+Test 11: 2.0000000102211272174e-38 -> 2.0000000102211272174e-38
+Test 12: 2.000000430610666515e-39 -> 2.000000430610666515e-39
+Test 13: 9.8090892502737194961e-45 -> 9.8090892502737194961e-45
+Test 14: 1.401298464324817071e-45 -> 1.401298464324817071e-45

> The only reliable way to debug this I'm aware of is to add cprintf
> lines to the emulator and read the resulting logs.  Yes, those are
> very long, so it's tedious, sigh...

Ok. Don't hold your breath.


Right,

						MartinS