Stephan K=E4mper <skaemper@physik.uni-bremen.de> writes:

| Scott Robert Ladd wrote:
| >=20
| > double angle =3D acos(2.0); // angle should =3D=3D NaN
| >=20
|=20
| Hmmm. IMHO acos(2.0) should equal to a complex (infact imaginary) value=
 of
| (approx.)
| 0 + i * 1.31695789 resp. (0, 1.31695789)

Well, actually LIA-III (whose first draft is expected by the end of
September) is trying to codify such things.  I will be glad to see
joint work with WG21 to produce a reliable and acceptable binding for
C++.=20

Anyway, the C++ definition does not require LIA conformance.

--=20
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
>
> double angle = acos(2.0); // angle should == NaN
>

Hmmm. IMHO acos(2.0) should equal to a complex (infact imaginary) value of
(approx.)
0 + i * 1.31695789 resp. (0, 1.31695789)




--
Stephan Kaemper                     Mail: skaemper@physik.uni-bremen.de
Universitaet Bremen / FB 1          Tel.: (49) 421 / 218-2931
Abt. Tracer-Ozeanographie           Fax.: (49) 421 / 218-7018
Postfach 330440
D-28334 Bremen / Germany                  |    |    |
                                         )_)  )_)  )_)
                                        )___))___))___)\
                                       )____)____)_____)\\
                                     _____|____|____|____\\\__
                            ---------\                   /---------
                               ^^^^^ ^^^^^^^^^^^^^^^^^^^^^
                                ^^^^      ^^^^     ^^^    ^^
                                     ^^^^      ^^^
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qh0s8$2q05$1@hardcore.ivn.net>, Scott Robert Ladd
<scott@coyotegulch.com> writes
>I would love to be part of the C++ Committee -- but I'm just a poor ol'
>writer and consultant, without a big company to pay my way. See, I got these
>three kids to feed, and a wife, and a guinea pig, and a grumpy old truck...

And I am a retired school teacher, but if you are serious you can find
the money.  As an author the knowledge you will gain will seriously
improve your work.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qh0ev$2po4$1@hardcore.ivn.net>, Scott Robert Ladd
<scott@coyotegulch.com> writes
>The more I think about it, the more I wonder if it is at all practical to
>maintain "as close to C, but no closer." I have a feeling the "closeness" of
>the two languages is going to be an ever-widening gap.

I may have a minority view but I do not find that disturbing.  Both C
and C++ should very substantial weight to retaining compatibility with
C89.  Neither should gratuitously introduce incompatibilities with the
current version of the other.  I think the current scheme for having at
least one meeting a year at the same place and with contiguous or
overlapping timing will prove to be very beneficial.  I hope that each
group of experts will respect the expertise and goodwill of the other
(and those that do not already feel that way will learn better)



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stephan K   mper <skaemper@physik.uni-bremen.de> wrote...
> Hmmm. IMHO acos(2.0) should equal to a complex (infact imaginary) value of
> (approx.) > 0 + i * 1.31695789 resp. (0, 1.31695789)

Unfortunately, C (and thus C++ and Java) did not define an intrinsic complex
type. Lack of an intrinsic complex is a serious hole in the C family of
languages.

You can get around this limitation by performing your calculations using the
methods defined by complex<>. However, the standard complex<> lacks
inversion trigonometric functions, among other useful methods. Sigh... I
really need to join that committee.

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qoqd2$nkd$1@hardcore.ivn.net>, Scott Robert Ladd
<scott@coyotegulch.com> writes
>You can get around this limitation by performing your calculations using the
>methods defined by complex<>. However, the standard complex<> lacks
>inversion trigonometric functions, among other useful methods. Sigh... I
>really need to join that committee.

Well the next meeting is in Hawaii in October, and the Ironman contest
is taking place at the same time:)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qh0s8$2q05$1@hardcore.ivn.net>,
  "Scott Robert Ladd" <scott@coyotegulch.com> wrote:

> Steve Clamage <clamage@eng.sun.com> wrote...
> > We had only one person on the C++ committee who was expert in
> > numerical programming, and his employer withdrew support for
> > his continuing on the committee after a relatively short time.
> > With no one on the committee having sufficient expertise, and with
> > no support from organizations that might have wanted good
> > numerical support in C++, there was little we could do.

> I would love to be part of the C++ Committee -- but I'm just a poor
> ol' writer and consultant, without a big company to pay my way. See, I
> got these three kids to feed, and a wife, and a guinea pig, and a
> grumpy old truck...

It's not that expensive, around $1000 a year in America, I think.
[ moderator's note: US $600 per year membership fee. See the FAQ. -sdc ]

(Formally, the only members of the ISO committee are the national
bodies. You get to participate by becoming a member of one of the
national bodies. And each national body sets its own rules.)

> In this day and age of telecommunications, it seems to me that
> Standards could be defined without face-to-face meetings. It would
> certainly make international standards easier to work on. Yes, I
> understand that membership fees help pay for the committee process --
> but right now, most of the people involved are big companies with big
> agendas. The scientific and numeric community isn't quite that
> wealthy.

You can participate a lot without attending the meetings.

A lot of members *are* small organizations or individuals.  Some are
even students, on a student's budget.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrew Koenig <ark@research.att.com> wrote...
> The committee did not want to adopt numerical extensions and then
> have C9X do something different.  The only way to avoid doing so
> was not to adopt them, under the assumption that once C9X is complete,
> C++ vendors will start implementing C9X numerics as extensions to C++.

Thanks for the clarification.

The more I think about it, the more I wonder if it is at all practical to
maintain "as close to C, but no closer." I have a feeling the "closeness" of
the two languages is going to be an ever-widening gap.

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

> Francis Glassborow <francis@robinton.demon.co.uk> wrote...
> > You mean that the C++ Standard should mandate that divide by zero will
> > throw an exception?  I would be very unhappy if it did.  Some systems
> > support NaNs and divide by zero should generate a NaN on such a system.
>
> Mathematically incorrect. Division by zero should generate an INFINITY, not
> a NaN. Mathematics clearly defines division by zero in this fashion. A NaN
> should be the result of any non-sensical mathematical operation, such as
> whentaking this inverse cosine of a value greater than 1:
>
> double angle = acos(2.0); // angle should == NaN
>
> I note that the revised C9X (C0X?) standard and Java handle this correctly.
>
> What is the future direction of Standard C++ in regard to these issues (if
> any)?

None, so far as I know.  With SGI's C++ compiler (using MIPS/IRIX),
dividing a positive floating-point number by zero does indeed give
Inf; I expect that the same is true on most of the other popular
platforms of today.  Mandating that in a standard, though, would be
tricky, since not all hardware platforms support IEEE754
floating-point arithmetic.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

>As someone who develops mathematical applications, I am disappointed by the
>lack of strong numerical support in Standard C++. While it appears that C9X
>will include vastly improved mathematical facilities, I have no idea what
>(if any) plans are underway to improve C++'s arithmetic.

We had only one person on the C++ committee who was expert in
numerical programming, and his employer withdrew support for
his continuing on the committee after a relatively short time.
With no one on the committee having sufficient expertise, and with
no support from organizations that might have wanted good
numerical support in C++, there was little we could do.

That is, you don't want amateurs defining numerics, and we had
no competent professionals available. We asked. No one came.

>Back in 1991, the Numerical C Extensions Group (NCEG) had developed a set of
>C extensions, some of which appear to be part of C9X. Zortech C++ (now a
>near-defunct Symantec product) implemented those extensions; did the
>Standard C++ committee (finished seven years later) consider implementing
>any of this?

Yes, but the timing worked against including any of it in the C++
standard. It was not until after the C++ standard was published
that the C committee made final decisions about what NCEG work to
include in the C standard. Anything the C++ committee could have
adopted from the NCEG work would certainly have wound up
conflicting with whatever the C committee did. We decided not to
try to extend C ourselves, but wait for the C committee to finish
their work. (That's also why C++ does not define type "long long",
for example.)

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <clamage@eng.sun.com> wrote...
> We had only one person on the C++ committee who was expert in
> numerical programming, and his employer withdrew support for
> his continuing on the committee after a relatively short time.
> With no one on the committee having sufficient expertise, and with
> no support from organizations that might have wanted good
> numerical support in C++, there was little we could do.

I would love to be part of the C++ Committee -- but I'm just a poor ol'
writer and consultant, without a big company to pay my way. See, I got these
three kids to feed, and a wife, and a guinea pig, and a grumpy old truck...

In this day and age of telecommunications, it seems to me that Standards
could be defined without face-to-face meetings. It would certainly make
international standards easier to work on. Yes, I understand taht membership
fees help pay for the committee process -- but right now, most of the people
involved are big companies with big agendas. The scientific and numeric
community isn't quite that wealthy.

> That is, you don't want amateurs defining numerics, and we had
> no competent professionals available. We asked. No one came.

Well, C/C++ isn't the first choice of many numerical people; witness the
continued popularity of FORTRAN, for example. I know I do a bit of FORTRAN
work still, just because some of my clients still use it. We may have a
self-fulfilling prophesy here -- C isn't thought of as a numerical language,
so numerical programmers don't use it, which means that C/C++ never gains
important numerical capabilities.

Just a thought.

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

As someone who develops mathematical applications, I am disappointed by the
lack of strong numerical support in Standard C++. While it appears that C9X
will include vastly improved mathematical facilities, I have no idea what
(if any) plans are underway to improve C++'s arithmetic.

Back in 1991, the Numerical C Extensions Group (NCEG) had developed a set of
C extensions, some of which appear to be part of C9X. Zortech C++ (now a
near-defunct Symantec product) implemented those extensions; did the
Standard C++ committee (finished seven years later) consider implementing
any of this?

>From the discussion about divide by zero and exceptions:

Francis Glassborow <francis@robinton.demon.co.uk> wrote...
> You mean that the C++ Standard should mandate that divide by zero will
> throw an exception?  I would be very unhappy if it did.  Some systems
> support NaNs and divide by zero should generate a NaN on such a system.

Mathematically incorrect. Division by zero should generate an INFINITY, not
a NaN. Mathematics clearly defines division by zero in this fashion. A NaN
should be the result of any non-sensical mathematical operation, such as
whentaking this inverse cosine of a value greater than 1:

double angle = acos(2.0); // angle should == NaN

I note that the revised C9X (C0X?) standard and Java handle this correctly.

What is the future direction of Standard C++ in regard to these issues (if
any)?

--
  *     Scott Robert Ladd
  *
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]