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

> I'm not quite sure what you're driving at here. Why would Standard
> C++ say anything about Fortran? I'm talking about the ease of
> linking Fortran and C++ object code into a single application,
> something that is generally easy to do on most platforms. [...]

While I agree that there will be many programmers knowing how to mix
Fortran and C/C++ in _their_ applications there is no
platform/compiler independent way to achieve this goal in general.
This fact is clearly demonstrated by the -- over the years -- constant
traffic on comp.lang.fortran with discussions about C and Fortran
interoperability.  My understanding from these discussions and the
postings from people working on the Fortran standard is that the
present standards do not allow a platform independent way to entangle
Fortran and C code.  For the same reason the current draft on "Fortran
2000", which is the working name for scheduled revision of the Fortran
standard, has a chapter on its own on "Interoperability with C"
(http://www.j3-fortran.org/).

Karsten Chmielewski

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <fRuN7.135809$Yb.36257319@typhoon.tampabay.rr.com>, Scott Robert Ladd
says...
>
>"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote
>> Concretely, what does that mean to take "an object-oriented approach
>> to numerical programming"?
>
>A simple example: C99 and Fortran implement complex numbers as intrinsic
>(POD) types; C++ uses a class template. The C++ approach is likely a bit
>less efficient but more extensible and flexible.

?
Why would templates be less efficient? Once the compiler had replaced
(internally) complex<double> by complex$double { double real,img; } it
is as efficient as _Complex{ double real,img; }.

BTW, compiler vendors are already allowed to implement the std:: library
using intrinsics, if you can't notice it. complex<> looks like a prime
canidate for specializations.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote
> Could you point me to a normative text in the standard that say that
> you can mix Fortran and C++ code?

I'm not quite sure what you're driving at here. Why would Standard C++ say
anything about Fortran? I'm talking about the ease of linking Fortran and
C++ object code into a single application, something that is generally easy
to do on most platforms. This allows critical numerical code to be written
in Fortran and housekeeping code to be developed in C++. But I don't see why
Standard C++ would say anything about Fortran, any more than it needs to
talk about assembler language...

> Concretely, what does that mean to take "an object-oriented approach
> to numerical programming"?

A simple example: C99 and Fortran implement complex numbers as intrinsic
(POD) types; C++ uses a class template. The C++ approach is likely a bit
less efficient but more extensible and flexible.

I use my own real<> template in some of my work, which takes a template
argument defining the underlying type. For no practical cost in efficiency,
I gain the ability to switch between single and double precision (or
fixed-point, or BCD, or whatever) by changing a template argument. This is
similar to Fortran's "kind" capability.

C99 uses a function library to control precision, exception-handling, and
other characteristics of the floating-point system. I'd like to see
something like a "floating point model" class that encapsulates the complete
state of FP calculation.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd <scott@coyotegulch.com>...
> Hello, all.
>
> The U.S. Thanksgiving Holiday kept me busy, so this is the first
chance I've
> had to address issues of numerical programming in C++0X. Here's the
first
> set of points that come to mind:
>
> [Cut-n-pasted below...]
>
> Fire away, ladies and gentlemen.

Thanks,

> ...given the relative ease of intermixing Fortran and C++ code on most
> platforms, ... Do other topics require our focus?

Yes, but standards development appears to be a case of "whoever does the
work, sets the agenda", so if numerical experts step forward, we can
expect
numerical extensions to be considered.

> Will adding numerical capability draw more people to C++, or will
> Fortran people remain in Fortran?

My impression is that numerical experts and users both program in
whatever
language they know. The users in particular normally have "day jobs"
that
aren't much to do with programming. Since, as you point out, intermixing
is
quite easy, if non-portable, it surely doesn't matter who wins the
language
popularity contest.

Another factor is that many numerical algorithms are surprisingly low on
numerical work and relatively high on complicated housekeeping. C++ is
already better than Fortran for this, even if you can't quite get as
many
mega-flops on those inner loops.

Yet another factor is that those inner loops may well be written in
assembly
language in any case, at least for commercial libraries.

> the nature of C++ renders it ill-suited to some optimizations that
> can be performed on Fortran.

Are you thinking just of pointer aliasing here, or are there other
aspects?

> as a scientific programmer, I would like to have [C99 numerical
extensions]
> in C++0X. Lordy, would I love to have propagating Quiet NaNs...

Yes, it's about time the IEEE floating point features were available to
folks
other than assembly language hackers. Whilst we are in the area, might I
mention
interval arithmetic? If you have decent support for interval
calculations,
you don't need any of the C99 features, except perhaps NaNs.

> ...an extension to numeric_limits, for the identification of platform
> limitations at compile/run time.

The problem with numeric_limits<> is what to do if the answer is "no".
As
a rule, if you care enough to ask about IEEE, then you need it.

> In any event, such limited platforms are unlikely to be used for
numerical
> work.

Thinking out loud ...

How would people react if IEEE semantics were *required*, but floating
point support (including the types) were subsetted out of the language?

 * The embedded crowd would heave a sigh of relief and drop it. (They
probably
   have done already, but they could now stick "ISO standard" on their
compiler.)
 * The desktop and (modern) mainframe crowd would heave a sigh of
relief,
   because they already have it, but can now depend on it.
 * Those with C/C++ software targetting old mainframes with no IEEE
support would
   complain, because they'd have to use some sort of emulation, or just
offer
   their own floating point as an extension to the "embedded subset".

Since "C" and "old mainframes" are an uncommon combination, and since
any such
change would presumably take a few years to percolate through ISO, we
might get
away with it.

> C++ and C now follow different paths, and it is not practical -- or
wise --
> to require C++0X support C99 as a full subset.

I agree that the two languages now differ. C++ has demonstrated what you
can
do by torturing the compiler writers. C has responded by demonstrating
where
you can go (platform-wise, and I'm sure they'd mention verifiability
too)
by making their life easy. The two appear to be carving out separate
niches.

Another point is that unless the two committees share a timetable, there
will
never be a point when one language isn't "ahead of" the other. There's
not
much point in staying "as close as possible" if the gap is several years
wide.


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

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

> 1) Does C++ need to be Fortran?
>
> A good programmer uses the right tool for the job; given the relative ease
> of intermixing Fortran and C++ code on most platforms, is it necessary for
> C++ to match Fortran in numerical capability?

 I work on a project that absolutely needs C++ because of size and
 complexity; if we didn't have classes, templates, and such, we'd be
 lost.  OTOH, the project is fundamenally mathematical.  It'd be nice
 to have Fortran's run-time speed.

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
itftkd@home.com                     Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote
> Yes, but standards development appears to be a case of "whoever does the
> work, sets the agenda", so if numerical experts step forward, we can
> expect numerical extensions to be considered.

This is one reason I'm posting articles on the topic, because I've been told
in the past (by people in this newsgroup) that Standard C++ lacks strong
numerical support becasue there were no active numericists on the committee.

The lack of certain advocacies on the committee may be more a matter of
opportunity than desire. I'd love to participate in Standard C++, but
haven't the financial means to do so. The agenda (in any matter) tends to be
set by who can afford participation -- and those of us without personal
fortunes or corporate backers tend not to be heard. That's why I like
community-based standards over the officious sort... ;)

....and I much appreciate Bjarne's (and others') efforts at opening the
discussion to the C++ community at large.

> Another factor is that many numerical algorithms are surprisingly low on
> numerical work and relatively high on complicated housekeeping. C++ is
> already better than Fortran for this, even if you can't quite get as
> many mega-flops on those inner loops.

In most cases, it's less a matter of "mega-flops on... inner loops" than it
is in capability. Fortran supports a specific set of features that make
precise numerical computing easier, possible and portable. In most cases,
I'm more interested in capability and ease of expression over raw
performance.

The C99 extensions largely address the deficiencies of C++; in fact, in many
ways, C99 goes beyond Fortran, providing *better* numerical capabilities.
Standard C++ should work from the C99 base, which stems from many years of
experience and research. It doesn't make sense for Standard C++ to reinvent
the wheel, with all the attendant research and debate, when the C99 people
already did the functional analysis. What I'd like to see in C++ is an
objectified implementation of the C99 numerical extensions.

> > the nature of C++ renders it ill-suited to some optimizations that
> > can be performed on Fortran.
>
> Are you thinking just of pointer aliasing here, or are there other
> aspects?

I need to do a formal analysis of the current Standard C++ in terms of
numerical work, so people understand where the deficiencies lie.

> Yes, it's about time the IEEE floating point features were available to
folks
> other than assembly language hackers. Whilst we are in the area, might I
> mention interval arithmetic? If you have decent support for interval
> calculations, you don't need any of the C99 features, except perhaps NaNs.

Very true, on all points. Admittedly, not every architecture  implements
IEEE 754/IEC 559 -- but the vast majority of machines in use today *do*
deploy those standards.

> The problem with numeric_limits<> is what to do if the answer is "no".
> As a rule, if you care enough to ask about IEEE, then you need it.

True. What it gives you is a graceful way to say "This architecture is
inadequate for my work", or to use a less precise but more portable
algorithm. I have a few programs that "sense" their environment, and change
their behavior accordingly.

> How would people react if IEEE semantics were *required*, but floating
> point support (including the types) were subsetted out of the language?

I'll ponder this idea before responding in detail. I don't think we could
"extract" floating point into a separate standard, though...

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

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

[...]

| A good programmer uses the right tool for the job; given the relative ease
| of intermixing Fortran and C++ code on most platforms, is it necessary for
| C++ to match Fortran in numerical capability?

Could you point me to a normative text in the standard that say that
you can mix Fortran and C++ code?

[...]

| It may sound like a contradiction of my answer above, but I say *no*. C++
| should take an object-oriented approach to numerical programming.

Concretely, what does that mean to take "an object-oriented approach
to numerical programming"?

--
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://www.research.att.com/~austern/csc/faq.html                ]

Hello, all.

The U.S. Thanksgiving Holiday kept me busy, so this is the first chance I've
had to address issues of numerical programming in C++0X. Here's the first
set of points that come to mind:

1) Does C++ need to be Fortran?

A good programmer uses the right tool for the job; given the relative ease
of intermixing Fortran and C++ code on most platforms, is it necessary for
C++ to match Fortran in numerical capability? Do other topics we require our
focus? Will adding numerical capability draw more people to C++, or will
Fortran people remain in Fortran? Modern Fortran 95 is a very nice modular
language; the nature of C++ renders it ill-suited to some optimizations that
can be performed on Fortran.

2) Should C++ have the same abilities as C99?

My answer is an emphatic *yes*. The C99 numerical extensions provide for
precision and floating-point exception control, the standardization of NaNs
and infinities... as a scientific programmer, I would like to have these
features in C++0X. Lordy, would I love to have propagating Quiet NaNs...

Yes, I know that some platforms may not support NaNs and other such
capabilities; this is something that should be handled by an extension to
numeric_limits, for the identification of platform limitations at
compile/run time. In any event, such limited platforms are unlikely to be
used for numerical work.

3) Should C++ ape C99 exactly?

It may sound like a contradiction of my answer above, but I say *no*. C++
should take an object-oriented approach to numerical programming. Rather
than implement C99's Complex type, for example, the existing complex class
should be improved and extended. Many of the other C99 innovations could be
incorporated into the numeric_limits template.

C++ and C now follow different paths, and it is not practical -- or wise --
to require C++0X support C99 as a full subset.

Fire away, ladies and gentlemen.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]