Wintel compilers with: C99 tgmath.h? 16-byte "long double"?

[Dan Pop]

I couldn't care less about your opinion Mr Pop. Yes. That is clear.

If it were *only* my opinion, you'd have a point. Since it is the
quasi-consensus of the c.l.c regulars, and you still couldn't care less,
that makes you an asshole.

I can post in the usenet as you can. You have no authority to
tell me what should I write or what should I think.

When what I told you about posting to c.l.c coincides with what many
other c.l.c regulars have *already* told you, there may be a point
in actually listening. But, being the asshole you actually are, you
can't be expected to listen.

Expect to be treated accordingly in the future.

Dan

 

[bq]

Here is the bug. y and ey are long doubles!

This is WRONG.
You are doing all calculations in long double precision
instead of float precision!!
Changing this to:
ey = (float)y*(float)y-2*(float)x*(float)x;

It is not wrong for two reasons. First, as I explained in the original
post, the program did detect that hypot() was always working as
double hypot(double, double)
and it also did detect that the compiler applied 3 different versions
of sqrt(x) depending on the type of x.
Second, what matters is that hypot() was called with two float
arguments. Computing the error in double or in long double (or even
quadruple!) has no bearing on the issue in question.

Let me repeat here what is the issue in question. In short, the sqrt()
function was overloaded or type-generic while hypot() was not. That
was in a C program that did NOT #include <tgmath.h>. And that happened
with one particular compiler. My (perhaps unrealistic) expectation was
that
hypot() would behave similar to sqrt() [because internally hypot()
would call sqrt() and possibly fabs()]. Obviously, that was not the
case.

Thanks.
bq

 

[bq]

"bq" <[email protected]> a écrit dans le message de
news:[email protected]...

BUT, (and this is even better) you have discovered a BUG
in lcc-win32.

I do destroy precision (by making a cast) from double or long
double to float,

You have to, don't you? Assuming 4, 8 and 10 bytes for float, double
and long double, respectively, we have
FLT_EPSILON > DBL_SPSILON > LDBL_EPSILON
Loss of precision is unavoidable when you go from wider to narrower
types.

but I do not destroy precision in the conversion of long double to double.

You have to (if long double is actually wider than double, if double
== long double, the question is trivial).

bq