scientific notation parsing/conversion problems #9095

p5pRT · 2007-11-01T18:01:48Z

Migrated from rt.perl.org#47087 (status was 'open')

Searchable as RT47087$

p5pRT · 2007-11-01T18:01:49Z

From [email protected]

This is a bug report for perl from davidp@lanl.gov,
generated with the help of perlbug 1.35 running under perl v5.8.8.

Upon investigation I've discovered some disturbing things:

1. perl -e 'print eval($ARGV[0]),"\n"'
'(1.818343814922934E+05-1.818343815129567E+05)/1.450606250000001E+02'
returns -1.4244604399474e-07
2. Using the attached programs, gcc, pgf90, SunWSPro cc and f90, MIPS f90, gfortran and g95 all
calculate
the following from the identical expression (on Sun, Cygwin, 32-bit Linux, 64-bit Linux,
SGI):
-1.424458433625532e-07

If that's not disturbing enough, then read on ...

The most disturbing fact occurs when I remove the scientific notation from the literals:

1. perl -e 'print eval($ARGV[0]),"\n"'
'(181834.3814922934-181834.3815129567)/145.0606250000001'
returns -1.42445843362553e-07

Compilers are the bane of my life ... sigh.

The following was suggested to me:

perl -e 'printf("%.15E\n", eval($ARGV[0])),"\n"' \
'(1.818343814922934E+05-1.818343815129567E+05)/1.450606250000001E+02'
-1.424458433625532E-07
Perl print uses the default C printf precision of six places. To get more you have to
explicitly ask using printf.

It was not portable to Cygwin since my Cygwin build of Perl continued to produce the original,
incorrect value. So, here is an alternative script that avoids the precision problem on all
platforms I've tested so far (i686 Linux, Sun, SGI, i686 Cygwin on Windows XP, IBM AIX Power PC,
Darwin Power PC, i386 Darwin Mac):

perl -e '$s=$ARGV[0]; $s=~s/[eE]([+-]?\d+)/*10**$1/g; printf "%s =\n%s
=\n%.15e\n",$ARGV[0],$s,eval($s);' \
'(1.818343814922934E+05-1.818343815129567E+05)/1.450606250000001E+02'
yields:
(1.818343814922934E+05-1.818343815129567E+05)/1.450606250000001E+02 =
(1.818343814922934*10**+05-1.818343815129567*10**+05)/1.450606250000001*10**+02 =
-1.424458433625532e-03

Basically, I convert the scientific notation numbers to standard floating point numbers with regex,
and then run eval on the resulting string expression. This indicates to me that "print" is not the
culprit here, but that Perl is not correctly converting scientific notation from the expression.

Flags:
category=core
severity=medium

Site configuration information for perl v5.8.8:

Configured by rurban at Sun Jul 8 19:08:44 GMT 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=cygwin, osvers=1.5.24(0.15642), archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 reini 1.5.24(0.15642) 2007-01-31 10:57 i686 cygwin '
config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads -Uusemymalloc -Doptimize=-O3
-Dman3ext=3pm -Dusesitecustomize -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe
-Wdeclaration-after-statement',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -Wdeclaration-after-statement'
ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using dmd 0.125)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat
perllibs=-ldl -lcrypt -lgdbm_compat
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'

Locally applied patches:
CYG01 - hints.cygwin.sh ldflags -s
CYG02 - lib-ExtUtils-Embed insensitive against leading \\s
CYG03 - lib-Test-Harness-Straps $ENV{PERL5LIB} = ''
CYG04 - major.version.cygwin.sh cygperl-5_8.dll and not cygperl-5_8_x.dll
CYG05 - add Win32CORE to core
CYG07 - File-Spec-Cygwin-TMPDIR.patch
Bug#38628 - allow legacy Cwd->cwd()
Bug#40103 - File-Spec-case_tolerant.patch from 5.9.5

@INC for perl v5.8.8:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.

Environment for perl v5.8.8:
HOME=/cygdrive/d/Users/120181/cyghome
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/usr/local/bin:/usr/bin:/bin:/cygdrive/c/PROGRA1/GNU/WinCvs:/eclipse:/cygdrive/c/absoft90/bin:
/cygdrive/d/Users/120181/cyghome/SCRIPTS:/usr/X11R6/bin:.:/usr/local/bin:/usr/local/bin:/usr/bin:/bi
n:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files/Microsoft Visual
Studio/Common/Tools:/cygdrive/c/Program Files/Microsoft Visual
Studio/Common/Msdev98/BIN:/cygdrive/c/Program Files/Microsoft Visual
Studio/DF98/BIN:/cygdrive/c/Program Files/Microsoft Visual
Studio/VC98/BIN:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/
cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Program
Files/WRQ/RSecure/:/cygdrive/c/Program Files/Reflection/:/cygdrive/c/Program Files/Diskeeper
Corporation/Diskeeper/:/cygdrive/c/Program Files/IDM Computer
Solutions/UltraEdit-32:/cygdrive/c/Program Files/Common Files/Adobe/AGL:/cygdrive/c/Program
Files/QuickTime/QTSystem/:/cygdrive/c/Program Files/Common Files/Roxio Shared/!
DLLShared:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools/WinNT:/cygdrive/c/Program
Files/Microsoft Visual Studio/Common/MSDev98/Bin:/cygdrive/c/Program Files/Microsoft Visual
Studio/Common/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio/VC98/bin:/cygdrive/c/Program
Files/IDM Computer
Solutions/UltraCompare:/usr/lib/lapack:/usr/local/bin/Graphviz/bin:/usr/local/bin/default/intel-cygw
in:/cygdrive/d/Users/120181/MYDOCU1/eospac6/Source/scripts
PERL_BADLANG (unset)
SHELL=/bin/tcsh

p5pRT · 2016-07-16T23:25:51Z

From @dcollinsn

$ perl5.25.2 -e 'print eval("(1.818343814922934E+05-1.818343815129567E+05)"),"\n"'
-2.06633121706545e-05
$ perl5.25.2 -e 'print eval("(181834.3814922934-181834.3815129567)"),"\n"'
-2.06632830668241e-05

What gives?

--
Respectfully,
Dan Collins

p5pRT · 2016-07-16T23:25:51Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2016-07-16T23:40:34Z

From [email protected]

Dan Collins via RT wrote:

What gives?

$ perl -MData::Float=float_hex -le 'print float_hex($_) for 181834.3814922934, 1.818343814922934e5'
+0x1.632530d4bd4dfp+17
+0x1.632530d4bd4dep+17

Looks like another form of [perl #41202]. The former is the true closest
representable value:

$ perl -le 'printf "%.60f\n", $_ for 181834.3814922934, 1.818343814922934e5'
181834.381492293410701677203178405761718750000000000000000000000000
181834.381492293381597846746444702148437500000000000000000000000000

-zefram

p5pRT · 2016-07-17T00:02:16Z

From @khwilliamson

On 07/16/2016 05:40 PM, Zefram wrote:

Dan Collins via RT wrote:

What gives?

$ perl -MData::Float=float_hex -le 'print float_hex($_) for 181834.3814922934, 1.818343814922934e5'
+0x1.632530d4bd4dfp+17
+0x1.632530d4bd4dep+17

Looks like another form of [perl #41202]. The former is the true closest
representable value:

$ perl -le 'printf "%.60f\n", $_ for 181834.3814922934, 1.818343814922934e5'
181834.381492293410701677203178405761718750000000000000000000000000
181834.381492293381597846746444702148437500000000000000000000000000

-zefram

I've wondered if things like this would be improved if we were to take
the advice of someone whose name I don't recall of treating 10**x as
5**x * 2**x. The first term is much smaller than 10**x, and the second
term is just shifting. But my knowledge of floating point
implementations stopped at the CDC 7600.

p5pRT · 2016-07-17T01:02:06Z

From [email protected]

Karl Williamson wrote:

I've wondered if things like this would be improved if we were to take the
advice of someone whose name I don't recall of treating 10**x as 5**x * 2**x.

No, it would not. When putting multiple digits together, we still need
their weights to be 10**x apart, not 5**x.

-zefram

khwilliamson · 2019-12-19T01:28:37Z

Please see GH #7586 for a similar issue

khwilliamson · 2019-12-19T01:36:14Z

RT #41202 (GH #8730 ) was fixed in 5.30. I just ran Dan Collins examples on blead, and both now give the same result. So I'm closing this ticket:

blead -le 'print eval("(1.818343814922934E+05-1.818343815129567E+05)"),"\n"'
-2.06632830668241e-05

blead -le 'print eval("(181834.3814922934-181834.3815129567)"),"\n"'
-2.06632830668241e-05

p5pRT added Severity High distro-All type-core type-numerical labels Oct 18, 2019

khwilliamson mentioned this issue Dec 19, 2019

numeric.c assumes that NV_DIG+2 will be enough digits for all precision possible in NV #7586

Closed

khwilliamson closed this as completed Dec 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

scientific notation parsing/conversion problems #9095

scientific notation parsing/conversion problems #9095

p5pRT commented Nov 1, 2007

p5pRT commented Nov 1, 2007

p5pRT commented Jul 16, 2016

p5pRT commented Jul 16, 2016

p5pRT commented Jul 16, 2016

p5pRT commented Jul 17, 2016

p5pRT commented Jul 17, 2016

khwilliamson commented Dec 19, 2019

khwilliamson commented Dec 19, 2019

scientific notation parsing/conversion problems #9095

scientific notation parsing/conversion problems #9095

Comments

p5pRT commented Nov 1, 2007

p5pRT commented Nov 1, 2007

From [email protected]

p5pRT commented Jul 16, 2016

From @dcollinsn

p5pRT commented Jul 16, 2016

p5pRT commented Jul 16, 2016

From [email protected]

p5pRT commented Jul 17, 2016

From @khwilliamson

p5pRT commented Jul 17, 2016

From [email protected]

khwilliamson commented Dec 19, 2019

khwilliamson commented Dec 19, 2019