string.c:string_to_num
Leopold Toetsch
bewow fails, 1.e100 isn't really 10**100.
2) I've modified string_to_num to just use atof() which works.
3) This makes 2 tests fail (pmc_22, pmc_32). *But* these seem both to be
bogus: I can't imagine that e.g. "Z1" should evaluate to int(1).
Can people please have a look at the implementation of string_to_num and
at these tests.
Thanks,
leo
new P9, .PerlNum
pow N1, 10, 100
set P9, N1
new P10, .PerlNum
set P10, 1.e100
eq P9, P10, ok
print "not "
ok:
print "ok\n"
end
Dan Sugalski
> 1) I've serious troubles with the precision of string_to_num. The test
> bewow fails, 1.e100 isn't really 10**100.
> 2) I've modified string_to_num to just use atof() which works.
I so wish this were the case. Unfortunately it's not. atof's behaviour
isn't standardized across platforms--using it means that source will
behave differently depending on where it's compiled, which is bad.
I thought we'd grabbed perl 5's string-to-num code. If not, we should. The
licenses match, and we know it works.
> 3) This makes 2 tests fail (pmc_22, pmc_32). *But* these seem both to be
> bogus: I can't imagine that e.g. "Z1" should evaluate to int(1).
I can't think of a reason Z1 should be 1 -- it ought to be zero.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Nicholas Clark
> On Mon, 12 Jul 2004, Leopold Toetsch wrote:
>
> > 1) I've serious troubles with the precision of string_to_num. The test
> > bewow fails, 1.e100 isn't really 10**100.
> > 2) I've modified string_to_num to just use atof() which works.
>
> I so wish this were the case. Unfortunately it's not. atof's behaviour
> isn't standardized across platforms--using it means that source will
> behave differently depending on where it's compiled, which is bad.
I'm pretty sure atof()'s behaviour can be standardised if one preprocesses
to get rid of the C99 braindeath first (0x... being hex floating point
constants)
> I thought we'd grabbed perl 5's string-to-num code. If not, we should. The
> licenses match, and we know it works.
In my opinion it doesn't work well enough. It can't do NaNs or Infs, and
it suffers rounding errors on some architectures and platforms
(Notably long doubles in various places, and Crays, because Crays don't
round in the IEEE way)
Nicholas Clark
Dan Sugalski
> On Mon, Jul 12, 2004 at 09:20:31AM -0400, Dan Sugalski wrote:
> > On Mon, 12 Jul 2004, Leopold Toetsch wrote:
> >
> > > 1) I've serious troubles with the precision of string_to_num. The test
> > > bewow fails, 1.e100 isn't really 10**100.
> > > 2) I've modified string_to_num to just use atof() which works.
> >
> > I so wish this were the case. Unfortunately it's not. atof's behaviour
> > isn't standardized across platforms--using it means that source will
> > behave differently depending on where it's compiled, which is bad.
>
> I'm pretty sure atof()'s behaviour can be standardised if one preprocesses
> to get rid of the C99 braindeath first (0x... being hex floating point
> constants)
I'm not so sure. Perl 5 has its own string to number conversion because of
atof incompatibilites IIRC. (Which I may not) Granted, at this point all
those problems may well be gone, what with us requiring a C89 standard
compiler and all the platforms that have died, but I'm not so sure.
(Neither am I sure it'll work right in the face of all the potential float
sizes one can configure)
> > I thought we'd grabbed perl 5's string-to-num code. If not, we should. The
> > licenses match, and we know it works.
>
> In my opinion it doesn't work well enough. It can't do NaNs or Infs, and
> it suffers rounding errors on some architectures and platforms
> (Notably long doubles in various places, and Crays, because Crays don't
> round in the IEEE way)
Ah, foo. In that case we need more work. I still think that we're better
off with a standard atof rather than relying on the C standard library,
though.
Nicholas Clark
> On Mon, 12 Jul 2004, Nicholas Clark wrote:
>
> > On Mon, Jul 12, 2004 at 09:20:31AM -0400, Dan Sugalski wrote:
> > > On Mon, 12 Jul 2004, Leopold Toetsch wrote:
> > >
> > > > 1) I've serious troubles with the precision of string_to_num. The test
> > > > bewow fails, 1.e100 isn't really 10**100.
> > > > 2) I've modified string_to_num to just use atof() which works.
> > >
> > > I so wish this were the case. Unfortunately it's not. atof's behaviour
> > > isn't standardized across platforms--using it means that source will
> > > behave differently depending on where it's compiled, which is bad.
> >
> > I'm pretty sure atof()'s behaviour can be standardised if one preprocesses
> > to get rid of the C99 braindeath first (0x... being hex floating point
> > constants)
>
> I'm not so sure. Perl 5 has its own string to number conversion because of
> atof incompatibilites IIRC. (Which I may not) Granted, at this point all
> those problems may well be gone, what with us requiring a C89 standard
> compiler and all the platforms that have died, but I'm not so sure.
> (Neither am I sure it'll work right in the face of all the potential float
> sizes one can configure)
The real big problem was the first time we realised we'd encountered a C99
libc, and perl was converting "0x3" to 3, rather that 0 as the Camel says,
because atof()'s documented C89 behaviour is broken by C99, and perl expected
the the C89 behaviour.
I don't remember any major reason to mistrust platform atof() apart from this,
and this particular stupidity can be worked round by wrapping atof() in a
vetting routine and chucking anything matching the hex constants /^0x/ back
as 0.0
And I think that the principal reason perl didn't do this was because Hugo
sent Jarkko a patch to implement atof() faster than I was able to write a
vetting routine. I still consider perl's own atof() a bad move, because it's
never going to be portable enough.
Nicholas Clark