Re: Bug in libm or libstdc++.

Re: Bug in libm or libstdc++.

[N8TM]

In a message dated 3/2/99 8:32:33 AM Pacific Standard Time, doug@seaspace.com
writes:

<< Try Chebyshev instead of that funky spelling above :)
  >>
You should use the other spelling if you're looking for references in German,
I imagine.

Re: Bug in libm or libstdc++.

[N8TM]

In a message dated 3/2/99 8:32:33 AM Pacific Standard Time, doug@seaspace.com
writes:

<< Try Chebyshev instead of that funky spelling above :)
  >>
You should use the other spelling if you're looking for references in German,
I imagine.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 05:16 AM 3/1/99 -0300, you wrote:
>> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
>>    I've mentioned a few times before.
>
>It is outdated anyway.

No it is not. It's the most recent version around, so it isn't possible for
it to be outdated, especially since if it were, this would be completely
unacceptable, as it would imply that there is no up-to-date reference, and
that of course just can't have been allowed.

>...egcs targets the ANSI C++ Standard, not the ARM.

What is "the ARM"?

(Note: Search engine results: 725,480 hits, of which none on the
 first page are relevant. Search engines are simply not usable for
 finding this stuff out! Unless you honestly expect me to read
 through 72,548 pages and 725,480 URLs and descriptions before
 asking any questions, which would be ludicruous.)

In any case, quit accusing me of ignorance of the C++ essentials and quit
accusing, of all people, Bjarne Stroustrup of same. BTW, this is veering
rapidly off-topic due to you.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Mar  2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:

>> ...egcs targets the ANSI C++ Standard, not the ARM.

> What is "the ARM"?

The ARM is Stroustrup's book.  It is not the ANSI/ISO C++ Standard.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Bug in libm or libstdc++.

[Joe Buck]

> > Date: Sat, 27 Feb 1999 01:21:20 -0500
> > From: Paul Derbyshire <pderbysh@usa.net>
> 
> > My copy of Stroustrup makes no mention of "export", IIRC.

YDRC. (you don't remember correctly).  But then, no human being could
reliably make such statements from memory about a 900-page book.

> Hum, that's strange, are you sure you have his fourth edition? :-)

The 3rd edition does indeed mention "export", very briefly, in
section 9.2.3.  RTFI (read the fine index).

Please note that while Stroustrup's 3rd edition is an excellent book, it
contains many errors.  See http://www.research.att.com/~bs/3rd_errata.html
for a list of the known ones.

The book has gone through nine printings now, and how many errors you have
in your copy reflects which printing you have.  The errata list for the
9th printing is quite small, unfortunately I bought the 2nd printing which
has loads of errors.

Re: Bug in libm or libstdc++.

[Doug Semler]

----- Original Message -----
From: Paul Derbyshire <pderbysh@usa.net>
To: <egcs@egcs.cygnus.com>
Sent: Tuesday, March 02, 1999 8:04 AM
Subject: Re: Bug in libm or libstdc++.


>At 04:30 PM 3/1/99 +0000, you wrote:
>>When you want to use a Polynom approximation, you should rather use a
>>Tschebyscheff polynom.
>
>Perhaps.
>
>>Look it up in a mathematical enceclopedia.
>
>Impossible, since I don't have the URL for any, and a Web search turned up
>dry. (Again.)
>Of course, printed, expensive ones are not a viable alternative, since I
>have insufficient funds, no access to any vendor of such a product, and
>moreover no information about how I would locate such a vendor given that I
>did have the access and the three-figure amount of spare cash. Also, egcs
>is a free software product run on an open development model, and so it is
>not possible for them to require/expect a contributor to obtain expensive
>items in order to contribute, without thereby violating their own charter.

Try Chebyshev instead of that funky spelling above :)


Regarding books ... as far as I know, libraries are still around :)


---
Doug Semler | doug@seaspace.com
SeaSpace Corporation | Garbage In -- Gospel Out
Least Senior Software Developer; | Minister of things to do Next Quarter
Low Man on the Totem Pole | (but will Never Be Done) DNRC O-
A closed mind is a terrible thing | Bus Error (passengers dumped)

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 12:07 PM 3/1/99 PST, you wrote:

[Deleted]
['export' is in Stroustrup 3rd Ed.]

Interesting. There is one lone mention in connection with templates, which
seems to describe some usage that never actually occurs, namely, putting a
template in a .cc file and expecting another .cc file to magically be able
to use it, instead of putting it in a .h file. How would such a scheme be
implemented anyways? Making the compiler scan the filesystem (and then
maybe the net) for .cc files that might define a template after it sees one
used without definition in a translation unit it is processing, strikes me
as impractical... Perhaps the idea is for the "export" to cause a compiler,
on reading a .cc file, to add any instantiations of the template in
question to a global collection of object files the linker always links
against, but then of course, 
1. What if the other cc file is encountered first?
2. What if the other cc file uses a combination of template
   parameters the first does not instantiate?
3. What if the compiler does this and the linker expects otherwise,
   or vice versa?

>Please note that while Stroustrup's 3rd edition is an excellent book, it
>contains many errors.  See http://www.research.att.com/~bs/3rd_errata.html
>for a list of the known ones.

Read them. (For the printing that produced my copy.) The only one with
potential to really trip someone up is:

pg 218 s/if (atexit(&my_cleanup))/if (atexit(&my_cleanup)==0)/ 

:-)


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Mar  2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:

> ['export' is in Stroustrup 3rd Ed.]

> Interesting. There is one lone mention in connection with templates, which
> seems to describe some usage that never actually occurs, namely, putting a
> template in a .cc file and expecting another .cc file to magically be able
> to use it, instead of putting it in a .h file. How would such a scheme be
> implemented anyways?

Well, it doesn't occur because `export' is not widely available yet.
But it probably will be in the future, and then people will probably
start using it.

The C++ Standard allows an implementation to require the translation
unit containing the definition of the exported template to be compiled
before others that depend on it, so it is possible to create databases
with template repositories, but definitely some magic is needed in
order to implement this, and such magic can hardly be made reliable.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Bug in libm or libstdc++.

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:

> At 06:40 PM 2/27/99 +0100, you wrote:
>> Get a newer one, or better yet, get a clue.

> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
>    I've mentioned a few times before.

It is outdated anyway.  It is not the ANSI C++ Standard, and egcs
targets the ANSI C++ Standard, not the ARM.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Bug in libm or libstdc++.

[N8TM]

In a message dated 3/2/99 8:06:06 AM Pacific Standard Time, pderbysh@usa.net
writes:

<< >When you want to use a Polynom approximation, you should rather use a
 >Tschebyscheff polynom.
 
 Perhaps.
 
 >Look it up in a mathematical enceclopedia.
  >>
The much maligned Numerical Recipes is quite adequate to give you a start in
this area.  There are plenty of open source code examples as well.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 04:30 PM 3/1/99 +0000, you wrote:
>When you want to use a Polynom approximation, you should rather use a
>Tschebyscheff polynom.

Perhaps.

>Look it up in a mathematical enceclopedia.

Impossible, since I don't have the URL for any, and a Web search turned up
dry. (Again.)
Of course, printed, expensive ones are not a viable alternative, since I
have insufficient funds, no access to any vendor of such a product, and
moreover no information about how I would locate such a vendor given that I
did have the access and the three-figure amount of spare cash. Also, egcs
is a free software product run on an open development model, and so it is
not possible for them to require/expect a contributor to obtain expensive
items in order to contribute, without thereby violating their own charter.

>If you just want to get something working, you can skip the proofs and go
>straight for the recipes ;-)

Of course.

>I happen to have written sqrt functions when I worked on an XFmode /
>TFmode fp-bit.c .  ( The project got stuck for lack of priority. )
>I'll send it to you in private email.

A sqrt can be implemented quickly with Newton's method, converging in
O(log_2 # binary digits in mantissa) starting from a suitable guess. This
is O(log n)... I doubt it can be bettered.

It's the trig, exponentials, and especially the logarithms that are the
nontrivial ones. :-)


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Mike Stump]

> Date: Sat, 27 Feb 1999 01:21:20 -0500
> From: Paul Derbyshire <pderbysh@usa.net>

> My copy of Stroustrup makes no mention of "export", IIRC.

Hum, that's strange, are you sure you have his fourth edition?

:-)  (Sorry, couldn't resist.)

Re: Bug in libm or libstdc++.

[Joern Rennecke]

> I may be mathematically inclined but I have none of the
> numerical-computation background necessary to know how to implement these
> things in an optimized way. Best I could probably do is a slowly converging
> Taylor series for these things. You ened a volunteer with a bit more
> knowledge in techniques of rapid numerical computation of trig functions.


When you want to use a Polynom approximation, you should rather use a
Tschebyscheff polynom.  Look it up in a mathematical enceclopedia.
If you just want to get something working, you can skip the proofs and go
straight for the recipes ;-)

I happen to have written sqrt functions when I worked on an XFmode /
TFmode fp-bit.c .  ( The project got stuck for lack of priority. )
I'll send it to you in private email.

Re: Bug in libm or libstdc++.

[Joern Rennecke]

> Impossible, since I don't have the URL for any, and a Web search turned up
> dry. (Again.)
> Of course, printed, expensive ones are not a viable alternative, since I
> have insufficient funds, no access to any vendor of such a product, and
> moreover no information about how I would locate such a vendor given that I
> did have the access and the three-figure amount of spare cash. Also, egcs
> is a free software product run on an open development model, and so it is
> not possible for them to require/expect a contributor to obtain expensive
> items in order to contribute, without thereby violating their own charter.

Oh, I bought one for a sum that, expresed in US dollars, would be one-figure.

But never mind, you can go to one of these old-fashioned places called
'public libraries' or 'university libraries'.

> A sqrt can be implemented quickly with Newton's method, converging in
> O(log_2 # binary digits in mantissa) starting from a suitable guess. This
> is O(log n)... I doubt it can be bettered.

You have to keep in mind that multiplication itself is O(n^1.6).  Moreover,
XFmode and TFmode can be expressed in a small number of 32 / 64 bit values,
so you have a lot of discretization noise in the actual precision - runtime
function.  And sqrt is supposed to be rounded EXACTLY for IEEE, i.e. for
round to nearest, you should return that floating point value that most
accurately describes the actual square root.

> It's the trig, exponentials, and especially the logarithms that are the
> nontrivial ones. :-)

For these functions, the rounding requirements ar a lot more relaxed.

Re: Bug in libm or libstdc++.

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Mar  2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:

> ['export' is in Stroustrup 3rd Ed.]

> Interesting. There is one lone mention in connection with templates, which
> seems to describe some usage that never actually occurs, namely, putting a
> template in a .cc file and expecting another .cc file to magically be able
> to use it, instead of putting it in a .h file. How would such a scheme be
> implemented anyways?

Well, it doesn't occur because `export' is not widely available yet.
But it probably will be in the future, and then people will probably
start using it.

The C++ Standard allows an implementation to require the translation
unit containing the definition of the exported template to be compiled
before others that depend on it, so it is possible to create databases
with template repositories, but definitely some magic is needed in
order to implement this, and such magic can hardly be made reliable.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Bug in libm or libstdc++.

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Mar  2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:

>> ...egcs targets the ANSI C++ Standard, not the ARM.

> What is "the ARM"?

The ARM is Stroustrup's book.  It is not the ANSI/ISO C++ Standard.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Bug in libm or libstdc++.

[N8TM]

In a message dated 3/2/99 8:06:06 AM Pacific Standard Time, pderbysh@usa.net
writes:

<< >When you want to use a Polynom approximation, you should rather use a
 >Tschebyscheff polynom.
 
 Perhaps.
 
 >Look it up in a mathematical enceclopedia.
  >>
The much maligned Numerical Recipes is quite adequate to give you a start in
this area.  There are plenty of open source code examples as well.

Re: Bug in libm or libstdc++.

[Joern Rennecke]

> Impossible, since I don't have the URL for any, and a Web search turned up
> dry. (Again.)
> Of course, printed, expensive ones are not a viable alternative, since I
> have insufficient funds, no access to any vendor of such a product, and
> moreover no information about how I would locate such a vendor given that I
> did have the access and the three-figure amount of spare cash. Also, egcs
> is a free software product run on an open development model, and so it is
> not possible for them to require/expect a contributor to obtain expensive
> items in order to contribute, without thereby violating their own charter.

Oh, I bought one for a sum that, expresed in US dollars, would be one-figure.

But never mind, you can go to one of these old-fashioned places called
'public libraries' or 'university libraries'.

> A sqrt can be implemented quickly with Newton's method, converging in
> O(log_2 # binary digits in mantissa) starting from a suitable guess. This
> is O(log n)... I doubt it can be bettered.

You have to keep in mind that multiplication itself is O(n^1.6).  Moreover,
XFmode and TFmode can be expressed in a small number of 32 / 64 bit values,
so you have a lot of discretization noise in the actual precision - runtime
function.  And sqrt is supposed to be rounded EXACTLY for IEEE, i.e. for
round to nearest, you should return that floating point value that most
accurately describes the actual square root.

> It's the trig, exponentials, and especially the logarithms that are the
> nontrivial ones. :-)

For these functions, the rounding requirements ar a lot more relaxed.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 12:07 PM 3/1/99 PST, you wrote:

[Deleted]
['export' is in Stroustrup 3rd Ed.]

Interesting. There is one lone mention in connection with templates, which
seems to describe some usage that never actually occurs, namely, putting a
template in a .cc file and expecting another .cc file to magically be able
to use it, instead of putting it in a .h file. How would such a scheme be
implemented anyways? Making the compiler scan the filesystem (and then
maybe the net) for .cc files that might define a template after it sees one
used without definition in a translation unit it is processing, strikes me
as impractical... Perhaps the idea is for the "export" to cause a compiler,
on reading a .cc file, to add any instantiations of the template in
question to a global collection of object files the linker always links
against, but then of course, 
1. What if the other cc file is encountered first?
2. What if the other cc file uses a combination of template
   parameters the first does not instantiate?
3. What if the compiler does this and the linker expects otherwise,
   or vice versa?

>Please note that while Stroustrup's 3rd edition is an excellent book, it
>contains many errors.  See http://www.research.att.com/~bs/3rd_errata.html
>for a list of the known ones.

Read them. (For the printing that produced my copy.) The only one with
potential to really trip someone up is:

pg 218 s/if (atexit(&my_cleanup))/if (atexit(&my_cleanup)==0)/ 

:-)


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Doug Semler]

----- Original Message -----
From: Paul Derbyshire <pderbysh@usa.net>
To: <egcs@egcs.cygnus.com>
Sent: Tuesday, March 02, 1999 8:04 AM
Subject: Re: Bug in libm or libstdc++.


>At 04:30 PM 3/1/99 +0000, you wrote:
>>When you want to use a Polynom approximation, you should rather use a
>>Tschebyscheff polynom.
>
>Perhaps.
>
>>Look it up in a mathematical enceclopedia.
>
>Impossible, since I don't have the URL for any, and a Web search turned up
>dry. (Again.)
>Of course, printed, expensive ones are not a viable alternative, since I
>have insufficient funds, no access to any vendor of such a product, and
>moreover no information about how I would locate such a vendor given that I
>did have the access and the three-figure amount of spare cash. Also, egcs
>is a free software product run on an open development model, and so it is
>not possible for them to require/expect a contributor to obtain expensive
>items in order to contribute, without thereby violating their own charter.

Try Chebyshev instead of that funky spelling above :)


Regarding books ... as far as I know, libraries are still around :)


---
Doug Semler | doug@seaspace.com
SeaSpace Corporation | Garbage In -- Gospel Out
Least Senior Software Developer; | Minister of things to do Next Quarter
Low Man on the Totem Pole | (but will Never Be Done) DNRC O-
A closed mind is a terrible thing | Bus Error (passengers dumped)

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 04:30 PM 3/1/99 +0000, you wrote:
>When you want to use a Polynom approximation, you should rather use a
>Tschebyscheff polynom.

Perhaps.

>Look it up in a mathematical enceclopedia.

Impossible, since I don't have the URL for any, and a Web search turned up
dry. (Again.)
Of course, printed, expensive ones are not a viable alternative, since I
have insufficient funds, no access to any vendor of such a product, and
moreover no information about how I would locate such a vendor given that I
did have the access and the three-figure amount of spare cash. Also, egcs
is a free software product run on an open development model, and so it is
not possible for them to require/expect a contributor to obtain expensive
items in order to contribute, without thereby violating their own charter.

>If you just want to get something working, you can skip the proofs and go
>straight for the recipes ;-)

Of course.

>I happen to have written sqrt functions when I worked on an XFmode /
>TFmode fp-bit.c .  ( The project got stuck for lack of priority. )
>I'll send it to you in private email.

A sqrt can be implemented quickly with Newton's method, converging in
O(log_2 # binary digits in mantissa) starting from a suitable guess. This
is O(log n)... I doubt it can be bettered.

It's the trig, exponentials, and especially the logarithms that are the
nontrivial ones. :-)


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 05:16 AM 3/1/99 -0300, you wrote:
>> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
>>    I've mentioned a few times before.
>
>It is outdated anyway.

No it is not. It's the most recent version around, so it isn't possible for
it to be outdated, especially since if it were, this would be completely
unacceptable, as it would imply that there is no up-to-date reference, and
that of course just can't have been allowed.

>...egcs targets the ANSI C++ Standard, not the ARM.

What is "the ARM"?

(Note: Search engine results: 725,480 hits, of which none on the
 first page are relevant. Search engines are simply not usable for
 finding this stuff out! Unless you honestly expect me to read
 through 72,548 pages and 725,480 URLs and descriptions before
 asking any questions, which would be ludicruous.)

In any case, quit accusing me of ignorance of the C++ essentials and quit
accusing, of all people, Bjarne Stroustrup of same. BTW, this is veering
rapidly off-topic due to you.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Joe Buck]

> > Date: Sat, 27 Feb 1999 01:21:20 -0500
> > From: Paul Derbyshire <pderbysh@usa.net>
> 
> > My copy of Stroustrup makes no mention of "export", IIRC.

YDRC. (you don't remember correctly).  But then, no human being could
reliably make such statements from memory about a 900-page book.

> Hum, that's strange, are you sure you have his fourth edition? :-)

The 3rd edition does indeed mention "export", very briefly, in
section 9.2.3.  RTFI (read the fine index).

Please note that while Stroustrup's 3rd edition is an excellent book, it
contains many errors.  See http://www.research.att.com/~bs/3rd_errata.html
for a list of the known ones.

The book has gone through nine printings now, and how many errors you have
in your copy reflects which printing you have.  The errata list for the
9th printing is quite small, unfortunately I bought the 2nd printing which
has loads of errors.

Re: Bug in libm or libstdc++.

[Mike Stump]

> Date: Sat, 27 Feb 1999 01:21:20 -0500
> From: Paul Derbyshire <pderbysh@usa.net>

> My copy of Stroustrup makes no mention of "export", IIRC.

Hum, that's strange, are you sure you have his fourth edition?

:-)  (Sorry, couldn't resist.)

Re: Bug in libm or libstdc++.

[Joern Rennecke]

> I may be mathematically inclined but I have none of the
> numerical-computation background necessary to know how to implement these
> things in an optimized way. Best I could probably do is a slowly converging
> Taylor series for these things. You ened a volunteer with a bit more
> knowledge in techniques of rapid numerical computation of trig functions.


When you want to use a Polynom approximation, you should rather use a
Tschebyscheff polynom.  Look it up in a mathematical enceclopedia.
If you just want to get something working, you can skip the proofs and go
straight for the recipes ;-)

I happen to have written sqrt functions when I worked on an XFmode /
TFmode fp-bit.c .  ( The project got stuck for lack of priority. )
I'll send it to you in private email.

Re: Bug in libm or libstdc++.

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:

> At 06:40 PM 2/27/99 +0100, you wrote:
>> Get a newer one, or better yet, get a clue.

> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
>    I've mentioned a few times before.

It is outdated anyway.  It is not the ANSI C++ Standard, and egcs
targets the ANSI C++ Standard, not the ARM.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 02:28 PM 2/28/99 +0200, you wrote:
>
>On Fri, 26 Feb 1999, Paul Derbyshire wrote:
>
>> You're wrong, I'm right. Long double versions of atan and friends ARE
>> demanded by the standard.

>Which standard is that?

The ISO C++ standard. The C++ compiling environment is what was under
discussion.

>libm.a which comes with DJGPP v2.02 is not a C++
>library, it's a C library, and AFAIK it conforms to current C
>standards.

Then it must be libstdc++ that is supposed to overload those functions for
floats and long doubles. As the subject says, the bug was in one of those
libraries, and your clarification has narrowed it down to libstdc++.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Marc Espie]

In article < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > you write:
>At 10:36 AM 2/26/99 PST, you wrote:
>>Limited resources.  Up to now most resources have been concentrated on
>>completing the compiler portion of the standard, and we are very close.
>>The only significant unimplemented feature is "export".

>My copy of Stroustrup makes no mention of "export", IIRC.

Get a newer one, or better yet, get a clue.

I have the chance to read the egcs-ml thru an email to local news
gateway.

You know what ? You're the first individual to make my kill-file on this list.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 02:03 PM 2/26/99 -0800, you wrote:
>:-)  You could learn!

Me and what heap of time and money to support getting some kind of
additional education in this, while concurrently finishing my computer
mathematics degree (which doesn't cover numeric computation of basic trig
in the third year)?


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Joe Buck]

> At 03:32 PM 2/24/99 PST, you wrote:
> >You have already been informed that libstdc++ is not complete.  Sorry.
> 
> The standard has been around in largely complete form for over a year, and
> finalized for many months. I am curious as to what is the cause for all of
> these omissions...

Limited resources.  Up to now most resources have been concentrated on
completing the compiler portion of the standard, and we are very close.
The only significant unimplemented feature is "export".

> In any case, to avoid any more unpleasant surprised I would like to see a
> list of all the omissions in the current libstdc++ and other
> non-conformances, and where possible ETAs for the missing components.

If you would like to volunteer to assemble such a list, and do most of
the research yourself, you might find that others are willing to help.
If you continue to demand that others do work, you will probably just
create more hostility.

As for ETAs, in the free software world the only answer you will get is
"when it's ready".

> It
> would be a good idea to post a periodic libstdc++ progress report and calls
> for volunteers to implement some of the stuff. I think that might attract
> more developers to fixing up and finishing implementing the standard C++
> library.

See http://sourceware.cygnus.com/libstdc++/

> An area where I may be able to help is with the standard valarray and its
> friends, once I get back a response regarding making the compiler eliminate
> temporaries and excess copies in argument passing and return.

Again, see above.

Re: Bug in libm or libstdc++.

[Bob McWhirter]

On Mon, 22 Feb 1999, Paul Derbyshire wrote:

> C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
> c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
> `atan(long double)'
	
	[ snip ]

> What the hell?

	Is that -really- necessary?  Pipe down, already.

> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.

	Uhhh... if you're referring to page 660 (section 22.3)
	it most certainly does not make any such guarantee with
	regards to -long double- datatypes.

> Using egcs 1.1.1 and the libm and libstdc++ that came with it.

	at least on my box (sparc solaris), libm is vendor provided.

	gnu/include/g++/cmath -does- make reference to the math
	functions that use long doubles for arguments, but I don't
	think any library on my box actually supports them.

	Possibly there for platforms that do?  There for platforms
	that typedef a long double to be the same as a double?

	(nm'ing vendor's libm and stdc++ does not reveal math
	 functions taking long doubles, but possibly some other
	 lib I'm ignoring?  I did find math functions take
	 complex objects as arguments though.)

		-Bob

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 10:36 AM 2/26/99 PST, you wrote:
>Limited resources.  Up to now most resources have been concentrated on
>completing the compiler portion of the standard, and we are very close.
>The only significant unimplemented feature is "export".

My copy of Stroustrup makes no mention of "export", IIRC.

>If you would like to volunteer to assemble such a list...

Ack!

Well, for starters:
* <valarray>  to be implemented
* <limits>  to be implemented
* "void (*foo) (void) throw ();"  causes a spurious error
* IIRC stringstreams and <sstream> were incomplete/missing

Anyone else who'se noticed an omission/incomplete thing/bug in C++ support
that isn't platform-dependent is welcome to add to the list.

>As for ETAs, in the free software world the only answer you will get is
>"when it's ready".

Or "when you do it yourself" right? <g>

I may be able to cobble together a draft of a working <valarray>. If I come
up with one amidst all the other work I'm doing on my own stuff, I'll be
sure to offer it here.

>See http://sourceware.cygnus.com/libstdc++/

OK

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 03:32 PM 2/24/99 PST, you wrote:
>You have already been informed that libstdc++ is not complete.  Sorry.

The standard has been around in largely complete form for over a year, and
finalized for many months. I am curious as to what is the cause for all of
these omissions... I would love to help but I don't know the first thing
about implementing these mathematical functions.

In any case, to avoid any more unpleasant surprised I would like to see a
list of all the omissions in the current libstdc++ and other
non-conformances, and where possible ETAs for the missing components. It
would be a good idea to post a periodic libstdc++ progress report and calls
for volunteers to implement some of the stuff. I think that might attract
more developers to fixing up and finishing implementing the standard C++
library.

An area where I may be able to help is with the standard valarray and its
friends, once I get back a response regarding making the compiler eliminate
temporaries and excess copies in argument passing and return.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Bug in libm or libstdc++.

[Paul Derbyshire]

C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
`atan(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xa8):ntst.cc: undefined reference to
`exp(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xef):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x136):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x17d):ntst.cc: undefined reference to
`sqrt(long double)'

What the hell?

Stroustrup 3rd Ed definitely informs me that long double overloads for
these and other functions are supposed to be in either libm or libstdc++.

Using egcs 1.1.1 and the libm and libstdc++ that came with it.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 11:35 AM 2/26/99 -0500, you wrote:

[Long double overloads of libm functions in libstdc++]

>Then ... implement them.

I may be mathematically inclined but I have none of the
numerical-computation background necessary to know how to implement these
things in an optimized way. Best I could probably do is a slowly converging
Taylor series for these things. You ened a volunteer with a bit more
knowledge in techniques of rapid numerical computation of trig functions.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 06:40 PM 2/27/99 +0100, you wrote:
>Get a newer one, or better yet, get a clue.

1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
   I've mentioned a few times before.
2. There is no need to be insulting. We're all mature adults here...or
   at least I thought we were...


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

>	Uhhh... if you're referring to page 660 (section 22.3)
>	it most certainly does not make any such guarantee with
>	regards to -long double- datatypes.

S22.3, page 661: "double atan (double) ..... In addition, <cmath> and
<math.h> supply these functions for float and long double arguments."

You're wrong, I'm right. Long double versions of atan and friends ARE
demanded by the standard. I would like to see them very soon so that I may
use them (the long double versions anyways) when I want that bit of extra
precision.......

>	at least on my box (sparc solaris), libm is vendor provided.

Not on an IBM PC clone, where it comes with the DJGPP/Cygwin/whatever
development environment you install. I installed the DJGPP/EGCS development
environment and got a broken libm.

>	gnu/include/g++/cmath -does- make reference to the math
>	functions that use long doubles for arguments, but I don't
>	think any library on my box actually supports them.

Then those libraries are broken and not conformant. I suggest you complain
to the vendor. You may also want to ask the bookstore where you got your
copy of Stroustrup for an exchange or a refund; I sure would have if my
copy had turned out to have pp. 661-662 torn out or missing.

Anyways, since these are function overloads in C++, I would expect the long
double and float versions to be in libstdc++, not libm. And libstdc++ comes
with gcc/egcs rather than being vendor supplied, on all platforms. If the
egcs libstdc++ is lacking long double overloads for atan and the like, then
this is a bug in egcs.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Mike Stump]

> Date: Fri, 26 Feb 1999 01:25:13 -0500
> To: egcs@egcs.cygnus.com
> From: Paul Derbyshire <pderbysh@usa.net>

> At 03:32 PM 2/24/99 PST, you wrote:
> >You have already been informed that libstdc++ is not complete.  Sorry.

> The standard has been around in largely complete form for over a
> year, and finalized for many months. I am curious as to what is the
> cause for all of these omissions...

They are unimportant.  As to why they are unimportant, that is a
harder to answer question.  Basically it is a value judgement by all
the users of gcc/g++.

> I would love to help but I don't know the first thing about
> implementing these mathematical functions.

:-)  You could learn!

> In any case, to avoid any more unpleasant surprised I would like to
> see a list of all the omissions in the current libstdc++

Ok, sure, love to see the list when you get done with it.  Maybe you
could get it added to the website after you're done.

Re: Bug in libm or libstdc++.

[Joe Buck]

[ no "long double" overloads of math functions ]

> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.

You have already been informed that libstdc++ is not complete.  Sorry.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 02:28 PM 2/28/99 +0200, you wrote:
>
>On Fri, 26 Feb 1999, Paul Derbyshire wrote:
>
>> You're wrong, I'm right. Long double versions of atan and friends ARE
>> demanded by the standard.

>Which standard is that?

The ISO C++ standard. The C++ compiling environment is what was under
discussion.

>libm.a which comes with DJGPP v2.02 is not a C++
>library, it's a C library, and AFAIK it conforms to current C
>standards.

Then it must be libstdc++ that is supposed to overload those functions for
floats and long doubles. As the subject says, the bug was in one of those
libraries, and your clarification has narrowed it down to libstdc++.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 06:40 PM 2/27/99 +0100, you wrote:
>Get a newer one, or better yet, get a clue.

1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
   I've mentioned a few times before.
2. There is no need to be insulting. We're all mature adults here...or
   at least I thought we were...


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 02:03 PM 2/26/99 -0800, you wrote:
>:-)  You could learn!

Me and what heap of time and money to support getting some kind of
additional education in this, while concurrently finishing my computer
mathematics degree (which doesn't cover numeric computation of basic trig
in the third year)?


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 11:35 AM 2/26/99 -0500, you wrote:

[Long double overloads of libm functions in libstdc++]

>Then ... implement them.

I may be mathematically inclined but I have none of the
numerical-computation background necessary to know how to implement these
things in an optimized way. Best I could probably do is a slowly converging
Taylor series for these things. You ened a volunteer with a bit more
knowledge in techniques of rapid numerical computation of trig functions.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Marc Espie]

In article < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > you write:
>At 10:36 AM 2/26/99 PST, you wrote:
>>Limited resources.  Up to now most resources have been concentrated on
>>completing the compiler portion of the standard, and we are very close.
>>The only significant unimplemented feature is "export".

>My copy of Stroustrup makes no mention of "export", IIRC.

Get a newer one, or better yet, get a clue.

I have the chance to read the egcs-ml thru an email to local news
gateway.

You know what ? You're the first individual to make my kill-file on this list.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 10:36 AM 2/26/99 PST, you wrote:
>Limited resources.  Up to now most resources have been concentrated on
>completing the compiler portion of the standard, and we are very close.
>The only significant unimplemented feature is "export".

My copy of Stroustrup makes no mention of "export", IIRC.

>If you would like to volunteer to assemble such a list...

Ack!

Well, for starters:
* <valarray>  to be implemented
* <limits>  to be implemented
* "void (*foo) (void) throw ();"  causes a spurious error
* IIRC stringstreams and <sstream> were incomplete/missing

Anyone else who'se noticed an omission/incomplete thing/bug in C++ support
that isn't platform-dependent is welcome to add to the list.

>As for ETAs, in the free software world the only answer you will get is
>"when it's ready".

Or "when you do it yourself" right? <g>

I may be able to cobble together a draft of a working <valarray>. If I come
up with one amidst all the other work I'm doing on my own stuff, I'll be
sure to offer it here.

>See http://sourceware.cygnus.com/libstdc++/

OK

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Mike Stump]

> Date: Fri, 26 Feb 1999 01:25:13 -0500
> To: egcs@egcs.cygnus.com
> From: Paul Derbyshire <pderbysh@usa.net>

> At 03:32 PM 2/24/99 PST, you wrote:
> >You have already been informed that libstdc++ is not complete.  Sorry.

> The standard has been around in largely complete form for over a
> year, and finalized for many months. I am curious as to what is the
> cause for all of these omissions...

They are unimportant.  As to why they are unimportant, that is a
harder to answer question.  Basically it is a value judgement by all
the users of gcc/g++.

> I would love to help but I don't know the first thing about
> implementing these mathematical functions.

:-)  You could learn!

> In any case, to avoid any more unpleasant surprised I would like to
> see a list of all the omissions in the current libstdc++

Ok, sure, love to see the list when you get done with it.  Maybe you
could get it added to the website after you're done.

Re: Bug in libm or libstdc++.

[Joe Buck]

> At 03:32 PM 2/24/99 PST, you wrote:
> >You have already been informed that libstdc++ is not complete.  Sorry.
> 
> The standard has been around in largely complete form for over a year, and
> finalized for many months. I am curious as to what is the cause for all of
> these omissions...

Limited resources.  Up to now most resources have been concentrated on
completing the compiler portion of the standard, and we are very close.
The only significant unimplemented feature is "export".

> In any case, to avoid any more unpleasant surprised I would like to see a
> list of all the omissions in the current libstdc++ and other
> non-conformances, and where possible ETAs for the missing components.

If you would like to volunteer to assemble such a list, and do most of
the research yourself, you might find that others are willing to help.
If you continue to demand that others do work, you will probably just
create more hostility.

As for ETAs, in the free software world the only answer you will get is
"when it's ready".

> It
> would be a good idea to post a periodic libstdc++ progress report and calls
> for volunteers to implement some of the stuff. I think that might attract
> more developers to fixing up and finishing implementing the standard C++
> library.

See http://sourceware.cygnus.com/libstdc++/

> An area where I may be able to help is with the standard valarray and its
> friends, once I get back a response regarding making the compiler eliminate
> temporaries and excess copies in argument passing and return.

Again, see above.

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

At 03:32 PM 2/24/99 PST, you wrote:
>You have already been informed that libstdc++ is not complete.  Sorry.

The standard has been around in largely complete form for over a year, and
finalized for many months. I am curious as to what is the cause for all of
these omissions... I would love to help but I don't know the first thing
about implementing these mathematical functions.

In any case, to avoid any more unpleasant surprised I would like to see a
list of all the omissions in the current libstdc++ and other
non-conformances, and where possible ETAs for the missing components. It
would be a good idea to post a periodic libstdc++ progress report and calls
for volunteers to implement some of the stuff. I think that might attract
more developers to fixing up and finishing implementing the standard C++
library.

An area where I may be able to help is with the standard valarray and its
friends, once I get back a response regarding making the compiler eliminate
temporaries and excess copies in argument passing and return.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Paul Derbyshire]

>	Uhhh... if you're referring to page 660 (section 22.3)
>	it most certainly does not make any such guarantee with
>	regards to -long double- datatypes.

S22.3, page 661: "double atan (double) ..... In addition, <cmath> and
<math.h> supply these functions for float and long double arguments."

You're wrong, I'm right. Long double versions of atan and friends ARE
demanded by the standard. I would like to see them very soon so that I may
use them (the long double versions anyways) when I want that bit of extra
precision.......

>	at least on my box (sparc solaris), libm is vendor provided.

Not on an IBM PC clone, where it comes with the DJGPP/Cygwin/whatever
development environment you install. I installed the DJGPP/EGCS development
environment and got a broken libm.

>	gnu/include/g++/cmath -does- make reference to the math
>	functions that use long doubles for arguments, but I don't
>	think any library on my box actually supports them.

Then those libraries are broken and not conformant. I suggest you complain
to the vendor. You may also want to ask the bookstore where you got your
copy of Stroustrup for an exchange or a refund; I sure would have if my
copy had turned out to have pp. 661-662 torn out or missing.

Anyways, since these are function overloads in C++, I would expect the long
double and float versions to be in libstdc++, not libm. And libstdc++ comes
with gcc/egcs rather than being vendor supplied, on all platforms. If the
egcs libstdc++ is lacking long double overloads for atan and the like, then
this is a bug in egcs.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Bug in libm or libstdc++.

[Bob McWhirter]

On Mon, 22 Feb 1999, Paul Derbyshire wrote:

> C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
> c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
> `atan(long double)'
	
	[ snip ]

> What the hell?

	Is that -really- necessary?  Pipe down, already.

> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.

	Uhhh... if you're referring to page 660 (section 22.3)
	it most certainly does not make any such guarantee with
	regards to -long double- datatypes.

> Using egcs 1.1.1 and the libm and libstdc++ that came with it.

	at least on my box (sparc solaris), libm is vendor provided.

	gnu/include/g++/cmath -does- make reference to the math
	functions that use long doubles for arguments, but I don't
	think any library on my box actually supports them.

	Possibly there for platforms that do?  There for platforms
	that typedef a long double to be the same as a double?

	(nm'ing vendor's libm and stdc++ does not reveal math
	 functions taking long doubles, but possibly some other
	 lib I'm ignoring?  I did find math functions take
	 complex objects as arguments though.)

		-Bob

Re: Bug in libm or libstdc++.

[Joe Buck]

[ no "long double" overloads of math functions ]

> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.

You have already been informed that libstdc++ is not complete.  Sorry.

Bug in libm or libstdc++.

[Paul Derbyshire]

C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
`atan(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xa8):ntst.cc: undefined reference to
`exp(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xef):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x136):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x17d):ntst.cc: undefined reference to
`sqrt(long double)'

What the hell?

Stroustrup 3rd Ed definitely informs me that long double overloads for
these and other functions are supposed to be in either libm or libstdc++.

Using egcs 1.1.1 and the libm and libstdc++ that came with it.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|