On 2007-11-16 19:33:38 -0500, Geert Bosch wrote:
> If a real number is rounded to the nearest number in a binary floating
> point format with 2*p+1 bits and that result rounded again to
> a p-bit float, the result is the same as if the original value was
> rounded to a p-bit float directly.
No, th
Geert Bosch wrote:
>
> On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
>
>>> Initially, float could simply use double and cast the result.
>>> For double->float the results will remain correctly rounded.
>>
>> Yes, very probably, but this needs to be proven for each supported
>> function, due t
On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
Initially, float could simply use double and cast the result.
For double->float the results will remain correctly rounded.
Yes, very probably, but this needs to be proven for each supported
function, due to the double rounding problem (this ma
Hello,
It's time for CRLibm developpers to step in this discussion.
We confirm that CRLibm is as fast as other portable libraries, or
faster, and that it keeps improving (some benchmarks below). When we are
slower, it is because we wanted cleaner code or smaller tables or we
tuned the code on
On Wed, 14 Nov 2007, Vincent Lefevre wrote:
> On 2007-11-12 21:29:44 -0500, Geert Bosch wrote:
> > On Nov 12, 2007, at 12:37, Michael Matz wrote:
> >> * only double is implemented, hence long double and float are missing at
> >> least, at least the long double would need some implementation work,
On 2007-11-12 21:29:44 -0500, Geert Bosch wrote:
> On Nov 12, 2007, at 12:37, Michael Matz wrote:
>> * only double is implemented, hence long double and float are missing at
>> least, at least the long double would need some implementation work,
>> as you can't simply enlarge the mantissa and hop
On Nov 13, 2007, at 08:17, Michael Matz wrote:
You don't have to preach to the choir, I know why I looked at several
libms in the past :-)
I just say that crlibm is not it. There are libms which would impose
much less work, are more complete, faster and more proven in the real
world.
Do you
Hi,
On Mon, 12 Nov 2007, Geert Bosch wrote:
> The big advantage of having a libm with GCC is that, instead of only
> being able to rely on the lowest common denominator for accuracy of math
> functions, you'll be able to rely on the same precision on all targets.
> This is a huge benefit, espe
On Nov 12, 2007, at 12:37, Michael Matz wrote:
At the time we discussed and evaluated a bundled libm I've looked at
several ones. I rules out crlibm relatively quickly for these
reasons:
* only double is implemented, hence long double and float are
missing at
least, at least the long do
Hi,
On Tue, 6 Nov 2007, Uros Bizjak wrote:
> Forwarded is a short discussion with Mr. de Dinechin (forwarded with
> permission), where the possibility to import crlibm as the default gcc
> math library is discussed. I would like to ask members of the GCC SC for
> the opinion on the idea of ado
Hi Uros,
It sounds like a great idea! I'm forwarding this to the Fortran list,
because I think it might raise quite some interest there also :
http://gcc.gnu.org/ml/gcc/2007-11/msg00164.html
FX
On Sun, Nov 11, 2007 at 11:05:43AM +0100, Uros Bizjak wrote:
> Richard Sandiford wrote:
> >Uros Bizjak <[EMAIL PROTECTED]> writes:
> >
> >>Forwarded is a short discussion with Mr. de Dinechin (forwarded with
> >>permission), where the possibility to import crlibm as the default gcc
> >>math lib
Richard Sandiford wrote:
Uros Bizjak <[EMAIL PROTECTED]> writes:
Forwarded is a short discussion with Mr. de Dinechin (forwarded with
permission), where the possibility to import crlibm as the default gcc
math library is discussed. I would like to ask members of the GCC SC for
the opinion o
Uros Bizjak <[EMAIL PROTECTED]> writes:
> Forwarded is a short discussion with Mr. de Dinechin (forwarded with
> permission), where the possibility to import crlibm as the default gcc
> math library is discussed. I would like to ask members of the GCC SC for
> the opinion on the idea of adopting
14 matches
Mail list logo
