Re: long double in gcc implementations

lcw1964 wrote:

I am duly humbled and I may have spoken prematurely. I have tested out
some of Mr. Navia's built-in math functions, compared the results to
Maple, and they do seem to render very impressive results. (As a matter
of fact, I am so impressed I would love to see the source code to try
to learn where I have gone astray.)


I may need to rescind my contrition here.

I am interested in something called the error function. This following
bit of code uses the built-in versions of lcc-win32 to compute this:

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

char Pause(void);

int main(void)
{
char txt[80];
qfloat calc, x;

printf("Enter the x argument: ");
gets(txt);
x = atof(txt);

calc=erfcq(x);
printf("erfc(x): %.80qg\n",calc);
calc=erfq(x);
printf("erf(x): %.80qg\n",calc);
puts("");

Pause();

return 0;
}

char Pause()
{
char c;
printf("\nPress Enter to continue...");
while ((c = getchar()) != '\n') { }
return c;
}

To be modest in my expectations I only output 80 digits, as opposed to
the full 100 digit precision claimed by qfloat.

For nice "round" arguments (1.0, 2.0, 3.0), the resulting 80 digits
agree totally with the output of Maple (which I trust). It is to weep,
and I am duly amazed.

However, if I try something like 1.73 or 2.52, the result offers at
best long double accuracy, with things breaking down after the 17th
digit, or 18th if I am lucky.

I genuinely hope this has something to do with my typing of the input
via atof(). For some reason, Mr. Navia's erfcq and erfq seem to see
input like 1.73 or 2.52 as double precision at best and produce only
the double precision version of the desired result, whereas nice round
input seems to get typed appropriately as qfloat and the high precision
is reflected in the output.

For my limited personal purposes the much maligned lcc-win32 could be
very satisfactory to me, so I am interested in whether this observation
is a product of my own limited programming ability or whether it is a
genuine problem related to the lcc-w32's non-standard extended function
library. FWIW, my own code to calculate erfc() (an adaptation of some
stuff in NR in C) suffers the same problem--full high precision for
"round" input, double precision at best for input with a little
business going on after the decimal point.

Grateful for feedback--polite if possible ;)

Les

.

Relevant Pages