decimal round off issue
in [Perl]
|
Prev: Newbie: Regular expresion
Next: CGI and UTF-8
From: Peter J. Holzer on 26 Sep 2009 05:17 On 2009-09-24 01:10, Ben Morrow <ben(a)morrow.me.uk> wrote: > Quoth "Peter J. Holzer" <hjp-usenet2(a)hjp.at>: >> Is there a "standard" C library on Windows which gcc has to use or does >> it use the glibc? I suspect it's the former (I've seen similar results >> with Microsofts C compiler). > > Huh? glibc is Linux- (well, and Hurd-) only. Ports to other systems existed. I wouldn't be terribly surprised if a (partial) port to Windows exists and is bundled with one of the ports of gcc for Windows. > gcc on Win32 uses MSVCRT.DLL, That's what I thought (I wrote "I suspect it's the former"), but I didn't know it. The last time I wrote C code for a MS platform was in the MS-DOS days ... hp
From: Peter J. Holzer on 26 Sep 2009 05:42 On 2009-09-24 01:58, sln(a)netherlands.com <sln(a)netherlands.com> wrote: [ unexpected results from perl printf on Windows ] > Still, you have to wonder why MS, who supposedly is ANSI CRT > would differ from other compilers in its sprintf results. The C standard is deliberately vague on many aspects of floating point arithmetic, because in the late 1980s there were still a lot of very different implementations of fp arithmetic (both in software and hardware). Mandating IEEE-754 compliant arithmetic would have been as sure way to prevent the standard from being adopted by major vendors. Even the C99 standard only contains IEEE-754 arithmetic as an option. So the MS printf implementation is almost certainly standard-conforming, it just isn't as good as it could be. (I haven't checked, but I think the error is below one ulp, so it is even correct) > I thought it could be that gcc doesn't use perhaps an optimization > that MS uses in its comiler that may pertain to floating point. It is unlikely that this has anything to do with compiler optimizations. Printf is just implemented differently (note that the MS implementation apparently has a fixed number of decimal digits and prints only zeros after that). > On the other hand, there is alot of defines being passed to the > Perl source. Are you sure that sprintf/printf from the CRT is > is not being bypassed via custom Perl implementation? No. But if Perl had its own implementation I would expect the output on Linux and Windows to be the same. Since the output is different it is very likely that Perl just uses the facilities of the local C library. (The default perl FP->string conversion is a custom implementation (since the C library doesn't offer the functionality) and it is buggy - I've ranted about that before, but that isn't an issue here) hp
From: Ilya Zakharevich on 26 Sep 2009 22:44 On 2009-09-24, Ben Morrow <ben(a)morrow.me.uk> wrote: >> AFAIK, there are many gcc's on Win32, all (?) using different CRTL... > > Really? The only port I've ever seen is the MinGW port, which uses > MSVCRT as it's libc. (I don't count Cygwin/Interix/whatever gccs as > running on Win32, and neither does perl.) I saw mentions of djgcc port. At some time OS/2 EMX port was working on Win32 with an appropriate syscalls library (RSX-NT, if I remember correct) - but later people could not reproduce it; I did not collect enough incentive to debug. I know that klibc sources have __WIN32__ defines and subdirectories scattered about... Do not know whether klibc actually compiles under Win32. I know that Perl compiles - and at least in some repects works - with klibc. Yours, Ilya
From: Ilya Zakharevich on 26 Sep 2009 22:46 On 2009-09-26, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote: > (The default perl FP->string conversion is a custom implementation > (since the C library doesn't offer the functionality) C library definitely offers the functionality. And it was used for decades without much problem.... > and it is buggy - Agreed. Ilya
From: Peter J. Holzer on 27 Sep 2009 08:24
On 2009-09-27 02:46, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote: > On 2009-09-26, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote: >> (The default perl FP->string conversion is a custom implementation >> (since the C library doesn't offer the functionality) > > C library definitely offers the functionality. Really? Which standard C function gives you the shortest decimal string representation of a floating point number which can be be converted back to an fp number with the same value? The closest I see is gcvt, which isn't a standard C function (but probably portable enough for the purposes of perl) and doesn't quite cut it either: It prints 1.0000000000000000818...e-05 as 1.0000000000000001e-05 instead of 0.00001 or 1e-05 (tested with glibc 2.7). hp |