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)
> > 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.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
