Front page | perl.perl5.porters |
Postings from December 2004
Re: modf chainsaw?
Thread Previous
|
Thread Next
From:
Yitzchak Scott-Thoennes
Date:
December 14, 2004 03:14
Subject:
Re: modf chainsaw?
Message ID:
20041214111430.GA2756@efn.org
On Tue, Dec 14, 2004 at 05:59:00AM -0500, Ed Allen Smith <easmith@beatrice.rutgers.edu> wrote:
> In message <20041214094930.GB756@efn.org> (on 14 December 2004 01:49:30
> -0800), sthoenna@efn.org (Yitzchak Scott-Thoennes) wrote:
> >It looks to me like the only use of modfl? is now in pp_pack.c, and that
> >looks like a bizarre kind of way to do something by someone who didn't
> >know that fmod existed.
> >
> >Can someone who has some idea what the uuencode unpacking code is doing
> >comment on whether this:
> >
> > cdouble = Perl_modf(cdouble / adouble, &trouble) * adouble;
> >
> >can't be this instead:
> >
> > cdouble = Perl_fmod(cdouble, adouble);
> >
> >Then the Perl_modfl stuff in numeric.c can be ripped out, and the
> >requirement for modfl for using long doubles can be removed from
> >Configure.
>
> OTOH:
Yeah, I saw that, but couldn't make heads or tails of when an (IV) cast
would produce a different number than modf. Both should truncate zeroward.
Neither should involve any rounding at all.
But I had meant to note it and that pp_int used to be another modf
consumer (5.8.0 and earlier).
>
> PP(pp_int)
> {
> dSP; dTARGET; tryAMAGICun(int);
> {
> NV value;
> IV iv = TOPi; /* attempt to convert to IV if possible. */
> /* XXX it's arguable that compiler casting to IV might be subtly
> different from modf (for numbers inside (IV_MIN,UV_MAX)) in which
> else preferring IV has introduced a subtle behaviour change bug. OTOH
> relying on floating point to be accurate is a bug. */
Thread Previous
|
Thread Next