And Gabriel Dos Reis writes:
 - > To all the language implementors:  Please support the C9X extensions
 - > dealing with IEEE 754 arithmetic in C++.  Please.  Pretty please.
 -
 - which ? The experimental ones ?

Yes, I mean the experimental names used to access the features of the
13-year-old IEEE 754 standard.  Things like NAN, INFINITY, etc.  I
realize those names may change, but I tend to think they're pretty
close to the final names.

The names of the fenv_t accessors probably aren't as stable, but the
underlying functionality has been in most processors for a little
while (just say no to Cray vector machine arithmetic).  The pragma
names are, well, pragma names.  Not much chance of collision in that
namespace, so I kinda think they're done.

Basically, the names may change, but the functionality won't.  Some
may get added, but from my moderately quick overview of the draft I
don't think any functionality will be removed.

 - Surely not OOP for those so concrete types.

I'm not at all sure what your objection is to object wrappers around
concrete types, which is what I mentioned...  That's pretty common,
hence the vector<> wrapper around a chunk of memory.

Things like the floating-point environment seem have the potential to
be wrapped in an object in a very useful way.  The FPU's current
settings could be wrapped in a special object.  You could change
flush-to-zero, etc. with methods.  Assigning the special object to an
object of type std::fenv (not a good name) would save all the
settings.  Assigning the other object back to the special object would
restore the settings.

While inheritance and other OOP properties are fairly useless here
(well, inheritance as more than aggregation), an object wrapper would
make the code look more C++-ish.  Hence, it would be more accepted by
C++ coders.

 - My impression is that people involved in numerics are waiting for other
 - people to do their works for them.

My impression of such people involved in numerics as Dr. William
Kahan, etc. is that they are not compiler writers.  They are much more
interested in solving numeric problems than the symbolic problems in
compiler writing.  They work on writing the numerical standards.  They
work on developing the algorithms used in hardware.  I think you're
short-changing them a bit...

I happen to be interested in both numerics and compilation, but I'm
quite strapped for time.  I've slowly been figuring out chunks of the
gcc source, but I do not yet understand enough comment intelligently
on improving numeric support.

 - Please do get involved in discussion on OONSTD and submit projects.

I keep an eye on the archives.  I also work for Dr. Demmel, one of the
BLAS authers / designers, and have been commenting on the BLAST
proposals.

And I'm on way too many mailing lists already.  ;)

Jason


[ 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              ]

>>>>> =ABJason=BB, E Jason Riedy <ejr@cise.ufl.edu> wrote:

[ stuff on IEE 754 ]

Jason>  - Surely not OOP for those so concrete types.

Jason> I'm not at all sure what your objection is to object wrappers arou=
nd
Jason> concrete types, which is what I mentioned...  That's pretty common=
,
Jason> hence the vector<> wrapper around a chunk of memory.


Well, vector<> is an abstract data type. And objects (in C++ parlance)
of type vector<> have little to do with objects in OOP parlance.


[...]


Jason> While inheritance and other OOP properties are fairly useless here
Jason> (well, inheritance as more than aggregation), an object wrapper wo=
uld
Jason> make the code look more C++-ish.  Hence, it would be more accepted=
 by
Jason> C++ coders.

Sure.

Jason>  - My impression is that people involved in numerics are waiting f=
or other=20
Jason>  - people to do their works for them.

Jason> My impression of such people involved in numerics as Dr. William
Jason> Kahan, etc. is that they are not compiler writers.  They are much =
more
Jason> interested in solving numeric problems than the symbolic problems =
in
Jason> compiler writing.  They work on writing the numerical standards.  =
They
Jason> work on developing the algorithms used in hardware.  I think you'r=
e
Jason> short-changing them a bit...

I'm not a compiler writer. I came to be interested in numerics and how
compilers deal with them because I could no longer accept (mathematical)
assertions like : "it's theorically possible possible to do this."
Without any clue. Note: I'm not blaming Dr. Kahan -- I come from
Geometry, not numerical analysis.


Jason> I happen to be interested in both numerics and compilation, but I'=
m
Jason> quite strapped for time.  I've slowly been figuring out chunks of =
the
Jason> gcc source, but I do not yet understand enough comment intelligent=
ly
Jason> on improving numeric support.

Jason>  - Please do get involved in discussion on OONSTD and submit proje=
cts.

Jason> I keep an eye on the archives.  I also work for Dr. Demmel, one of=
 the
Jason> BLAS authers / designers, and have been commenting on the BLAST
Jason> proposals. =20

Jason> And I'm on way too many mailing lists already.  ;)

:-) We all get busy.

--=20
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ 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              ]

ejr@cise.ufl.edu (E. Jason Riedy) writes:

>To all the language implementors:  Please support the C9X extensions
>dealing with IEEE 754 arithmetic in C++.  Please.  Pretty please.

>To the language specifiers: Please seriously consider it for the next
>revision of C++.

The schedule for the C++ standard (which was quite late
anyway) precluded incorporating new features of C9X, which
is still in development. (I know you didn't ask why C++
doesn't have the features already, but it's worth mentioning
explicitly. It would not have been a good idea to adopt into
C++ something that the C committee was still modifying.)

It has always been the goal of C++ to be as compatible as
possible with C. I would expect the next round of C++
standardization to incorporate as many features of C9X as are
compatible with C++. (We have liaison members on each committee
who try to keep incompatibilities to a minimum.)

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

>>>>> E Jason Riedy <ejr@cise.ufl.edu> =E9crit :

> To all the language implementors:  Please support the C9X extensions
> dealing with IEEE 754 arithmetic in C++.  Please.  Pretty please.


which ? The experimental ones ?


> To the language specifiers: Please seriously consider it for the next
> revision of C++...  If you start considering early enough, you can
> make nice OOP wrappers for some of it and actually stand a change of

Surely not OOP for those so concrete types.

> coders using those rather than the straight C9X bits.  (Take care with
> floating- point exceptions, however.  They are more like signals than
> like C++ exceptions...)

> While the C9X stuff isn't perfect, it's a _lot_ better than what we
> have now.  There may not be much hope for the C++ complex class, but
> at least the fenv.h and new math.h stuff can come into the standard.

> The excuse for not improving numerics is often the lack of demand.
> Well, here's some demand.  If you need more demand, I can go find it.
> Other people may say it's bulky junk about which they don't care.
> However, people who do care _must_ have it, or must fall into using
> assembler (back to the original topic).


The OON mailing list

 http://monet.uwaterloo.ca/oon/

is very *sporadic*. My impression is that people involved in numerics are
waiting for other people to do their works for them.=20

Please do get involved in discussion on OONSTD and submit projects.

-- Gabriel


[ 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<stephen.clamage@sun.com> wrote:
>ejr@cise.ufl.edu (E. Jason Riedy) writes:
>
>>To all the language implementors:  Please support the C9X extensions
>>dealing with IEEE 754 arithmetic in C++.  Please.  Pretty please.
>
>... It has always been the goal of C++ to be as compatible as
>possible with C. I would expect the next round of C++
>standardization to incorporate as many features of C9X as are
>compatible with C++. (We have liaison members on each committee
>who try to keep incompatibilities to a minimum.)

It will be interesting to try to adopt the C complex support into
the C++ standard.  Ironically, for a verbatim adoption the greatest
obstruction is the proposed name "clog".  The name std::clog is
already defined in the C++ standard, so people who like to say
"using namespace std" will get amusing results if they also include
the C9x header.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]

Oh well.  And Francis Glassborow  <francis@robinton.demon.co.uk> writes:
 -
 - It is instructive to look at the work done on C9X.

Speaking of which...

To all the language implementors:  Please support the C9X extensions
dealing with IEEE 754 arithmetic in C++.  Please.  Pretty please.

To the language specifiers: Please seriously consider it for the next
revision of C++...  If you start considering early enough, you can
make nice OOP wrappers for some of it and actually stand a change of
coders using those rather than the straight C9X bits.  (Take care with
floating- point exceptions, however.  They are more like signals than
like C++ exceptions...)

While the C9X stuff isn't perfect, it's a _lot_ better than what we
have now.  There may not be much hope for the C++ complex class, but
at least the fenv.h and new math.h stuff can come into the standard.

The excuse for not improving numerics is often the lack of demand.
Well, here's some demand.  If you need more demand, I can go find it.
Other people may say it's bulky junk about which they don't care.
However, people who do care _must_ have it, or must fall into using
assembler (back to the original topic).

Jason



[ 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              ]