long double in gcc implementations

[lcw1964]

This may be in the category of bush-league rudimentary, but I am quite
perplexed on this and diligent Googling has not provided me with a
clear straight answer--perhaps I don't know how to ask the quesion.

I have begun to familiarize myself here with the gcc compiler in a
win32 environment, in the form of MinGW using both Dev C++ and MSYS as
interfaces.

I have recompiled some old math code that uses long double types
throughout and provides the corresponding range and precision (up to 18
digits, with exponents up to about -/+ 4900) when compiled under an
older version of BC++.

In the MinGW incarnation of gcc, I have made a couple of adjustments to
get it to compile--in particular, _atold() doesn't exist, and atof() is
prototyped only in stdlib.h whereas in BC++ it is listed in math.h too.
However, I kept all of my long double declarations and outputs as that,
and used all of the long double versions of the math functions--expl(),
fabsl(), etc. The file complied but the output was gibberish. It took a
little googling to find that I had to recast the long double output as
double so printf() could meaningfully display it.

However, I have come to suspect that MinGW's long double isn't really
long double, and that somewhere in the process the range and precision
of of the floating point math has been restricted to the double range.
For example, in the original code under BC++ (not MSVC++, which is well
known to recast everything as double) I can generate a meaningful
answer of, say 1.34598900000098888e-2345, whereas the MinGW compiled
version will render this tiny value as simply 0.

My question is this--does MinGW offer the "true" long double floating
point 80bit type, and if so how can I get my programs to display
results of the sort I mentioned in the previous paragraph is printf()
needs recasting to double in order to handle it?

I know that the C language in general is not the best environment in
which to do extended precision math work (one would be better off
mastering a high or arbitrary precision library), but I would like to
get the most precision and range out of my calculations under MinGW if
this is available.

many thanks,

Les

[lcw1964]

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

[Richard Heathfield]

lcw1964 said:

<snip>

I may need to rescind my contrition here.

Maybe we should establish the facts before we start either attacking or
defending lcc-win32. :-)

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);

This is a buffer overflow waiting to happen. Use fgets(txt, sizeof txt,
stdin) instead. We can't tell, of course, whether a buffer overflow has
caused your problem, although it is probably unlikely in this case, since
you have a nice big buffer, nice short inputs, and a (presumably) careful
and non-malicious user.

<snip>

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.

Perhaps if you could express your requirements in more detail, we could
establish whether there is a problem with qfloat.

<snip>

For my limited personal purposes the much maligned lcc-win32

Nobody has maligned the compiler. What concerns quite a few of us in
comp.lang.c is the way in which Mr Navia abuses the newsgroup for
commercial ends, pointing out this or that feature of his product without
bothering to mention that said features are non-portable. There's nothing
wrong with non-portable features, but in a newsgroup devoted to
portability, if he must mention them at all he ought to mention that their
use will render the user's code non-portable. If he wants to trumpet about
his features, he can do so in comp.compilers.lcc, surely? I mean, this guy
has his very own newsgroup, for heaven's sake!

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.

Have you considered comparing against gcc?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Gordon Burditt]

>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.

There is no exact representation of most decimal numbers in binary
floating point with only a finite number of bits, and atof() is
going to give you only the precison of a double. You need a atoqf(),
if there is such a thing. Or perhaps fgets() and sscanf() with
%qf. It's non-standard, but so will be everything involved with a
non-standard high-precision floating point type. If the input is
only good to 15 digits (IEEE double, a not uncommon implementation),
the output is not likely to be much better. If you expect 80-digit
precision, you have to not chop it to 15 digits at any point in the
calculation.

1.73 as long double:
Before: 1.729999999999999999908927017511217627543373964726 92489624023437500000000000000000
Value: 1.730000000000000000017347234759768070944119244813 91906738281250000000000000000000
After: 1.730000000000000000125767452008318514344864524900 91323852539062500000000000000000

1.73 as double:
Before: 1.729999999999999760191826680966187268495559692382 812500000000
Value: 1.729999999999999982236431605997495353221893310546 875000000000
After: 1.730000000000000204281036531028803437948226928710 937500000000

1.73 as float:
Before: 1.729999899864196777343750000000000000000000000000 000000000000
Value: 1.730000019073486328125000000000000000000000000000 000000000000
After: 1.730000138282775878906250000000000000000000000000 000000000000

>I genuinely hope this has something to do with my typing of the input
via atof().

Well, I can't prove it, but it's extremely likely. Most decimal
numbers are infinite repeating binary numbers. Chop them and you'll
lose precision in the output.

>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.

Gordon L. Burditt

[Richard Heathfield]

[Attributions restored, after Mr Burditt was careless enough to forget them
or remove them]

Gordon Burditt said:

>lcw1964 wrote:

<snip>

>>
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.

There is no exact representation of most decimal numbers in binary
floating point with only a finite number of bits, and atof() is
going to give you only the precison of a double.

Good spot. I should have seen that myself. The atof function does indeed
return a double, so any precision the OP may have typed in beyond double's
capacity is lost at this point.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

lcw1964 a écrit :

gets(txt);
x = atof(txt);

Here you should use atoq. For some stupid reason
I was missing this function. It is fixed now, and will
be in the next release.

atof returns a double and will spoil precision.

Another "gotcha" is that all number in qfloat precision
should be suffixed with q like

qfloat s = 1.23q;

if not they will be read as double precision only.

Please email me if you see any problems since
it is better not to discuss this compiler specific
stuff in this group. You can email

comp.compilers.lcc too, if you want.

jacob

[jacob navia]

lcw1964 a écrit :

>
#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);

/////changing here atof to atoq!!!!
x = atoq(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;
}

This produces:
erfc(x):
0.014421500171819502568811928600244606213396306816 2465467077964669091485918397397063
erf(x):
0.985578499828180497431188071399755393786603693183 75345329220353309085140816026029

Stephen Wolfram's Mathematica yields:
0.014421500171819502568811928600244606213396306816 2465467077964669091485918397397063
1507594187479276740

[lcw1964]

Thanks, Messr. Navia:

I need to apologize to the group for naively breaching etiquette by
straying outside the expected parameters of discussion. I should take
up further discussion of the issue with you or in the .lcc group.

Les

[Herbert Rosenau]

On Sat, 29 Jul 2006 17:26:44 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:

lcw1964 a écrit :

Whoa whoa whoa!

I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Did I just wade into a political rats' nest here?

Les

Yes. There is a political rat's nest here.

Some people in this group, think that lcc-win32 is a bad compiler
since it has good features in it.

Stop spamming for your incompatible to the whole world thing that as
you have declared by yourself is neither a C++ nor a C compiler but
something to confuse peoples.

Stop spamming because there is nothing that can make your properitary
product more useable than each and any other compiler that can claim
in some way to be a C compiler.

Stop spamming immediately as this group is not designed to promote
software. Stop spamming now because wincrap is not the only system
that needs a C compiler any your crap is useable only on some kinds of
one single properitary os - and even not only there.

lcc-win32 is a really bad compiler because it needs to get spammed
from its developer.

Spammy piss off!

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Herbert Rosenau]

On Sat, 29 Jul 2006 18:17:43 UTC, Skarmander <in*****@dontmailme.com>
wrote:

Richard Heathfield wrote:
[lots of repetitions of the phrase "unutterably stupid man" addressed to
Jacob Navia]

Please try making your points without calling people names. It's childish
and distracting. I don't frequent comp.lang.c for the arguments, but when
there *are* arguments I'd at least expect the participants to remain civil.

Oh, a person who is misusing this group to spam for his properitary
product where he has already proven multiple times that his
understunding of the topic of this group is to say it courteous highly
incomplete is needed from time to time.

It seems you are relative new to this group, so you does not know the
history of mr. Navia you should ask mr. google for him and what it has
to say about the person you says nobody should call his name.

Calling mr. Navia "unutterably stupid" as many times as possible is for your
own benefit, as nobody expects such epithets to convince anyone of anything,
except perhaps the immaturity of the speaker. That he was being disingenuous
by deliberately misrepresenting your (and other people's) views doesn't
change that.

No, it is only pure fact as proven by himself.

In short, if you want to insult someone on a personal level, please use
e-mail. I'm pretty sure your post would have conveyed its non-personal
points equally well without the insults.

No, there is really no insult but there are enough comments about the
person you says nobody should call his name. Mr. google will help you
to get informed.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Herbert Rosenau]

On Sat, 29 Jul 2006 18:44:21 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:

True, I speak about my compiler system in this group,

s/speak/spam/

and I think that I

have the right to do so. Specifically, when a user has precision
problems, I think I can point out that after years of effort I have a
compiler system that offers 100 digits in the standard version.

This group is about standard C - it is NOT about incompatible
extensions. So jacob navia is spamming for a product that is NOT
related to this group.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Herbert Rosenau]

On Sat, 29 Jul 2006 19:44:52 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:

"Genius programmers like you should not use lcc-win32." - Jacob Navia.

Where do I insult someone with that remark?
I advise you not to use a compiler system that
you tell again and again that is bad.

Be sure that I will never and in no circumstance will ever try to use
a product from the person whes names is given in the first line of
this artikle. Be sure that I will ever and in any circumstasnce
recommend not to use your compiler.

An advise that with good manners discussions are less emotional
and more to the point. Flame fests are so boring.

You do not like lcc-win32?

You are not the only one. Please keep cool and expose your views.

Explain why providing features like 100 digits precision is
bad for the user.

Only 3 single points in a sequence without scoring:
1. it is not standard conform
2. windows XP is not the only OS.
3. it is in a compier the developer is constantly spamming for
and more I left open for now.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Skarmander]

Herbert Rosenau wrote:

On Sat, 29 Jul 2006 18:17:43 UTC, Skarmander <in*****@dontmailme.com>
wrote:

>Richard Heathfield wrote:
[lots of repetitions of the phrase "unutterably stupid man" addressed to
Jacob Navia]

Please try making your points without calling people names. It's childish
and distracting. I don't frequent comp.lang.c for the arguments, but when
there *are* arguments I'd at least expect the participants to remain civil.

Oh, a person who is misusing this group to spam for his properitary
product where he has already proven multiple times that his
understunding of the topic of this group is to say it courteous highly
incomplete is needed from time to time.

It's not entirely clear what you mean, but if you're implying that he needs
a good tongue-lashing every now and then to uphold the community mores, I
disagree.

It seems you are relative new to this group, so you does not know the
history of mr. Navia you should ask mr. google for him and what it has
to say about the person you says nobody should call his name.

I'm not defending mr. Navia in the least, and frankly I couldn't care if he
ate babies.

Well, as long as he kept any mention of devouring infants out of this group.

>Calling mr. Navia "unutterably stupid" as many times as possible is for your
own benefit, as nobody expects such epithets to convince anyone of anything,
except perhaps the immaturity of the speaker. That he was being disingenuous
by deliberately misrepresenting your (and other people's) views doesn't
change that.

No, it is only pure fact as proven by himself.

Far be it from me to argue with fact. Or truthiness, for that matter.

What I see as a fact is that nobody has ever been called stupid (repeatedly)
to respond that they now see the error of their ways, or for others to
mention that they have gained a new understanding of the situation.

Of course, making progress wasn't really the point of the discourse, and I
shouldn't have pretended otherwise.

>In short, if you want to insult someone on a personal level, please use
e-mail. I'm pretty sure your post would have conveyed its non-personal
points equally well without the insults.

No, there is really no insult but there are enough comments about the
person you says nobody should call his name. Mr. google will help you
to get informed.

You seem to imply that my opinion on mr. Navia, whatever it is or could be,
would have anything to do with my dislike of insults as a style of rhetoric.
It does not.

And if you are convinced no insults were involved, I can only say that your
conception of an insult is apparently different from mine. No sense arguing
from that angle.

All this just reinforces my existing belief that commenting on a flame is
pointless; I should have resisted the temptation, which I find stirring in
me from time to time. I promise to show more restraint in the future.

S.

[jacob navia]

Skarmander a écrit :

>
All this just reinforces my existing belief that commenting on a flame
is pointless; I should have resisted the temptation, which I find
stirring in me from time to time. I promise to show more restraint in
the future.

Agreed. That is a good sentence to keep.

Now, I will eat a few more babies for lunch!

jacob

[ena8t8si]

Eric Sosman wrote:

lcw1964 wrote:

Whoa whoa whoa!

I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Fine. Use it good health. However, keep in mind that
this compiler (if we are to believe Jacob's description) is
not a C compiler, at least, not a C compiler in its usual
mode of operation.

Aren't most C compilers not C compilers in their usual
mode of operation? For gcc, for example, I'm pretty
sure that what it accepts isn't strictly standard C
unless a switch or two is added.

[av]

On 29 Jul 2006 23:37:39 -0700, lcw1964 wrote:

>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:

i have "erf" too; i wrote it seeing my university book "analisi 1" the
integral:
oo
x 2 ---- k 2k + 1
/ -t \ (-1) x
| e dt = / --------------
/ ---- k k! (2k + 1)
0 0

in some other place i found
it seems x 2
2 / -t
erf(x)= -------- * | e dt
------ /
\/ Pi 0

erfc(x)= 1 - erf(x)

then an inplementation (don't know if is right it is all in "test"
here)

#include "num32.h"

int pause(void)
{int c;
P("\nPress enter to couninue...");
c=getchar_m(); R c;
}

int main(void)
{int i;
fnum x;
///////////
cout << "inserisci la precisione [\"0\" finisce]";
if(get_int(cin, &i, 0, 9000)==0) R 0;
set_precision10(i);
cout << "inserisci un numero "; cin >x;
cout << "erfc(" << x << ")==" << erfc(x) << "\n";
cout << "erf (" << x << ")==" << erf (x) << "\n";
pause(); R 0;
}
--------------------------------------------------

>m3

inserisci la precisione ["0" finisce]assssffe err
Errore o importo fuori range: Riprova -999999999999999999
Errore o importo fuori range: Riprova -1
Errore o importo fuori range
DD:cont1=0 buffh_len1=4 buffh1=0x43285C
MEMORIA DINAMICA LIBERATA Tot=0.0080 Mb

>m3

inserisci la precisione ["0" finisce]sii isisi uaia
Errore o importo fuori range: Riprova 9999999999999999999999
Errore o importo fuori range: Riprova 200
base_10=200 precision=21
inserisci un numero 1.73
erfc(1.73)==0.014421500171819502568811928600244606 213396306816246546707796466909
14859183973970631507594187479276740019642092608453 769205806480452297025856609028
23961796790779129348207438425579729456045965735427 7808
erf(1.73)==0.9855784998281804974311880713997553937 86603693183753453292203533090
85140816026029368492405812520723259980357907391546 230794193519547702974143390971
76038203209220870651792561574420270543954034264572 2192

Press enter to couninue...
DD:cont1=0 buffh_len1=26 buffh1=0x43263C
MEMORIA DINAMICA LIBERATA Tot=0.0080 Mb

>m3

inserisci la precisione ["0" finisce]20
base_10=20 precision=3
inserisci un numero aaaa
erfc(0)==1
erf (0)==0

Press enter to couninue...
DD:cont1=0 buffh_len1=8 buffh1=0x43263C
MEMORIA DINAMICA LIBERATA Tot=0.0080 Mb

>m3

inserisci la precisione ["0" finisce]700
base_10=700 precision=73
inserisci un numero 1.73
erfc(1.73)==0.014421500171819502568811928600244606 213396306816246546707796466909
14859183973970631507594187479276740019642092608453 769205806480452297025856609028
23961796790779129348207438425579729456045965735427 780829276055456766177255810490
09489450899305874485241735734329902771642126578242 826908491881699290363909702738
37485258369381146789843679628660206881332006907935 825951089724201992511894706841
04923803455775165217127667997338419520875591912910 520278572333408716697499401634
32239970196933678661287227224591967016761163282166 438400430159370017368174950344
99480951075785283901779522028949334324485846719525 271369786793031600737891870279
84437838261036547158831015418153908386052592280076 111430463372003832425102
erf(1.73)==0.9855784998281804974311880713997553937 86603693183753453292203533090
85140816026029368492405812520723259980357907391546 230794193519547702974143390971
76038203209220870651792561574420270543954034264572 219170723944543233822744189509
90510549100694125514758264265670097228357873421757 173091508118300709636090297261
62514741630618853210156320371339793118667993092064 174048910275798007488105293158
95076196544224834782872332002661580479124408087089 479721427666591283302500598365
67760029803066321338712772775408032983238836717833 561599569840629982631825049655
00519048924214716098220477971050665675514153280474 728630213206968399262108129720
15562161738963452841168984581846091613947407719923 888569536627996167574897

Press enter to couninue...
DD:cont1=0 buffh_len1=89 buffh1=0x4327BC
MEMORIA DINAMICA LIBERATA Tot=0.0240 Mb

[lcw1964]

You are obviously using an arbitrary precsion library to get such
excellent results. I can confirm that your output agrees fully with
Maple, and I gather Mathematica too--go to functions.wolfram.com, which
is an excellent interactive website driven by the Mathematica
computational engine.

Could you email me with more information about what you are using? I
would ask you to post here, but since this NG is interested in
standardization and portability it may not be the best place to get
into a detailed discussion about non-standard libraries and compiler
extensions.

Les

[lcw1964]

Tom St Denis wrote:

Have you thought of trying out Cygwin? It gives you a nice UNIX
emulation layer on-top of the windows runtime (e.g. applications you
write in Cygwin stand half a chance of working on BSD, Linux and UNIX).

I don't know for a fact, but maybe the math libs linked in with Cygwin
can help you out.

I have done a little homework and have decided to give Cygwin a try.

Since I have no idea what packages I need, I am in the process of
downloading the whole monstrously huge thing--yes, I choose the
"install all" option in the setup chooser! I have a good DSL connection
but it looks like I could very well be here until next week ;)

At least I have a good size hard drive, and it looks like Cygwin puts
everything in one place and doesn't splash the file system and registry
with tons of stuff that you can never safely get rid of later. Because
of this, I have no misgivings about doing a full download since it will
be no problem get Cygwin fully off my system later should I wish to.

I will let you know how my gcc adventures go once I get this downloaded
and set up.... I am up to 30% of download completion as I send this,
and it has only been 45min so far ;)

Les

[av]

On 6 Aug 2006 20:48:16 -0700, lcw1964 wrote:

>You are obviously using an arbitrary precsion library to get such
excellent results. I can confirm that your output agrees fully with
Maple, and I gather Mathematica too--go to functions.wolfram.com, which
is an excellent interactive website driven by the Mathematica
computational engine.

Could you email me with more information about what you are using? I

i'm using my little "home-made" math library
it is full of bug for example:

inserisci la precisione ["0" finisce]20
base_10=20 precision=3
inserisci un numero aaaa
erfc(0)==1
erf (0)==0

is wrong because "cin >x;" if fail it has to assign
"FAIL" in the stream flag (never assign a value in "x") and
possibly sane the stream like this call never would be
and this were not. so i have to rewrite >>(istream&, fnum&).
But it seems ">>" is ok now