long double versions of functions in gcc under Cygwin

[lcw1964]

Greetings, all,

I am trying to port a little bit of math code to gcc, that in the
original version used the long double version of several functions (in
particular, atanl, fabsl, and expl).

I get a complie-time "unidentified reference" error to the expl()
calls, but gcc seems to digest atanl and fabsl just fine. Changing expl
to exp cures the compile time problem, but I get at best double
precision in the final results. I am assuming that the use of exp() vs.
expl() is the weak link.

The GCC documentation seems to imply that expl() is supported, but I
have no idea where to find it or how to link it in properly. For that
matter, I can't seem to find prototypes in math.h for fabsl or atanl,
and they don't make gcc cough at all.

I hope this tenderfoot can find some direction, or I may resort to
singing the praises of the egregiously un-portable lcc-win32 with its
impressive 100+ digit precision qfloat library ;)

cheers,

Les

p.s. I am trying to keep this simple, so if there is a solution within
the main gcc offerings without me having to turn to the GSL, I would
like to try that first.

[Flash Gordon]

en******@yahoo.com wrote:

Flash Gordon wrote:

>en******@yahoo.com wrote:

>>jaysome wrote:

<snip alternative versions of code and discussions of the merits>

>>Two comments. First, not all resource allocation/release can be
rewritten in the style you suggest using release(NULL).[*]
Second, why would someone use throw when what's it's doing
basically just a goto in disguise?

Those are reasonable questions, but most of them have obvious
answers.

A reason for preferring goto to throw (when possible) is that
goto is guaranteed to be local; throw isn't. I don't see
any reason to use throw, except to avoid the bugaboo of using
goto. And that doesn't strike me as much of a reason.

To me throw would be the more natural. The problem is you have hit an
exceptional situation that you have to deal with not that you need to
clean up. I can accept, however, that others may not see it that way. I
also don't see the locality as a problem because with any sensible (to
me) sized code block you can see at a glance that it is enclosed in a
local try block.

I'm not saying you are wrong, this is a matter of personal preference in
my opinion, not who is right or wrong.

>Why use a for loop when it is just a while loop in disguise? Why use a
while loop when it is just a conditional goto and an unconditional goto
in disguise? Why use a do-while loop when it is just a conditional goto
in disguise? Why use a break when it is just a goto in disguise?

> If the release(NULL) technique
works, it seems better to dispense with try/catch altogether:

int typfun()
{
int rc = 0;
...
x=y=z=NULL;
do {
x = get_resource_one();
if(x==NULL){ rc = -1; break; }
y = get_resource_two();
if(y==NULL){ rc = -2; break; }
z = get_resource_three();
if(z==NULL){ rc = -3; break; }
} while(0);

release_resource(x);
release_resource(y);
release_resource(z);

return rc;
}

Or, if one had try/catch
int typfun()
{
int rc = 0;
...
x=y=z=NULL;
try {
x = get_resource_one();
if(x==NULL) throw -1;
y = get_resource_two();
if(y==NULL) throw -2;
z = get_resource_three();
if(z==NULL) throw -3;
}
catch( int i )
rc = i;

release_resource(x);
release_resource(y);
release_resource(z);

return rc;
}

I'm sure it is a few characters less typing ;-)

Same comments as above apply here. More mental
effort is required for try/throw/catch than
for do/break/while(0);

For me it does not require more mental effort. If anything it is less
because after seeing the do I don't have to check the end to know it is
just there to allow breaking out.

Of course, I spent years using a try/catch type system so I'm so
familiar with it that it requires no more thinking than understanding
for (;;) {
/* whatever */
}

>>[*] For performance reasons, among others.

Premature optimisation is the root of quite a lot of problems.

The optimization was not premature in the cases
I was referring to.

That was not clear in your previous post. You've since said that you had
found you had a performance problem, measured, and found this a
significant saving. In such conditions it is reasonable to make the
optimisation.

> Anyway,
as someone else suggested you can always nest the blocks.

Yes, and nesting the blocks produces a less satisfactory
result, as my response to that suggestion explained.

Again, very much a matter of personal preference.
--
Flash Gordon
Still sigless on this computer.

[lcw1964]

Dann Corbit wrote:

I think Moshier's code is beautiful. It was originally written in 1984, and
later reworked so that you could compile it with ANSI style prototypes.

At the top of every file is a detailed explanation of what the code does,
which equations are used to solve the problem, and what the measured errors
were in calibration of the function's useful range.

I am a very amateur hobbyist program so I am not qualified to comment
on either the aesthetics of the code or the virtues (or not) of goto
statements, but I know enough to be impressed by the math of it.

Mr. Corbit was quite correct to comment earlier in the thread that the
qlib package was easy to make, and, with a little research on my part,
is not so inscrutable to use. I have been particularly impressed with
Moshier's code for the high precision version of the gamma function.
This function is not something that is easily computed to very high
precision--the asymptotic Stirling series uses Bessel numbers which in
the higher terms get huge--but Moshier's code is painstakingly
thorough, with the requisite constants to dozes of digits rendered in
the code.

With a little practice I have been able to write a little
implementation that computes this function to over 100 digits. That
impresses me. As a user, I think I could forgive the evil gotos if
they get the job done :)

Les

[ena8t8si]

Flash Gordon wrote:

en******@yahoo.com wrote:

Flash Gordon wrote:

en******@yahoo.com wrote:
jaysome wrote:

<snip alternative versions of code and discussions of the merits>

>Two comments. First, not all resource allocation/release can be
rewritten in the style you suggest using release(NULL).[*]
Second, why would someone use throw when what's it's doing
basically just a goto in disguise?

Those are reasonable questions, but most of them have obvious
answers.

A reason for preferring goto to throw (when possible) is that
goto is guaranteed to be local; throw isn't. I don't see
any reason to use throw, except to avoid the bugaboo of using
goto. And that doesn't strike me as much of a reason.

To me throw would be the more natural. The problem is you have hit an
exceptional situation that you have to deal with not that you need to
clean up. I can accept, however, that others may not see it that way. I
also don't see the locality as a problem because with any sensible (to
me) sized code block you can see at a glance that it is enclosed in a
local try block.

I'm not saying you are wrong, this is a matter of personal preference in
my opinion, not who is right or wrong.

Why use a for loop when it is just a while loop in disguise? Why use a
while loop when it is just a conditional goto and an unconditional goto
in disguise? Why use a do-while loop when it is just a conditional goto
in disguise? Why use a break when it is just a goto in disguise?

If the release(NULL) technique
works, it seems better to dispense with try/catch altogether:

int typfun()
{
int rc = 0;
...
x=y=z=NULL;
do {
x = get_resource_one();
if(x==NULL){ rc = -1; break; }
y = get_resource_two();
if(y==NULL){ rc = -2; break; }
z = get_resource_three();
if(z==NULL){ rc = -3; break; }
} while(0);

release_resource(x);
release_resource(y);
release_resource(z);

return rc;
}
Or, if one had try/catch
int typfun()
{
int rc = 0;
...
x=y=z=NULL;
try {
x = get_resource_one();
if(x==NULL) throw -1;
y = get_resource_two();
if(y==NULL) throw -2;
z = get_resource_three();
if(z==NULL) throw -3;
}
catch( int i )
rc = i;

release_resource(x);
release_resource(y);
release_resource(z);

return rc;
}

I'm sure it is a few characters less typing ;-)

Same comments as above apply here. More mental
effort is required for try/throw/catch than
for do/break/while(0);

For me it does not require more mental effort. If anything it is less
because after seeing the do I don't have to check the end to know it is
just there to allow breaking out.

Of course, I spent years using a try/catch type system so I'm so
familiar with it that it requires no more thinking than understanding
for (;;) {
/* whatever */
}

>[*] For performance reasons, among others.
Premature optimisation is the root of quite a lot of problems.

The optimization was not premature in the cases
I was referring to.

That was not clear in your previous post. You've since said that you had
found you had a performance problem, measured, and found this a
significant saving. In such conditions it is reasonable to make the
optimisation.

Anyway,
as someone else suggested you can always nest the blocks.

Yes, and nesting the blocks produces a less satisfactory
result, as my response to that suggestion explained.

Again, very much a matter of personal preference.

Reasonable comments.

Just a few points in reply.

It's true for short functions that there isn't much difference
between the try/catch form and the goto form (or do/while(0)
form). Unfortunately the real cases where these come up (based on
my experience) tend to have longer than average function bodies,
and it isn't always easy to scan the whole function.

Two, whatever one's personal reaction, adding exception handling
to C would produce a bigger language than C is now. A bigger
language means more mental effort to understand programs written
in that language.

Three, exceptions are as easy to misuse as goto is, and in my
experience misused more often.

Adding these up, getting rid of gotos still doesn't make a good
argument for introducing exception handling into C. It might
(or might not) be good to introduce it for other reasons, but
getting rid of gotos isn't one of them.