This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Update x86_64 ULPs
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Jaeger <aj at suse dot com>, Markus Trippelsdorf <markus at trippelsdorf dot de>, libc-alpha at sourceware dot org
- Date: Thu, 2 May 2013 22:29:54 +0200
- Subject: Re: [PATCH] Update x86_64 ULPs
- References: <20130426055835 dot GA644 at x4> <517A2CF9 dot 20504 at suse dot com> <20130502160937 dot GA8564 at domone dot kolej dot mff dot cuni dot cz> <Pine dot LNX dot 4 dot 64 dot 1305021847100 dot 12072 at digraph dot polyomino dot org dot uk> <5182B698 dot 20501 at redhat dot com>
On Thu, May 02, 2013 at 02:55:20PM -0400, Carlos O'Donell wrote:
> On 05/02/2013 02:49 PM, Joseph S. Myers wrote:
> > On Thu, 2 May 2013, Ondrej Bilka wrote:
> >
> >> Could we compute ulp directly with mpfr or I am missing some roadblock?
> >
> > The whole point of ulps baselines is to record the errors produced by the
> > actual glibc implementation, compared to an exact expected result (which
> > quite likely was computed with MPFR). Those baselines can, on x86 and
> > x86_64, depend on the processor implementation of the x87 instructions for
> > transcendental operations (so on whether an Intel or AMD processor is in
> > use, for example), as well as, on 32-bit x86, on the details of where the
> > compiler uses excess precision.
> >
So mpfr computations depend on processor used?
> > I've been thinking lately about how to better automate computation of the
> > *expected results* with MPFR and MPC, but that won't remove the need for
> > ulps values for the glibc implementations used on different platforms.
>
> +1
>
> Automating expected result computation would be great.
>
> Cheers,
> Carlos.
--
SCSI's too wide.