By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,953 Members | 1,610 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,953 IT Pros & Developers. It's quick & easy.

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

P: n/a
bq
Hello,
Two questions related to floating point support:

What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?

What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support. I found some
compilers that did support "long double", but theirs was an 8-byte or
10-byte or 12-byte type with accuracy the same or nearly the same as
the plain 8-byte "double".

Thanks
fq

Note: My numbers were obtained by "sizeof" and "float.h" macros
DBL_DIGITS and LDBL_DIGITS.

Here is output from OpenWatcom 1.2:
FLT_EPSILON = 1.19209e-007
DBL_EPSILON = 2.22045e-016
LDBL_EPSILON = 2.22045e-016
FLT_DIG = 6
DBL_DIG = 15
LDBL_DIG = 15
FLT_MANT_DIG = 24
DBL_MANT_DIG = 53
LDBL_MANT_DIG = 53

and from Borland 5.5.1:
FLT_EPSILON = 1.19209e-07
DBL_EPSILON = 2.22045e-16
LDBL_EPSILON = 1.0842e-19
FLT_DIG = 6
DBL_DIG = 15
LDBL_DIG = 18
FLT_MANT_DIG = 24
DBL_MANT_DIG = 53
LDBL_MANT_DIG = 64

and, for comparison, from the SUN compiler (on Solaris):
FLT_EPSILON = 1.19209e-07
DBL_EPSILON = 2.22045e-16
LDBL_EPSILON = 1.92593e-34
FLT_DIG = 6
DBL_DIG = 15
LDBL_DIG = 33
FLT_MANT_DIG = 24
DBL_MANT_DIG = 53
LDBL_MANT_DIG = 113
Nov 14 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a

"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
Hello,
Two questions related to floating point support:

What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?
lcc-win32. The headers may be not in 100% standard compliance, but the basic
hardware support is there.
What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support.
lcc-win32 supports 10 byte long double. If that is too little for
you, you can use 350 bits floating point.

I found some
compilers that did support "long double", but theirs was an 8-byte or
10-byte or 12-byte type with accuracy the same or nearly the same as
the plain 8-byte "double".


No, the accuracy is better, of course, and also the range. As you
know, 64 bit is not the same as 80 bit.

Please be consequent. The "wintel" compilers must generate
code for the intel architecture. That architecture doesn't support
natively 16 bytes doubles as the sparc does.

If the purpose of your post was just to make publicity
for this fact, granted, but please do not blame the
compilers. They can't give you in hardware what the
hardware doesn't support.

lcc-win32 supports software
floating point with very high precision. I thought that
instead of 16 byte doubles, 350 bits would make
a real difference. The performance is good for a software
implementation, but do not expect hardware speeds.

gcc supports 10 byte doubles too, and gmp (their
multiprecision package) is a high speed implementation.


Nov 14 '05 #2

P: n/a
"bq" <fo**********@yahoo.com> wrote in message
news:6c**************************@posting.google.c om...
Two questions related to floating point support:

What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?
This is a library issue. If you add our library to any of several
compilers (VC++, Comeau, mingw) you can get a wintel compiler that
supports these headers properly.
What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support. I found some
compilers that did support "long double", but theirs was an 8-byte or
10-byte or 12-byte type with accuracy the same or nearly the same as
the plain 8-byte "double".


VC++ supports only 8-byte long double (same as double). Comeau has
the same limitation, at least when sitting atop VC++. mingw supports
the native Intel 10-byte long double, though their library has poor
long double precision. Our library supports the maximum of whatever
the compiler will handle. No wintel compiler supports 16-byte long
double, to my knowledge, because the hardware doesn't support it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #3

P: n/a
bq
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cb**********@news-reader4.wanadoo.fr>...
"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
Hello,
Two questions related to floating point support:

What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?
lcc-win32. The headers may be not in 100% standard compliance, but the basic
hardware support is there.
What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support.


lcc-win32 supports 10 byte long double. If that is too little for
you, you can use 350 bits floating point.


I am not familair with that 350 bit mode.
Is that through library functions or some other special tools?
If the purpose of your post was just to make publicity
for this fact, granted, but please do not blame the
compilers.


No blame was meant. In fact the compiler+library that had 16-byte
support
(I won't repeat its name!) had a few thins I didn't like. Example: the
sqrt() function operated as if <tgmath.h> was included even when it
wasn't.
However, hypot() operated in "double" regardless of its argument type,
and there is no hypotl() to use. It took me a while to figure out why
one routine (an SVD calculation) was losing precision. Once hypot()
was replaced with my own routine, full precision was recovered.

Thanks.
bq
Nov 14 '05 #4

P: n/a
bq
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cb**********@news-reader4.wanadoo.fr>...
"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
Hello,
Two questions related to floating point support:

What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?
lcc-win32. The headers may be not in 100% standard compliance, but the basic
hardware support is there.
What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support.


lcc-win32 supports 10 byte long double. If that is too little for
you, you can use 350 bits floating point.


I am not familair with that 350 bit mode.
Is that through library functions or some other special tools?
If the purpose of your post was just to make publicity
for this fact, granted, but please do not blame the
compilers.


No blame was meant. In fact the compiler+library that had 16-byte
support
(I won't repeat its name!) had a few thins I didn't like. Example: the
sqrt() function operated as if <tgmath.h> was included even when it
wasn't.
However, hypot() operated in "double" regardless of its argument type,
and there is no hypotl() to use. It took me a while to figure out why
one routine (an SVD calculation) was losing precision. Once hypot()
was replaced with my own routine, full precision was recovered.

Thanks.
bq
Nov 14 '05 #5

P: n/a

"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message

news:<cb**********@news-reader4.wanadoo.fr>...
"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
Hello,
Two questions related to floating point support:

What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?

lcc-win32. The headers may be not in 100% standard compliance, but the basic hardware support is there.
What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support.


lcc-win32 supports 10 byte long double. If that is too little for
you, you can use 350 bits floating point.


I am not familair with that 350 bit mode.
Is that through library functions or some other special tools?
If the purpose of your post was just to make publicity
for this fact, granted, but please do not blame the
compilers.


No blame was meant. In fact the compiler+library that had 16-byte
support
(I won't repeat its name!) had a few thins I didn't like. Example: the
sqrt() function operated as if <tgmath.h> was included even when it
wasn't.
However, hypot() operated in "double" regardless of its argument type,
and there is no hypotl() to use. It took me a while to figure out why
one routine (an SVD calculation) was losing precision. Once hypot()
was replaced with my own routine, full precision was recovered.

Thanks.
bq

Nov 14 '05 #6

P: n/a
Here is an example of 350 bit mode:

#include <qfloat.h>
#include <stdio.h>
int main(void)
{
qfloat q = -1.570796Q;
qfloat result = tanq(q); // tanq is tangent for qfloat

printf("tan is: %70.40qf\n",result);
}

Produces:

tan
-3060023.3061935646797771659336362687358523

If you want to be sure which result is right (-3060023.3061 or -3060024.455
?)
this comes handy

lcc-win32:

http://www.cs.virginia.edu/~lcc-win32
Nov 14 '05 #7

P: n/a
bq wrote:
.... snip ...
However, hypot() operated in "double" regardless of its argument
type, and there is no hypotl() to use. It took me a while to


As it should. If you called it with errooneous arguments it seems
clear to me where the blame should fall.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #8

P: n/a
In <cb**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:
Here is an example of 350 bit mode:

#include <qfloat.h>
#include <stdio.h>
int main(void)
{
qfloat q = -1.570796Q;
qfloat result = tanq(q); // tanq is tangent for qfloat

printf("tan is: %70.40qf\n",result);
}

Produces:

tan
-3060023.3061935646797771659336362687358523


Wrong! On my system, it produces:

fangorn:~/tmp 225> gcc -ansi -pedantic test.c
test.c:1:20: qfloat.h: No such file or directory
test.c: In function `main':
test.c:5: error: `qfloat' undeclared (first use in this function)
test.c:5: error: (Each undeclared identifier is reported only once
test.c:5: error: for each function it appears in.)
test.c:5: error: parse error before "q"
test.c:5:21: invalid suffix "Q" on floating constant

Please don't post example code that doesn't even compile with a standard
C compiler to this newsgroup. Keep your stuff for comp.compilers.lcc!

You've been told countless times that we're not interested in your
extensions. Is it that difficult to you to understand this or are you
an asshole who couldn't care less?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #9

P: n/a

"Dan Pop" <Da*****@cern.ch> a écrit dans le message de
news:cb**********@sunnews.cern.ch...
In <cb**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:
Please don't post example code that doesn't even compile with a standard
C compiler to this newsgroup. Keep your stuff for comp.compilers.lcc!

You've been told countless times that we're not interested in your
extensions. Is it that difficult to you to understand this or are you
an asshole who couldn't care less?


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

Concerning your language, you just show who you are, that's all.

Insults are the ressort of desperate people that have no longer
any arguments.

I am answering a question about the 350 bit mode of lcc-win32.

This mode is clearly marked as an extension. It allows greater
numerical precision. If your compiler doesn't support it, do not
use this mode.

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.
Nov 14 '05 #10

P: n/a
bq
CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...
bq wrote:

... snip ...

However, hypot() operated in "double" regardless of its argument
type, and there is no hypotl() to use. It took me a while to


As it should. If you called it with errooneous arguments it seems
clear to me where the blame should fall.


Here is the code I used. The error "ey" was on the order 1e-16 in all
three cases. A similar procedure applied to sqrt() gave errors of
order 1e-8, 1e-16 and 1e-33. Where are the "errooneous arguments"?

Thanks
bq

#include <stdio.h>
#include <math.h>

int main ()
{
long double x=1, y, ey;

printf("x: %40.35Lg \n", x );

printf("y=hypot((float) x, (float) x)\n" );
y=hypot((float) x,(float) x);
ey = y*y-2*x*x;
printf("y: %40.35Lg \n", y );
printf("ey: %40.35Lg \n", ey);
printf("\n") ;

printf("y=hypot((double) x, (double) x)\n" );
y=hypot((double) x,(double) x);
ey = y*y-2*x*x;
printf("y: %40.35Lg \n", y );
printf("ey: %40.35Lg \n", ey);
printf("\n") ;

printf("y=hypot((long double) x, (long double) x)\n" );
y=hypot((long double) x,(long double) x);
ey = y*y-2*x*x;
printf("y: %40.35Lg \n", y );
printf("ey: %40.35Lg \n", ey);
printf("\n") ;
return 0;
}
Nov 14 '05 #11

P: n/a
bq
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cb**********@news-reader2.wanadoo.fr>...
Here is an example of 350 bit mode:

#include <qfloat.h>
#include <stdio.h>


I am currently developing a numeric library, and the problem is this.
The basic library-wide floating type is, say, T.
There are two requirements. 1) I'd like to be able to recompile the
library, and for it to work and yield the expected precision whether T
is float, double or long double. Several functions in the library need
to call sqrt(), hypot() and fabs(). If long double is N decimal digits
of accuracy, the library should attain that precision. I don't care
whether N is 15 or 18 or 33 or something else, although the point of
allowing long double is to achieve N>15 when desired or called for,
and where it is available.

2) I'd like the library to work with most of the widely available
compilers/libraries without any #ifdef's to adapt to specific
compilers or operating systems. [C99's "tgmath" would solve the
problem, but that is not widely available]

The library works fine with double [on all compilers tested so far].
It also works with float (if I rely on automatic conversion of float
to double) on several compilers that I tested so far. However, getting
long double to work seems to require many #ifdef's to adapt to all
sorts of compiler+library behavior.

For long double, I've considered writing a special my_sqrt() function
that calls the double version sqrt() then improves the result by one
or two Newton-Raphson iterations. That would work on all systems, but
it would be inefficient on systems with a sqrtl() or a polymorhic
sqrt().

Any suggestions or comments are welcome.

Thanks.
bq
Nov 14 '05 #12

P: n/a

"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
int main ()
{
long double x=1, y, ey;
Here is the bug. y and ey are long doubles!

printf("x: %40.35Lg \n", x );

printf("y=hypot((float) x, (float) x)\n" );
y=hypot((float) x,(float) x);
ey = y*y-2*x*x;

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;

I obtain
ey: -6.845708355740498516e-08
and NOT what you obtain. This forces calculations
into single precision...

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, but I do not destroy precision in the conversion
of long double to double.

(double) x with x long double
generates nothing. This will be fixed ASAP.

By the way, adding

qfloat qy,qey;
printf("y=hypot((qfloat) x, (qfloat) x)\n" );
qy=hypotq((qfloat) x,(qfloat) x);
qey = qy*qy-2*(qfloat)x*(qfloat)x;
printf("y: %40.35qg \n", qy );
printf("ey: %40.35qg \n", qey);
printf("\n") ;

I obtain:
y=hypot((qfloat) x, (qfloat) x)
y: 1.41421356237309504880168872420969808
ey: 0

jacob
Nov 14 '05 #13

P: n/a

"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cb**********@news-reader2.wanadoo.fr>... The library works fine with double [on all compilers tested so far].
It also works with float (if I rely on automatic conversion of float
to double) on several compilers that I tested so far. However, getting
long double to work seems to require many #ifdef's to adapt to all
sorts of compiler+library behavior.

What kind of problems are you getting?

Beware that under microsoft compilers long double is
equal to double
For long double, I've considered writing a special my_sqrt() function
that calls the double version sqrt() then improves the result by one
or two Newton-Raphson iterations. That would work on all systems, but
it would be inefficient on systems with a sqrtl() or a polymorhic
sqrt().


Difficult to say without a concrete example of compiler
misbehavior...

Nov 14 '05 #14

P: n/a
"bq" <fo**********@yahoo.com> wrote in message
news:6c**************************@posting.google.c om...
I am currently developing a numeric library, and the problem is this.
The basic library-wide floating type is, say, T.
There are two requirements. 1) I'd like to be able to recompile the
library, and for it to work and yield the expected precision whether T
is float, double or long double. Several functions in the library need
to call sqrt(), hypot() and fabs(). If long double is N decimal digits
of accuracy, the library should attain that precision. I don't care
whether N is 15 or 18 or 33 or something else, although the point of
allowing long double is to achieve N>15 when desired or called for,
and where it is available.

2) I'd like the library to work with most of the widely available
compilers/libraries without any #ifdef's to adapt to specific
compilers or operating systems. [C99's "tgmath" would solve the
problem, but that is not widely available]

The library works fine with double [on all compilers tested so far].
It also works with float (if I rely on automatic conversion of float
to double) on several compilers that I tested so far. However, getting
long double to work seems to require many #ifdef's to adapt to all
sorts of compiler+library behavior.

For long double, I've considered writing a special my_sqrt() function
that calls the double version sqrt() then improves the result by one
or two Newton-Raphson iterations. That would work on all systems, but
it would be inefficient on systems with a sqrtl() or a polymorhic
sqrt().

Any suggestions or comments are welcome.


Well, we have a library that does all that, but it ain't free.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #15

P: n/a
bq wrote:
CBFalconer <cb********@yahoo.com> wrote:
bq wrote:

... snip ...

However, hypot() operated in "double" regardless of its argument
type, and there is no hypotl() to use. It took me a while to


As it should. If you called it with errooneous arguments it seems
clear to me where the blame should fall.


Here is the code I used. The error "ey" was on the order 1e-16 in all
three cases. A similar procedure applied to sqrt() gave errors of
order 1e-8, 1e-16 and 1e-33. Where are the "errooneous arguments"?

#include <stdio.h>
#include <math.h>

int main ()
{
long double x=1, y, ey;

printf("x: %40.35Lg \n", x );

printf("y=hypot((float) x, (float) x)\n" );
y=hypot((float) x,(float) x);


hypot takes and returns doubles.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #16

P: n/a
"CBFalconer" <cb********@yahoo.com> wrote in message
news:40***************@yahoo.com...
hypot takes and returns doubles.


Not necessarily in C99, if you include <tgmath.h>. And not in
C++, if you support TR1. In both cases, hypot is a generic
function.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #17

P: n/a
"P.J. Plauger" <pj*@dinkumware.com> wrote:
"CBFalconer" <cb********@yahoo.com> wrote in message
news:40***************@yahoo.com...
hypot takes and returns doubles.


Not necessarily in C99, if you include <tgmath.h>. And not in
C++, if you support TR1.


C++ is completely immaterial, obviously. As for <tgmath.h>, you're
correct, but bq did in fact _not_ #include it.

Richard
Nov 14 '05 #18

P: n/a
"jacob navia" <ja***@jacob.remcomp.fr> wrote:
I couldn't care less about your opinion Mr Pop. Yes. That is clear.

Concerning your language, you just show who you are, that's all.

Insults are the ressort of desperate people that have no longer
any arguments.
This is true, but...
I am answering a question about the 350 bit mode of lcc-win32.

This mode is clearly marked as an extension. It allows greater
numerical precision. If your compiler doesn't support it, do not
use this mode.
....his actual point was correct, regardless of the way he phrased it.
Your extensions _are_ off-topic on comp.lang.c, and you cannot possibly
expect a useful discussion of lcc here. As far as this group is
concerned, your program invoked undefined behaviour from the very first
line.
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.


The second sentence is true, but it has no bearing on the first. While
Dan has no authority over you, newsgroup tradition _has_. Only an
anti-social person would insistently discuss off-topic matters on a
technical newsgroup.

Richard
Nov 14 '05 #19

P: n/a
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net...
"P.J. Plauger" <pj*@dinkumware.com> wrote:
"CBFalconer" <cb********@yahoo.com> wrote in message
news:40***************@yahoo.com...
hypot takes and returns doubles.
Not necessarily in C99, if you include <tgmath.h>. And not in
C++, if you support TR1.


C++ is completely immaterial, obviously.


So is TR1. You forgot that part.
As for <tgmath.h>, you're
correct, but bq did in fact _not_ #include it.


And yet he got overload behavior for sqrt. So why didn't you
say "sqrt takes and returs doubles"? If you're going to quibble,
at least do so consistently.

The larger point is that the OP has discovered a mishmash of
behaviors in the general area of overloading math functions
in C libraries. He's looking for ways to get uniformity, and
I suggested some.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #20

P: n/a
In <cb**********@news-reader1.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:

"Dan Pop" <Da*****@cern.ch> a écrit dans le message de
news:cb**********@sunnews.cern.ch...
In <cb**********@news-reader2.wanadoo.fr> "jacob navia"<ja***@jacob.remcomp.fr> writes:

Please don't post example code that doesn't even compile with a standard
C compiler to this newsgroup. Keep your stuff for comp.compilers.lcc!

You've been told countless times that we're not interested in your
extensions. Is it that difficult to you to understand this or are you
an asshole who couldn't care less?


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #21

P: n/a
bq
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cb**********@news-reader3.wanadoo.fr>...
"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om...
int main ()
{
long double x=1, y, ey;


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

printf("x: %40.35Lg \n", x );

printf("y=hypot((float) x, (float) x)\n" );
y=hypot((float) x,(float) x);
ey = y*y-2*x*x;

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
Nov 14 '05 #22

P: n/a
bq
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cb**********@news-reader3.wanadoo.fr>...
"bq" <fo**********@yahoo.com> a écrit dans le message de
news:6c**************************@posting.google.c om... 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
Nov 14 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.