decimal round off issue
in [Perl]
|
Prev: Newbie: Regular expresion
Next: CGI and UTF-8
From: Ben Morrow on 23 Sep 2009 21:10 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. gcc on Win32 uses MSVCRT.DLL, which used to be part of MSVC6 and nowadays is part of Windows, or Internet Explorer, or something. Later versions of MSVC insist on using their own versions of the C library, which cause Interesting problems if you have a DLL compiled against one loaded into an EXE compiled against another. (This is one reason why it's particularly important to compile modules with the correct compiler on Win32.) Ben
From: Ilya Zakharevich on 23 Sep 2009 21:32 On 2009-09-24, Ben Morrow <ben(a)morrow.me.uk> wrote: > Huh? glibc is Linux- (well, and Hurd-) only. Last time I compiled glibc was several years ago. But it was nowhere close to Linux and/or Hurd. It is just a C library on top of POSIX - at lest at was at the time... > gcc on Win32 uses MSVCRT.DLL, AFAIK, there are many gcc's on Win32, all (?) using different CRTL... Yours, Ilya
From: sln on 23 Sep 2009 21:58 On Wed, 23 Sep 2009 22:51:36 +0200, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >On 2009-09-23 19:21, sln(a)netherlands.com <sln(a)netherlands.com> wrote: >> On Wed, 23 Sep 2009 19:21:08 +0200, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >>>On 2009-09-22 17:34, J�rgen Exner <jurgenex(a)hotmail.com> wrote: >>>> Shiping Zhang <spz1st(a)gmail.com> wrote: <snip> >> I never heard of that "round to even" rule. > >It is mentioned in this group just about every time that rounding is >discussed, which is probably at least once or twice per year. > >The rule was used at least since the early 20th century (Wikipedia cites >a book from 1906). In IEEE-754 arithmetic (which is used in all current >FP units) it is the default rounding mode. > Yeah I just read that on wikipedia. I imagine that a fpu has at least 2, 80 bit registers to do comarisons, +-/* operations, and result (don't know about this at all). When the fraction is to be chopped to 64 bit variable, the lsb is set to 0, if the lsb-1 bit in the register is set, not sure. It says 'midway'. I don't thinks this is a fp rounding issue, since by the standard, this would be consistent across fp hardware. >> On my build it rounds "up" >> all the time. Maybe I don't have the latest build. >> I'm sure this is a result of a define flag passed via compiler option. > >More likely it's caused by the implementation of sprintf in the C >library. > I think you are right on it being a lib implementation issue. >> I' got the active state 5.10 built using gcc. I looked over the build >> parameters using perl -V. > >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). > > hp There is a standard set of dll's that comes with Windows os', 2004 seems to be the last year that CRT was modified (added to). Some older programs used to just include some runtime libs (dll's) in thier exe path. Microsoft defines 'core' dll's (crt, win32 interface, etc..) in thier os, that get put in the system32 dir, part of the system path. Most programs that link to them use import .lib 's. That was seen all over gcc. Most can just get the platform sdk and grab the lib's. Header files are a whole different nightmare. So, yes. Gcc links with msvcrt.lib (import) which loads the system dll when it runs. Single threaded static libc is no longer available since VC2002/3/5/... But gcc uses /MD multithread-dynamic CRT library option. So thats where it is. In all of MS compilers, there is the option to compile as either C or C++. It looks like Gcc compiles it as C. I have VC-2005. Still, you have to wonder why MS, who supposedly is ANSI CRT would differ from other compilers in its sprintf results. 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. 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? Either way, it might be nice to compile it under vc-2005, using the float option /FP:precision -sln ---<cut>------- c:\temp>perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=MSWin32, osvers=5.00, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE - DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IM PLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='12.0.8804', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksi ze=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C: \Perl\lib\CORE" -machine:x86' libpth=\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32 ..lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_ 32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comd lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf - libpath:"C:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1004 [287188] 33741 avoids segfaults invoking S_raise_signal() (on Linux) 33763 Win32 process ids can have more than 16 bits 32809 Load 'loadable object' with non-default file extension 32728 64-bit fix for Time::Local Built under MSWin32 Compiled at Sep 3 2008 13:16:37 @INC: C:/Perl/site/lib C:/Perl/lib . c:\temp>
From: sln on 23 Sep 2009 22:11 On Wed, 23 Sep 2009 18:58:39 -0700, sln(a)netherlands.com wrote: >---<cut>------- c:\temp>perl -v This is perl, v5.10.0 built for MSWin32-x86-multi-thread (with 5 registered patches, see perl -V for more detail) Copyright 1987-2007, Larry Wall Binary build 1004 [287188] provided by ActiveState http://www.ActiveState.com Built Sep 3 2008 13:16:37 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. c:\temp> >c:\temp>perl -V > >Summary of my perl5 (revision 5 version 10 subversion 0) configuration: > Platform: > osname=MSWin32, osvers=5.00, archname=MSWin32-x86-multi-thread > uname='' > config_args='undef' > hint=recommended, useposix=true, d_sigaction=undef > useithreads=define, usemultiplicity=define > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=undef, use64bitall=undef, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE - >DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IM >PLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', > optimize='-MD -Zi -DNDEBUG -O1', > cppflags='-DWIN32' > ccversion='12.0.8804', gccversion='', gccosandvers='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 > ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksi >ze=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C: >\Perl\lib\CORE" -machine:x86' > libpth=\lib > libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32 >.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_ >32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib > perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comd >lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib >ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib > libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib > gnulibc_version='' > Dynamic Linking: > dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' > cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf - >libpath:"C:\Perl\lib\CORE" -machine:x86' > > >Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV > PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS > PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS > USE_LARGE_FILES USE_PERLIO USE_SITECUSTOMIZE > Locally applied patches: > ActivePerl Build 1004 [287188] > 33741 avoids segfaults invoking S_raise_signal() (on Linux) > 33763 Win32 process ids can have more than 16 bits > 32809 Load 'loadable object' with non-default file extension > 32728 64-bit fix for Time::Local > Built under MSWin32 > Compiled at Sep 3 2008 13:16:37 > @INC: > C:/Perl/site/lib > C:/Perl/lib > . > >c:\temp> > >
From: Ben Morrow on 24 Sep 2009 04:08
Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>: > On 2009-09-24, Ben Morrow <ben(a)morrow.me.uk> wrote: > > Huh? glibc is Linux- (well, and Hurd-) only. > > Last time I compiled glibc was several years ago. But it was nowhere > close to Linux and/or Hurd. It is just a C library on top of POSIX - > at lest at was at the time... http://www.gnu.org/software/libc/ports.html Version 2 currently supports only GNU systems (both Hurd-based and Linux-based). > > gcc on Win32 uses MSVCRT.DLL, > > 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.) Ben |