New C Standard Lures Fortran Users
Ivan frohne
There is an interesting article on the new C (not C++)
standard by Dr. P. J. Plauger in the May 1998 "Embedded
Systems Programming." Plauger, a sometime physicist,
compiler developer and author, now writes
C and C++ standard libraries and so keeps on top of
new developments.
The new C standard, due in 1999, will offer numerous minor
improvements, "and a whole bunch of stuff for numeric
computation," says Dr. Plauger. Later he notes that
"...[these] changes in Standard C reflect an obvious
desire to lure more programmers away from Fortran."
There will be a new pointer type qualifier to make C
compilers more competitive with Fortran in vector
processing applications. Variable length arrays will
be permitted in some circumstances. There is
built-in complex arithmetic, in three precessions --
float (4-byte), double (8-byte) and long double (10-byte).
There are signed and unsigned 64-bit integers.
Initialization procedures for structures have been
improved. There are new pragmas to control rules
for floating point arithmetic.
"By far the biggest change, however, occurs in
the header <math.h>,which is now awash with
added math functions...functions [for types long
and long double] are now all mandatory. But the
set has been rounded out aggressively to include
esoterica such as asinh ... in all three precisions
along with three more complex variants."
There is also a log1p() function, to calculate log(1+x)
accurately when x is close to 1. And there are many
new seminumerical functions, "like the next representable
floating point number in sequence, for example."
One final point of interest is that, while Dr. Plauger
plumped for the inclusion of some of the object-
oriented features of C++, "...such proposals died for
lack of support."
--Ivan Frohne
Ron Shepard
In article <HkB81.1$AZ4....@binary.alaska.net>, "Ivan frohne"
<fro...@alaska.net> wrote:
[...]
>There will be a new pointer type qualifier to make C
>compilers more competitive with Fortran in vector
>processing applications. Variable length arrays will
>be permitted in some circumstances. There is
>built-in complex arithmetic, in three precessions --
>float (4-byte), double (8-byte) and long double (10-byte).
>There are signed and unsigned 64-bit integers.
>Initialization procedures for structures have been
>improved. There are new pragmas to control rules
>for floating point arithmetic. [...]
Sounds interesting. Is "i/j" now well-defined when integers "i" or "j" or
both are negative? Are arrays always zero-based, or can the programmer
define them as appropriate to the problem? If not, then the new C may not
even give F77 any competition for science/engineering applications.
$.02 -Ron Shepard
Peter Shenkin
Ron Shepard wrote:
>
> In article <HkB81.1$AZ4....@binary.alaska.net>, "Ivan frohne"
> <fro...@alaska.net> wrote:
>
> [...]
> >There will be a new pointer type qualifier to make C
> >compilers more competitive with Fortran in vector
> >processing applications. Variable length arrays will
> >be permitted in some circumstances. There is
> >built-in complex arithmetic, in three precessions --
> >float (4-byte), double (8-byte) and long double (10-byte).
> >There are signed and unsigned 64-bit integers.
> >Initialization procedures for structures have been
> >improved. There are new pragmas to control rules
> >for floating point arithmetic. [...]
>
> Sounds interesting. Is "i/j" now well-defined when integers "i" or "j" or
> both are negative?
This has always been well-defined in C; it's i%j (the modulo function)
that was not, and, as far as I know, still is not. Also, the direction
of truncation of i=a/b (int i; float a,b) is undefined if a/b is
negative.
> ... Are arrays always zero-based
Yes.
> ..., or can the programmer
> define them as appropriate to the problem? If not, then the new C may not
> even give F77 any competition for science/engineering applications.
I see nothing in mathematical programming (or sci/eng apps) which
make index-origin 1 better than 0 for this purpose. It's just a
slightly different idiom. And if you use dynamically allocatable
arrays, you can make them index-origin 1, if you wish, at the risk
of violating the standard, but with a very small risk of problems
occurring. This has always been true.
-P.
--
*********** How can we have ethnic music without ethnic hatred?
***********
* Peter S. Shenkin; Chemistry, Columbia U.; 3000 Broadway, Mail Code
3153 *
** NY, NY 10027; she...@columbia.edu; (212)854-5143; FAX: 678-9039
***
*MacroModel WWW page:
http://www.columbia.edu/cu/chemistry/mmod/mmod.html *
William Clodius
Peter Shenkin wrote:
> <snip>
> > Sounds interesting. Is "i/j" now well-defined when integers "i" or "j" or
> > both are negative?
>
> This has always been well-defined in C; it's i%j (the modulo function)
> that was not, and, as far as I know, still is not. Also, the direction
> of truncation of i=a/b (int i; float a,b) is undefined if a/b is
> negative.
I believe integer division has not always been well defined for negative
operands, whether or not they are floats. See "The C Programming
Language" 2nd Ed, section 2.5. I suspect that simply because all (almost
all) processors implement Fortran's rules in hardware, C integer
division has been portable. The plan is to adopt Fortran's rules for
C9x, although many mathematicians prefer the opposite rounding
direction.
>
> > ... Are arrays always zero-based
>
> Yes.
>
> > ..., or can the programmer
> > define them as appropriate to the problem? If not, then the new C may not
> > even give F77 any competition for science/engineering applications.
>
> I see nothing in mathematical programming (or sci/eng apps) which
> make index-origin 1 better than 0 for this purpose. It's just a
> slightly different idiom. And if you use dynamically allocatable
> arrays, you can make them index-origin 1, if you wish, at the risk
> of violating the standard, but with a very small risk of problems
> occurring. This has always been true.
> <snip>
The question was not 1 based versus zero based, but user defined versus
fixed. There are fencepost problems that are less error prone to write
if 0 origin and 1 origin arrays are both available, and I have had some
problems that were easier with some arrays indexed from -N to N.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
Ron Shepard
In article <35634A...@still3.chem.columbia.edu>, Peter Shenkin
<she...@still3.chem.columbia.edu> wrote:
>> Sounds interesting. Is "i/j" now well-defined when integers "i" or "j" or
>> both are negative?
>
>This has always been well-defined in C; it's i%j (the modulo function)
>that was not, and, as far as I know, still is not.
I believe that both integer division and the modulo function are not
well-defined, at least in part, for the same reasons. In C, the
expression (-3/2) can evaluate either to -1 or to -2, it is left up to the
compiler. Integer division and the modulo functions must be coupled
together however, so that the relation i==(i/j)*j+i%j is always
satisfied. So depending on whether integer division happens to round up
or down for the two operands, the modulo result can be either positive or
negative accordingly.
Also, according to the way the C (89) standard is written, the only
integer division operation that is well defined is when both the numerator
and the denominator are positive. The other three combinations (+/-, -/+,
and surprisingly -/-) are all allowed this ambiguity.
In fortran, the same expression (with mod()) must be satisfied, but
integer division is defined to always round towards zero, so there is no
ambiguity. And if you want the other modulus function, that always
returns the same sign as the integer denominator, it is there too:
modulo().
>Also, the direction
>of truncation of i=a/b (int i; float a,b) is undefined if a/b is
>negative.
I had missed this one. ;-)
>> ... Are arrays always zero-based
>
>Yes.
>
>> ..., or can the programmer
>> define them as appropriate to the problem? If not, then the new C may not
>> even give F77 any competition for science/engineering applications.
>
>I see nothing in mathematical programming (or sci/eng apps) which
>make index-origin 1 better than 0 for this purpose.
It's not, of course, but in fortran (F77 even) the programmer can define
whatever lower bound he wants that best matches the problem.
>It's just a
>slightly different idiom. And if you use dynamically allocatable
>arrays, you can make them index-origin 1, if you wish, at the risk
>of violating the standard, but with a very small risk of problems
>occurring. This has always been true.
Yes, I know the trick, but I have always thought it should be
unnecessary. And multi-D arrays are a problem too. Fortran does this the
right way, for example
integer array(-123:456),
and has done it this way for two decades now. My point was that the new C
standard still hasn't caught up with even this simple stuff.
In many ways I like C, it is flexible, and because it has a standard
preprocessor, it is straightforward to write portable, yet
machine-dependent, code. But when you really want to do something with
it, you have to struggle against all these little oddities.
$.02 -Ron Shepard
Greg Lindahl
Peter Shenkin <she...@still3.chem.columbia.edu> writes:
> Ron Shepard wrote:
[...]
> > ..., or can the programmer
> > define them as appropriate to the problem? If not, then the new C may not
> > even give F77 any competition for science/engineering applications.
>
> I see nothing in mathematical programming (or sci/eng apps) which
> make index-origin 1 better than 0 for this purpose. It's just a
> slightly different idiom. And if you use dynamically allocatable
> arrays, you can make them index-origin 1, if you wish, at the risk
> of violating the standard, but with a very small risk of problems
> occurring. This has always been true.
A delicious mistake -- Ron never said anything about 1, he said
"appropriate to the problem". Modern Fortran allows any base. What the
default is is a separate issue.
-- g
John Rowe
Fantastic! Is there a URL for any of this?
John
Carsten Arnholm
Ron Shepard <she...@tcg.anl.gov> wrote in article
<shepard-2005...@macrls.tcg.anl.gov>...
[snip ]
>
> Yes, I know the trick, but I have always thought it should be
> unnecessary. And multi-D arrays are a problem too. Fortran does this
the
> right way, for example
>
> integer array(-123:456),
>
> and has done it this way for two decades now. My point was that the new
C
> standard still hasn't caught up with even this simple stuff.
>
> In many ways I like C, it is flexible, and because it has a standard
> preprocessor, it is straightforward to write portable, yet
> machine-dependent, code. But when you really want to do something with
> it, you have to struggle against all these little oddities.
>
What you need is C++, not C or C9x, because
1. If you want to, you can use C++ as a "better C" (read Bjarne
Stroustrup's 3rd edition to learn more)
2. You have standard container classes (STL - Standard Template Library,
part of ISO C++) that are as efficient, and much more flexible than C or
Fortran arrays.
3. You have full support for object orientation, if you need it.
4. You have support for generic programming (templates), if you need it.
This can be used in a surprising number of ways, see for example
http://monet.uwaterloo.ca/blitz/ where a C++ class library is presented,
which "provides performance on par with Fortran 77/90".
5. C++ mixes very well with Fortran, even _better_ than C. see
http://home.sol.no/~arnholm/cppf77.htm for details.
What more would you require ?
--
Carsten Arnholm
arn...@online.no
http://home.sol.no/~arnholm/
Greg Lindahl
"Carsten Arnholm" <arn...@online.no> writes:
> 2. You have standard container classes (STL - Standard Template Library,
> part of ISO C++) that are as efficient, and much more flexible than C or
> Fortran arrays.
We have now degenerated in the usual meaningless langauge drivel.
I've used STL. It is not at all useful for replacing a lovely, simple
thing such as a Fortran array. It is far harder to learn and far more
powerful. You may find it to be a good tool, but few scientific
programmers find C++ obvious.
So much for holding an interesting discussion about the new C
standard.
-- g
Clive Page
In article <01bd84fa$38162df0$32094382@rustad1>,[snip]
>What more would you require ?
(1) A language that ordinary scientists (like me) can use properly
without having to spend 6 months learning it (even enthusiasts for C++
admit that something like that period is needed to get the hang of it).
(2) A language which lets me name my own operators, so I can write things
like:
if(string .like. "a?b*") then
or even
new_set = old_set .union. another_set
(3) A language with a syntax which makes
if(x = y)
when I meant
if(x == y)
an error rather than a valid (if useless) statement.
No doubt others can add lots more reasons. But that'll do for now. :-)
--
--
Clive Page,
Dept of Physics & Astronomy,
University of Leicester.
Craig Burley
Clive Page <c...@nospam.le.ac.uk> writes:
> In article <01bd84fa$38162df0$32094382@rustad1>,
> Carsten Arnholm <arn...@online.no> wrote:
> >
> >What you need is C++, not C or C9x, because
> [snip]
> >What more would you require ?
[...]
> No doubt others can add lots more reasons. But that'll do for now. :-)
I'll add two obvious ones:
- A language with a binary infix operator that means "concatenate", like
Fortran's `//'.
- A language with a binary infix operator that means "power", like
Fortran's `**'.
Plus a not-so-obvious one:
- A language with binary infix operators having the ordinary meanings
of "and" and "or", like Fortran's `.AND.' and `.OR.'.
--
"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson bur...@gnu.org
Ron Shepard
>What you need is C++, not C or C9x, because [...]
Perhaps I didn't mention this before, but the "i/j" ambiguity is in C++ too.
$.02 -Ron Shepard
Kenneth G. Hamilton
Craig Burley <bur...@tweedledumb.cygnus.com> writes:
>- A language with binary infix operators having the ordinary meanings
> of "and" and "or", like Fortran's `.AND.' and `.OR.'.
Peter Shenkin
Craig Burley
Heh, well, I wasn't referring to the readability. I don't find
C's short-cut or bitwise operators particularly unreadable, once
they're gotten used to, for example.
Then again, one of my early "languages" was TECO. ;-)
I would just love to write my compiler and other projects in a
language that had real AND/OR operators like Fortran does. But C
is doing okay for the time being.
Seems to me most numeric work benefits from having real AND/OR
operators as well, instead of what C/C++ forces you to specify,
which amounts to an implementation decision the Fortran programmer
often doesn't care to make.
tyd...@tybor.com
>Sounds interesting. Is "i/j" now well-defined when integers "i" or "j" or
i/j is now well defined in C9X to be truncate toward zero
(which I believe is the same as Fortran).
>define them as appropriate to the problem? If not, then the new C may not
>even give F77 any competition for science/engineering applications.
>
>$.02 -Ron Shepard
---
Fred J. Tydeman +1 (512) 255-8696 Tydeman Consulting
3711 Del Robles tyd...@tybor.com Programming, testing, numerics
Austin, Texas 78727 Voting member of X3J11 (ANSI "C")
USA Sample C9X+FPCE tests: ftp://jump.net/pub/tybor
Carsten Arnholm
Greg Lindahl <lin...@pbm.com> wrote in article
<6k254p$e...@news1.newsguy.com>...
> "Carsten Arnholm" <arn...@online.no> writes:
>
> > 2. You have standard container classes (STL - Standard Template
Library,
> > part of ISO C++) that are as efficient, and much more flexible than C
or
> > Fortran arrays.
>
> We have now degenerated in the usual meaningless langauge drivel.
Meaning: I don't know what to say anymore.
>
> I've used STL. It is not at all useful for replacing a lovely, simple
> thing such as a Fortran array. It is far harder to learn and far more
> powerful.
Meaning: I never bothered to read the manual, and I could not quite figure
it out.
> You may find it to be a good tool, but few scientific
> programmers find C++ obvious.
I have done professional FORTRAN 77 programming for 15 years (Finite
Element Method + related stuff). It became obvious to me that the language
was not expressive enough. Scientists and engineers do other things besides
numerics (actually, they do relatively little numerics). Most non-trivial
applications do much more general information management than pure
numerics. Fortran is a poor tool for such work. OO and C++ is great in that
area. I am not a language fanatic. If I was, I would not have developed a
technique for calling F77 from C++, and I would not have made it public at
http://home.sol.no/~arnholm/cppf77.htm
Sometimes Fortran is the right tool, sometimes C++ is the right tool. Why
not take the best from two worlds ?
>
> So much for holding an interesting discussion about the new C
> standard.
Sounds like you are interested in your own viewpoints. period.
>
> -- g
Jose Miguel Perez
Carsten Arnholm wrote:
> Greg Lindahl <lin...@pbm.com> wrote in article
> <6k254p$e...@news1.newsguy.com>...
> > "Carsten Arnholm" <arn...@online.no> writes:
> >
> > > 2. You have standard container classes (STL - Standard Template
> Library,
> > > part of ISO C++) that are as efficient, and much more flexible than C
> or
> > > Fortran arrays.
> >
> > We have now degenerated in the usual meaningless langauge drivel.
>
> Meaning: I don't know what to say anymore.
>> > I've used STL. It is not at all useful for replacing a lovely, simple
>> > thing such as a Fortran array. It is far harder to learn and far more
>> > powerful.
>>
>> Meaning: I never bothered to read the manual, and I could not quite figure
>> it out.
>
I don't consider the STL a substitute to a simple numeric array object
in Fortran, neither in its efficiency nor on its easy of use.
To provide one example: the STL does not provide multidimensional arrays
but in the form of valarrays ( not implemented in all
c++ either), which has to be extended to make it as useful as in fortran.
Stroustrup remarks on his book seems to agree with this.
He shows some tricks using templated operators to avoid
redundant creations of temporary arrays during operations, effectively
doing the compilers work by hand.
The blitz library uses something similar to this (among other things)
to obtain code which is finally 'as efficient as fortran code'.
Unfortunately, not all compilers can handle the aggressive use of
templates by the blitz library.
Sorry, but if c++ designers would have had numerical computation in mind
(which they explicitly say they did not), they would have better provisions
for this.BTW, not to fight anyone elses battles, but these two comments were
not called for!
> > You may find it to be a good tool, but few scientific
> > programmers find C++ obvious.
>
> I have done professional FORTRAN 77 programming for 15 years (Finite
> Element Method + related stuff). It became obvious to me that the language
> was not expressive enough. Scientists and engineers do other things besides
> numerics (actually, they do relatively little numerics). Most non-trivial
> applications do much more general information management than pure
> numerics. Fortran is a poor tool for such work. OO and C++ is great in that
> area. I am not a language fanatic. If I was, I would not have developed a
> technique for calling F77 from C++, and I would not have made it public at
> http://home.sol.no/~arnholm/cppf77.htm
>
> Sometimes Fortran is the right tool, sometimes C++ is the right tool. Why
> not take the best from two worlds ?
Still, this does not rebate the fact that C++ is not easy to learn.You had
stated before in c.l.f. that you took your time on learning c++
(even paid some course if I remember well).
I do find c++ /c powerful languages for a lot of things, but not for
numerical applications. I think you are right on the nail ( as we said in my
country :) by providing a way to interface fortran with c/c++. I hope it
becomes
a standard in F2k.
Greg Lindahl
"Carsten Arnholm" <arn...@online.no> writes:
> > We have now degenerated in the usual meaningless langauge drivel.
>
> Meaning: I don't know what to say anymore.
Ask my friends -- I'm never lacking something to say.
> Meaning: I never bothered to read the manual, and I could not quite figure
> it out.
Actually, I've both read the STL manual, and I use something quite
similar in the project I work on. I still don't think that container
classes are the right way to approach arrays. I'm happy to disagree
with you about this, and I'm also happy to point out that you had
strayed from the topic of the thread off into the typical C++
vs. everyone else language flamewar.
> > You may find it to be a good tool, but few scientific
> > programmers find C++ obvious.
>
> I have done professional FORTRAN 77 programming for 15 years (Finite
> Element Method + related stuff). It became obvious to me that the language
> was not expressive enough.
But you seem to claim that you're average. You aren't.
> Sometimes Fortran is the right tool, sometimes C++ is the right tool. Why
> not take the best from two worlds ?
I do. I just don't think that STL is a good replacement for arrays, or
that the average Fortran programmer can effectively use C++. You then
insulted me.
> Sounds like you are interested in your own viewpoints. period.
Nope. I've met a few people with your viewpoint before, and I'm happy
to disagree with them.
-- g
Carsten Arnholm
Jose Miguel Perez <jpe...@stat.purdue.edu> wrote in article
> >
> > I have done professional FORTRAN 77 programming for 15 years (Finite
> > Element Method + related stuff). It became obvious to me that the
language
> > was not expressive enough. Scientists and engineers do other things
besides
> > numerics (actually, they do relatively little numerics). Most
non-trivial
> > applications do much more general information management than pure
> > numerics. Fortran is a poor tool for such work. OO and C++ is great in
that
> > area. I am not a language fanatic. If I was, I would not have developed
a
> > technique for calling F77 from C++, and I would not have made it public
at
> > http://home.sol.no/~arnholm/cppf77.htm
> >
> > Sometimes Fortran is the right tool, sometimes C++ is the right tool.
Why
> > not take the best from two worlds ?
>
> Still, this does not rebate the fact that C++ is not easy to learn.You
had
> stated before in c.l.f. that you took your time on learning c++
> (even paid some course if I remember well).
Wow ... I envy you your memory ( the biological, that is ). If I said so,
it must be a long time ago. But it is correct. My company paid for a one
week C++ course back in 1994 or 1995. It is also correct that I spent about
a year learning Fortran at the university back in the old days (1980/1981).
Any useful tool takes some effort to learn. True with Fortran, true with
C++. People tend to forget how much effort they spent learning their first
programming language, especially when they are looking at some other
language.
If it requires zero efforts to learn the second language, there is no
point, because you can probably express the same things in the language you
already know. C++ poses a challenge because it is extremely expressive, but
it pays off, in my opinion.
>
> I do find c++ /c powerful languages for a lot of things, but not for
> numerical applications. I think you are right on the nail ( as we said
in my
> country :) by providing a way to interface fortran with c/c++. I hope it
> becomes
> a standard in F2k.
Thanks ! The group of people using this technique is growing steadily.
Maybe the technique could be formally standardised some day, but for the
moment it feels sufficient to see it in practical use.
There are ways of extending the technique in the area of numerics. Lately,
an interesting technique for calling C++ virtual functions from Fortran has
been described. This is very useful when combining legacy FORTRAN libraries
with C++ class libraries. My prediction is that C++ will soon be much more
important in areas which have been dominated by Fortran so far.
Carsten Arnholm
> "Carsten Arnholm" <arn...@online.no> writes:
>
> Ask my friends -- I'm never lacking something to say.
Ok, I believe you.
>
> Actually, I've both read the STL manual, and I use something quite
> similar in the project I work on. I still don't think that container
> classes are the right way to approach arrays.
If you take the view that containers are awkward arrays, it's hard to
disagree. The point is that in languages like C or Fortran arrays are often
used as containers, and arrays are poor containers. Typically you need
sets, lists, maps, besides vectors (i.e. dynamic arrays). If you _do_ need
a low level array, there is nothing stopping you from from using them in
C++.
> I'm happy to disagree
> with you about this, and I'm also happy to point out that you had
> strayed from the topic of the thread off into the typical C++
> vs. everyone else language flamewar.
Please note that I have never taken that standpoint. I'm just stating that
C++ is a big improvement over Fortran in many cases. This does not imply
that I think Fortran programmers are idiots or anything like that. Why
should I, I'm a Fortran programmer too. I just happen to use more than one
language ....
>
> > I have done professional FORTRAN 77 programming for 15 years (Finite
> > Element Method + related stuff). It became obvious to me that the
language
> > was not expressive enough.
>
> But you seem to claim that you're average. You aren't.
Who's average ? Are you ?
>
> > Sometimes Fortran is the right tool, sometimes C++ is the right tool.
Why
> > not take the best from two worlds ?
>
> I do. I just don't think that STL is a good replacement for arrays, or
> that the average Fortran programmer can effectively use C++. You then
> insulted me.
Again, STL are not just a replacement for arrays. STL is a generic set of
containers which are very useful where arrays fall short. Sorry, if you
were insulted.
> Nope. I've met a few people with your viewpoint before, and I'm happy
> to disagree with them.
Well, then everybody's happy. Isn't it nice to be happy ?
James Giles
Carsten Arnholm wrote in message <01bd880f$6976c400$1b094382@rustad1>...
...
>Any useful tool takes some effort to learn. True with Fortran, true with
>C++. People tend to forget how much effort they spent learning their first
>programming language, especially when they are looking at some other
>language.
I *have* forgotten how long it took me to learn my first
language. I *haven't* forgotten how long it took me to
learn the most recent 50 languages I've studied. Out
of that set, C took about 10 times as long to learn
as other languages with similar expressiveness and
capabilities. (Turing+, for example, is easier to
learn and has all the features needed to write system
code for which C is often used. It is not just easier to
learn: it has fewer - almost none - traps and pitfalls, and
is less prone to many of the kinds of hard to find bugs
that seem to riddle C code.)
>If it requires zero efforts to learn the second language, there is no
>point, because you can probably express the same things in the language you
>already know. C++ poses a challenge because it is extremely expressive, but
>it pays off, in my opinion.
Everything any programming language does can be
expressed in all the other languages I've learned. That's
the most important lesson of Computing Science: All
sufficiently powerful programming languages permit the
coding of the *same* set of calculations. The
"expressiveness" of a programming language relates to
the *ease* of expressing an algorithm or data structure,
not to *whether* you can express it.
C++ is considerably more complex and difficult to learn
than other languages with similar "expressiveness". Based
on all the evidence I've seen, it's also much more prone
to error and delays in the programming process than
languages usually considered less "expressive". In the
only cases I've seen where the same code was developed
in C++ and some other language (usually the other language
first and then a C++ version), the C++ code took longer
to write (even with the best C++ "gurus" available), had
more long-term bugs (which took longer to find and
correct), ran slower, was *much* bigger, and - if the two
versions of the code were supported in parallel - the C++
version was always a revision or two behind. This is very
strange since the C++ team usually has the experience of the
other team to draw upon for any subtleties of the problem itself.
So, their difficulties must stem from the language.
There is an extent to which the problems stem from object
oriented techniques being applied when they are not desirable,
much less necessary. But the main culprit is the fact that C++
follows in the C tradition of adding features to the language
in the clumsiest way possible.
--
J. Giles
Ricercar Software
Greg Lindahl
"Carsten Arnholm" <arn...@online.no> writes:
> If you take the view that containers are awkward arrays, it's hard to
> disagree. The point is that in languages like C or Fortran arrays are often
> used as containers, and arrays are poor containers.
Ah. But that "point" wasn't mentioned until now, so I don't see why
you were posting in this thread at all. I happen to disagree with your
point, but that would be off-topic.
> If you _do_ need
> a low level array, there is nothing stopping you from from using them in
> C++.
But the question you were providing an answer to is "how do I get an
arbitrary lower bound for arrays in this new C9x version?"
> Please note that I have never taken that standpoint. I'm just stating that
> C++ is a big improvement over Fortran in many cases.
But nobody asked that. Hence, I claim you were starting a language flamewar.
> Again, STL are not just a replacement for arrays.
Then why did you present them as such? Or do you just lie in wait for
any excuse to promote your ideas in threads for which you are off-topic?
-- g
tyd...@tybor.com
In <5TQL+Yo....@delphi.com>, Kenneth G. Hamilton <hami...@delphi.com> writes:
>Craig Burley <bur...@tweedledumb.cygnus.com> writes:
>
>>- A language with binary infix operators having the ordinary meanings
>> of "and" and "or", like Fortran's `.AND.' and `.OR.'.
>
>
>Gosh, you mean something that reads like English, instead of Martian?
The existing C language already has:
and
and_eq
bitand
bitor
compl
not
not_eq
or
or_eq
xor
xor_eq
They are defined in the header <iso646.h>
Craig Burley
tyd...@tybor.com writes:
> In <5TQL+Yo....@delphi.com>, Kenneth G. Hamilton <hami...@delphi.com> writes:
> >Craig Burley <bur...@tweedledumb.cygnus.com> writes:
> >
> >>- A language with binary infix operators having the ordinary meanings
> >> of "and" and "or", like Fortran's `.AND.' and `.OR.'.
> >
> >
> >Gosh, you mean something that reads like English, instead of Martian?
>
> The existing C language already has:
> and
> and_eq
> bitand
> bitor
> compl
> not
> not_eq
> or
> or_eq
> xor
> xor_eq
>
> They are defined in the header <iso646.h>
Not on my system, they aren't. And I doubt they have any relevance
to what I was asking for -- which was *not* mere syntactic "English"
sugar for &, &&, ||, and |, though I think that might have been
what Kenneth G. Hamilton thought I meant.
I'm saying a language that doesn't offer a simple way to express
the same *meaning* as implied by Fortran's "F() .AND. G()", where
F and G are functions, is probably inadequate for serious numerical
work. And C and C++ do not meet this requirement. (If you think
they do, please don't argue with me about it; just go away and
*read* up on Fortran, read the standards, etc., and think about
the *meanings*, not just one of the implementations you happen to
find convenient. I've argued this point here, on comp.lang.c, and
on comp.compilers for years, and *nobody* has as yet posted a way
to simply express the same thing in C or C++, though many neophytes
have tried "f() & g()" and "f() && g()", which do *not* mean the
same thing.)
Carsten Arnholm
Craig Burley <bur...@tweedledumb.cygnus.com> wrote in article
<y6k96ul...@tweedledumb.cygnus.com>...
> tyd...@tybor.com writes:
>
> > In <5TQL+Yo....@delphi.com>, Kenneth G. Hamilton
<hami...@delphi.com> writes:
> > >Craig Burley <bur...@tweedledumb.cygnus.com> writes:
> > >
> > >>- A language with binary infix operators having the ordinary
meanings
> > >> of "and" and "or", like Fortran's `.AND.' and `.OR.'.
> > >
> > >
> > >Gosh, you mean something that reads like English, instead of Martian?
> >
> > The existing C language already has:
> > and
> > and_eq
> > bitand
> > bitor
> > compl
> > not
> > not_eq
> > or
> > or_eq
> > xor
> > xor_eq
> >
> > They are defined in the header <iso646.h>
>
> Not on my system, they aren't.
And since your compiler (outdated ?) don't have them, they don't exist,
right ?
> And I doubt they have any relevance
> to what I was asking for -- which was *not* mere syntactic "English"
> sugar for &, &&, ||, and |, though I think that might have been
> what Kenneth G. Hamilton thought I meant.
>
> I'm saying a language that doesn't offer a simple way to express
> the same *meaning* as implied by Fortran's "F() .AND. G()", where
> F and G are functions, is probably inadequate for serious numerical
> work. And C and C++ do not meet this requirement.
i.e. anyone using C or C++ are not serious about numerical work ? Hmm ....
I am doing Finite Elements, and I've switched from F77 (10+ years) to C++
(4+ years). Am I not serious.
> (If you think
> they do, please don't argue with me about it; just go away and
> *read* up on Fortran, read the standards, etc., and think about
> the *meanings*, not just one of the implementations you happen to
> find convenient.
I though a discussion group was meant for discussions. Now I know it is
meant for telling other people that whatever they think, it's wrong, and
there's some standards (, etc. ) that they haven't read. Even if they
_have_ read the standards, you can always refer to the "etc." stuff they
have not read.
> I've argued this point here, on comp.lang.c, and
> on comp.compilers for years, and *nobody* has as yet posted a way
> to simply express the same thing in C or C++, though many neophytes
> have tried "f() & g()" and "f() && g()", which do *not* mean the
> same thing.)
please explain the difference to us neophytes
--
Carsten Arnholm
arn...@online.no
http://home.sol.no/~arnholm/.
Serguei Patchkovskii
Carsten Arnholm (arn...@online.no) wrote:
: Craig Burley <bur...@tweedledumb.cygnus.com> wrote:
: > I've argued this point here, on comp.lang.c, and
: > on comp.compilers for years, and *nobody* has as yet posted a way
: > to simply express the same thing in C or C++, though many neophytes
: > have tried "f() & g()" and "f() && g()", which do *not* mean the
: > same thing.)
: please explain the difference to us neophytes
Please teach yourself how to use DejaNews, or a similar Usenet
archive. The semantic difference between logical operators in
C and Fortran has been discussed in comp.lang.fortran probably
a dozen times during the last year, and yet another discussion
won't serve anything.
/Serge.P
Craig Burley
"Carsten Arnholm" <arn...@online.no> writes:
Did I say that?
They *are* defined in the header in newer versions of gcc I've
installed. But there's no iso646.h in my /usr/include, which
came with my RedHat 4.2 and RedHat 5.0 systems.
Maybe there's been a new version of the C standard since I last
looked, but, again, that isn't relevant to the discussion. I never
asked for syntactic sugar in this thread; I was asking for
*semantic* expressiveness that is lacking in C, and is, amazingly,
still lacking in C++.
> > And I doubt they have any relevance
> > to what I was asking for -- which was *not* mere syntactic "English"
> > sugar for &, &&, ||, and |, though I think that might have been
> > what Kenneth G. Hamilton thought I meant.
> >
> > I'm saying a language that doesn't offer a simple way to express
> > the same *meaning* as implied by Fortran's "F() .AND. G()", where
> > F and G are functions, is probably inadequate for serious numerical
> > work. And C and C++ do not meet this requirement.
>
> i.e. anyone using C or C++ are not serious about numerical work ? Hmm ....
> I am doing Finite Elements, and I've switched from F77 (10+ years) to C++
> (4+ years). Am I not serious.
I didn't say that.
I *was* talking about using a language that is well-suited to the
task. C is not well-suited to numerical work. I did *not* say that
anyone using it for numerical work is not serious about it. (I did
certainly imply that they were either disregarding, or working around,
its inadequacies -- an implication I stand by.)
But, perhaps I made the mistake of using English to precisely express
what I *was* saying. And, somehow, you managed to misinterpret it
nonetheless.
Perhaps I should conclude that English is not well-suited for
serious technical communication?
Point being that, despite writing IMO fairly clearly what I *did*
say, you nonetheless managed (intentionally?) to misinterpret it,
and tried to start a flamewar, thus wasting lots of time.
And, anyone writing "f() & g()" or "f() && g()" in C or C++ is *likely*
to be writing something they don't mean, leading to misunderstanding
by the reader. In that case, though, they don't have the choice of
writing any more clearly *unless* they avoid C and C++ in the first
place; and the reader isn't *intending* to misunderstand what they
wrote.
> > I've argued this point here, on comp.lang.c, and
> > on comp.compilers for years, and *nobody* has as yet posted a way
> > to simply express the same thing in C or C++, though many neophytes
> > have tried "f() & g()" and "f() && g()", which do *not* mean the
> > same thing.)
>
> please explain the difference to us neophytes
I will if you first tell us whether both of the following was true:
- There was a full moon (astronomically; cloud cover is irrelevant)
here in Boston, MA the night of 1997-05-24
- Whether the Dallas Cowboys beat the Pittsburgh Steelers
by at least 4 points in the most recent Super Bowl they played
...AND if you tell us exactly how you determined the answer to
the above question...
...AND if you show us exactly how to express the "both of the following"
part of the above in C.
In Fortran, it's:
PRINT *, FMOON(...) .AND. SBOWL(...)
where both functions are LOGICAL and make the respective determinations.
And it is irrelevant what special "attributes" have been given these
functions; the relevant bit is the ".AND.".
Carsten Arnholm
> "Carsten Arnholm" <arn...@online.no> writes:
>
>>
> > i.e. anyone using C or C++ are not serious about numerical work ? Hmm
...
C++
> > (4+ years). Am I not serious.
>
> I didn't say that.
>
> I *was* talking about using a language that is well-suited to the
> task. C is not well-suited to numerical work. I did *not* say that
> anyone using it for numerical work is not serious about it. (I did
> certainly imply that they were either disregarding, or working around,
> its inadequacies -- an implication I stand by.)
The implication that C or C++ is "inadequate" for numerical work is purely
subjective.
>
> But, perhaps I made the mistake of using English to precisely express
> what I *was* saying. And, somehow, you managed to misinterpret it
> nonetheless.
>
> Perhaps I should conclude that English is not well-suited for
> serious technical communication?
True, in many ways. The most difficult aspect of the software projects I
have been working on is human communication. It is often not very precise,
regardless of the language (I'm Norwegian).
>
> Point being that, despite writing IMO fairly clearly what I *did*
> say, you nonetheless managed (intentionally?) to misinterpret it,
> and tried to start a flamewar, thus wasting lots of time.
I did not try to start a flamewar, so somehow this statement bounces back.
> > > I've argued this point here, on comp.lang.c, and
> > > on comp.compilers for years, and *nobody* has as yet posted a way
> > > to simply express the same thing in C or C++, though many neophytes
> > > have tried "f() & g()" and "f() && g()", which do *not* mean the
> > > same thing.)
> >
> > please explain the difference to us neophytes
>
> I will if you first tell us whether both of the following was true:
>
> - There was a full moon (astronomically; cloud cover is irrelevant)
> here in Boston, MA the night of 1997-05-24
I could, but I don't see why I should. I live outside Oslo, Norway and
don't care to much about full moons in Boston.
>
> - Whether the Dallas Cowboys beat the Pittsburgh Steelers
> by at least 4 points in the most recent Super Bowl they played
>
Can you tell me who won the Norwegian championship in speed skating this
year ?
> ...AND if you tell us exactly how you determined the answer to
> the above question...
>
> ...AND if you show us exactly how to express the "both of the following"
> part of the above in C.
You're pretty sure you wont have to explain, aren't you ?
>
> In Fortran, it's:
>
> PRINT *, FMOON(...) .AND. SBOWL(...)
>
> where both functions are LOGICAL and make the respective determinations.
> And it is irrelevant what special "attributes" have been given these
> functions; the relevant bit is the ".AND.".
> --
So if I have the following ISO C++ functions
bool fmoon(...);
bool sbowl(...);
what's wrong about
cout << ( fmoon(...) && sbowl(...) ) << endl;
James Giles
Carsten Arnholm wrote in message <01bd93f8$876a6030$17094382@rustad1>...
>Craig Burley <bur...@tweedledumb.cygnus.com> wrote in article
><y6k96sf...@tweedledumb.cygnus.com>...
>> In Fortran, it's:
>>
>> PRINT *, FMOON(...) .AND. SBOWL(...)
...
>bool fmoon(...);
>bool sbowl(...);
>
>what's wrong about
>
>cout << ( fmoon(...) && sbowl(...) ) << endl;
Both of these are about the same if the functions called
have no side effects. The C (and C++) rule is that &&
will shortcut if fmoon() is false. The Fortran rule is that
.AND. *may* shortcut if it determines FMOON() or
SBOWL() is false (whichever it executes first). The
only difference is speed - and it's not clear which wins
since both are allowed to shortcut, Fortran might not
shortcut, but Fortran might execute the fastest function
frst.
If the functions have side effects, neither language is
completely adequate. Fortran requires that, even though
they both might have side effects, they must not effect each
other. So, Fortran can still safely do the function calls in
either order. However, Fortran does not guarantee that
both functions (and therefore both sets of side effects) will
be executed. Neither does C (which doesn't allow parallel
or out of order execution either).
To be well defined, there should be a set of operators
which impose a strict ordering on the function calls and
guarantee shortcutting AND there should be a complete
set of operators which allow the operands to be executed
in any order and which guarantee NO shortcutting. The
latter condition is particularly important for parallel computing
which could be evaluating the operands simultaneously.
Either that, or there should be a rule outlawing side effects
in functions (try to get that past the committees).
--
J. Giles
Greg Lindahl
> To be well defined, there should be a set of operators
> which impose a strict ordering on the function calls and
> guarantee shortcutting AND there should be a complete
> set of operators which allow the operands to be executed
> in any order and which guarantee NO shortcutting.
Had you ever bothered to read past discussions of this topic, you
would be aware that Fortran does have shortcutting as well as the
"compiler chooses the order and shortcutting" form. Your second
option above (no shortcutting) can be expressed by using subroutines
and a smart compiler. I'm sure you remember that functions can't have
bad side-effects but subroutines can.
Fortran shortcutting example:
if (first()) then
if (second()) then
...
endif
endif
-- g
William Clodius
Greg Lindahl wrote:
> <snip> I'm sure you remember that functions can't have
> bad side-effects but subroutines can.
Fortran function can have side effects, however there are more instances
than in C where the results of mutually interacting side effects are not
defined. Even in C there are contexts where the results of mutually
interacting side effects are not defined, or if they are defined the
defined behavior might not be what a typical programmer might expect. In
both languages, the code writer should think long and hard about
defining "functions" that return values and have side effects, and be
certain he understands the context of their use.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
James Giles
Greg Lindahl wrote in message <6lm929$h...@news3.newsguy.com>...
>> To be well defined, there should be a set of operators
>> which impose a strict ordering on the function calls and
>> guarantee shortcutting AND there should be a complete
>> set of operators which allow the operands to be executed
>> in any order and which guarantee NO shortcutting.
>
>Had you ever bothered to read past discussions of this topic, you
>would be aware that Fortran does have shortcutting as well as the
>"compiler chooses the order and shortcutting" form. [...]
Had you bothered to read the message I just wrote (and which
you quote a fraction of), you would have seen that I explicitly
said that Fortran allowed shortcutting and any choice of order.
But, allowing shortcutting is different than requiring it. And,
without a requirement on the order in which the operands
are evaluated, shortcutting is not well defined. Shortcutting
is only well defined if the order in which the operands are
evaluated is also defined (as C does).
> [...] Your
second
>option above (no shortcutting) can be expressed by using subroutines
>and a smart compiler. I'm sure you remember that functions can't have
>bad side-effects but subroutines can.
Since subroutine references can't appear in expressions, this
observation is irrelevant to the present discussion. We are
talking about the evaluation of AND and OR operators in
expressions.
>Fortran shortcutting example:
>
> if (first()) then
> if (second()) then
> ...
> endif
> endif
(Ignoring that a shortcut for OR in this form is very
clumsy!)
The problem is that this is also *one* of the possible
interretations of:
if(first() .and. second()) then
...
end if
However, this can also be interpreted as:
if (second()) then
if (first()) then
...
endif
endif
On the other hand, the compiler is perfectly free under the
standard to evaluate both operands every time (no shortcutting
at all). This makes Fortran's operators less well defined than
C's since it may perform the side effects of first() only, or of
second() only, or both.
Now, having said all that, I'd like to point out that I would
prefer that the C interpretation *not* be adopted. It would
be better if shortcutting were explicitly specified:
if (first()) and if (second()) then
...
endif
if (first()) or if (second()) then
...
endif
The reason this would be better is that the infix boolean
operators could then be required to have their traditional
properties - that is, they are commutative and associative.
This means that all the operands should always be evaluated
in every instance (at least, if they have, or might have, side
effects). So, on a parallel implementation the operands can
be evaluated in parallel with no change to the meaning of
the program.
Either that or, as I said previously, disallow functions with
side effects. That would make the present Fortran rules
completely well defined. (With Fortran 95, it's probably
a good idea to make all functions PURE anyway - at least
those referenced in boolean expressions. Of course, this
has problems in that PURE is not really pure in F95 ... Oh well.)
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> Had you bothered to read the message I just wrote
I did. I just violently disagree with most of your definitions. I
suppose I'm better off doing real work than arguing with you; you can
just consult the last go-round of this discussion and not be
enlightened once again.
-- g
James Giles
Greg Lindahl wrote in message <6lmp8v$8...@news1.newsguy.com>...
Since I've discussed this issue with members of the Fortran
committee before and they've agreed that my analysis (basically
the same as my last article) is correct, I don't know what
you've violently disagreed with. I wouldn't recommend
arguing with *them* - they could issue an official interpretation
which supports their position.
In summary:
1) The C standard requires shortcutting and strict left to
right evaluation order. (If you disagree with that, you
need to get a copy of the C standard document.)
2) Because of (1), C does not allow certain optimizations
such as evaluating the operands of a logical expression
in parallel, or evaluating the easiest operand first.
3) Fortran allows the above optimizations. But it also
allows shortcutting (but doesn't *require* it like C does).
And it also allows function calls to have side effects.
4) Because of (3), a standard conforming Fortran program
may nevertheless generate different results on different
Fortran implementations (or even on different compiles
with the same implementation). Most people agree that
such behavior can fairly be described as "not well defined"
(though the standard document itself calls the effected
objects "undefined").
5) It is possible to eliminate the ambiguity in Fortran by
eliminating one or more of the freedoms that the Fortran
standard allows. Like: disallow side-effects. Or: disallow
shortcutting the operators. Or: adopt the C rules for the
operators.
6) Disallowing side effects might be the best solution since
references in the same expression already are disallowed
side effects which effect each others values (7.1.7.1 and
C.7.2 of the F90 standard document).
7) Disallowing shortcutting is the option I prefer. It makes
operators have their traditional properties (commutative
and associative). It guarantees that all functions in an
expression are always called (so their side effects can
be relied upon). You can go ahead and shortcut anyway
if the operands are all local expressions or PURE functions.
And finally because the user can explicitly require the
same behavior as shortcutting at the statement level using
nested IFs (which is clumsy for shortcut OR, as I said
before - but the proper syntactic sugar is easy to provide
in a preprocessor: the ANDIF and ORIF forms I wrote
last time).
8) I don't like the C solution because it doesn't allow optmizations
like reordering or parallelization of the operand evaluation. But
it would eliminate the hole in Fortran's semantics.
Now which point or points above do you so violently
disagree with, and why? As you point out, this discussion
is covering old ground. I've never had anyone on the
committee disagree with my analysis of this issue (though
they might disagree which solution ought to be applied,
or even whether a solution is necessary - user beware).
It's hard to imagine why you do.
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> 5) It is possible to eliminate the ambiguity in Fortran by
> eliminating one or more of the freedoms that the Fortran
> standard allows. Like: disallow side-effects. Or: disallow
> shortcutting the operators. Or: adopt the C rules for the
> operators.
Given that I have said that you force shortcutting in Fortran by:
if (first()) then
if (second()) then
...
endif
endif
That means that you are using a different definition of shortcutting,
and you aren't listening to what I write, since it would be impossible
to disallow this form of shortcutting.
-- g
James Giles
Greg Lindahl wrote in message <6lp0cj$d...@news1.newsguy.com>...
I don't understand why you ignore the topic I am discussing.
I have never denied that in the above code fragment the execution
of second() is dependent upon whether first() is true. That is an
inherent part of the semantics of IF blocks (and the term 'short cutting'
or 'short circuiting' is not relevant to IF blocks - only to operators).
That's not the topic under discussion. The question at hand is: does
second() get called in the following code fragment?
if (first() .and. second()) then
...
endif
Indeed, does first() get executed? Do both get executed? Does
the execution of either function call depend upon the value returned
by the other? The Fortran standard doesn't answer these questions.
The language definition is ambiguous on this point. That's what
I call "not well defined". I think the language should NOT
be ambiguous in this regard. There is no reason for it to be.
--
J. Giles
Robert O'Dowd
James Giles wrote:
> Greg Lindahl wrote in message <6lp0cj$d...@news1.newsguy.com>...
> >"James Giles" <james...@worldnet.att.net> writes:
> >
> >> 5) It is possible to eliminate the ambiguity in Fortran by
> >> eliminating one or more of the freedoms that the Fortran
> >> standard allows. Like: disallow side-effects. Or: disallow
> >> shortcutting the operators. Or: adopt the C rules for the
> >> operators.
> >
> >Given that I have said that you force shortcutting in Fortran by:
> >
> > if (first()) then
> > if (second()) then
> > ...
> > endif
> > endif
> >
[Snip]
> I have never denied that in the above code fragment the execution
> of second() is dependent upon whether first() is true. That is an
> inherent part of the semantics of IF blocks (and the term 'short cutting'
> or 'short circuiting' is not relevant to IF blocks - only to operators).
> That's not the topic under discussion. The question at hand is: does
> second() get called in the following code fragment?
>
> if (first() .and. second()) then
> ...
> endif
>
> Indeed, does first() get executed? Do both get executed? Does
> the execution of either function call depend upon the value returned
> by the other? The Fortran standard doesn't answer these questions.
> The language definition is ambiguous on this point. That's what
> I call "not well defined". I think the language should NOT
> be ambiguous in this regard. There is no reason for it to be.
Since you can explicitly achieve any of those possibilities by other
means, there is no reason why it should be defined either. You
don't *need* more than one way to achieve anything. You may want
alternatives, but you don't need them.
Realistically though, we can say the result of the above is
undefined (just as many things are undefined in FORTRAN,C,C++, etc).
With the above example, the compiler is free to do as it wishes.
In C, a similar thing happens with
f(a(), b());
In this example, the order of invoking functions a() and b() is
also undefined. I suspect the reasoning is the same; some
people will assume left to right evaluation order, others will
assume right to left evaluation. Others (e.g. on parallel
machines) could assume both function calls are invoked in parallel
for speed purposes. At least part of your audience will be
unhappy if they assume a particular order of evaluation. By
not defining an order, the language definition hands the
responsibilty back to the programmer to do things right.
-<Automagically included trailer>
Robert O'Dowd Ph +61 (8) 9553 3618
DSTO Bldg A51 Fax +61 (8) 9553 3577
HMAS Stirling Email:
robert...@dsto.defence.gov.au
Rockingham, Western Australia, 6958
Disclaimer: Opinions above are mine and may be worth what you paid for
them
Gib Bogle
Craig Burley wrote:
[snip]
At the risk of drawing fire from all sides, I have to say that this debate is
reminiscent of argueing about how many angels can stand on the head of a pin. Is
it really so important?
------------------------------------------------------
Gib Bogle g...@bogle.co.nz
Bogle Enterprises Tel: (64-9) 525-6878
1/44 Arthur St Fax: (64-9) 525-6878
Ellerslie, N.Z.
------------------------------------------------------
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> I don't understand why you ignore the topic I am discussing.
I was attempting to make a point, and you keep on griding whatever axe
you started with. Clearly I'm wasting everyone's time.
> The question at hand is: does
> second() get called in the following code fragment?
>
> if (first() .and. second()) then
> ...
> endif
And the answer is well known. I already told you how to force the
answer to be yes, no, or undefined, using current Fortran syntax. But
you don't seem to care.
-- g
Toon Moene
Gib Bogle <g...@bogle.co.nz> wrote:
> At the risk of drawing fire from all sides, I have to say that this debate
is
> reminiscent of argueing about how many angels can stand on the head of a
pin. Is
> it really so important?
Apparently, you've never seen a religious war at close quarters. Relax, we
in the Netherlands are on the brink of redoing Northern Ireland all over
again.
But, to return to your question: This is most easily answered by pondering
the subject in reverse order (and wonder why you never see it):
"New Fortran Standard Lures C Users"
See ?
--
Toon Moene (mailto:to...@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:for...@gnu.org; NWP: http://www.knmi.nl/hirlam
Craig Burley
Gib Bogle <g...@bogle.co.nz> writes:
> At the risk of drawing fire from all sides, I have to say that this debate is
> reminiscent of argueing about how many angels can stand on the head of a pin. Is
> it really so important?
Yes. It is *quite* important to frequently remind programmers to
look at the forest, not just the trees, generally.
In particular, it is important to counter claims that a programming
language is "well-suited" for, e.g., numerical work simply because
something *can* be done with it, even though many important numerical
expressions do not exist in that language, forcing those expressions
to be written out as implementations, not expressions.
I think the .AND./.OR. example itself isn't all that important, myself,
but it is an interesting example. I think it's at least as important
for compiler-development work as for numerical work, but I'm not
experienced doing numerical programming, so I might be wrong. In any
case, I use C for most of my compiler-development work, and rarely
find the lack of .AND./.OR. to be a "real" problem. (Yes, it's
annoying that I always have to choose a particular implementation of
them instead of being able to just say "and" or "or" as an *expression*.
But the implementation I choose is rarely a significant overstatement
of what I want to accomplish. I believe readers of my code are thus
rarely likely to misunderstand what I've written as a result of this
particular problem.)
Nevertheless, when I see programmers naively claim a language is
"ready" for widespread use in a field, based almost entirely on
whether the language offers, e.g., *libraries* suitable for use in
that field, I cringe, because a good *language* is not the same as
a good *tool*.
In short, C, sed, awk, perl, etc. are fine *tools* for use in
numerical work, but *none* of them, IMO (excluding perl, which I
haven't looked at yet), are appropriate *languages* for numerical
work. That is, they aren't well-suited to *express* the algorithms,
or often the high-level implementations, that represent the primary
focus of the numerical work.
The reasons I say this stem primarily from what I believe is the
#1 priority of any language (whether human, i.e. speech, gestures,
etc., or artificial, e.g. a computer language):
A good language makes it hard to write stuff that can be
misunderstood.
Reasoning from that, any language that *regularly* forces the
author to resort to writing *implementation* details in place of
*expressions* of what they want done is likely to fail in achieving
that first priority -- because the reader is likely to mistake
the implementation for the algorithm.
Going back to an example earlier in this thread, the pertinent
advantage of Fortran's
l = f() .and. g()
over C's
l = f() & g()
or
l = f() && g()
or
l = g() && f()
is that the Fortran form literally says no *more* than "at this
point in time, set the variable L to .TRUE. if and only if both
functions F and G would return .TRUE. at this time".
Whereas all three C forms *add* to that statement. E.g. the
first adds "...and make sure both F and G are actually called,
so any side effects they might perform are in fact performed";
the second adds "...and make sure F is actually called, so any
side effects it might perform are in fact performed, and *then*
that G is actually called if and only if F returned zero, so
any side effects it might perform are performed in that case and
may depend on F having been called".
That is, the reader cannot *avoid* taking into account the
extra linguistic baggage *always* carried by any of the simple
statements in the C forms. The reader can, of course, perform
comprehensive analysis to determine whether the extra baggage
is actually important and can thus be ignored -- good compilers
might do this, and they do count as "readers" somewhat -- but the
reader cannot then express the knowledge he's obtained, via a
rather expensive analysis, in the original language!
That forces *every* reader, who wants to know whether the baggage
is necessary, to perform the same analysis each and every time
they read the code. After all, the functions F and G, even how
L is used, can change *without* the original line of code changing,
and the results of these changes can be that the necessity of the
added baggage itself changes!
(E.g. the first time the reader sees the code, maybe F and G are
just stubs and look innocuous; a day later, they're filled in with
sensitive, side-effect-using code, so the reader *then* has to
know about those changes to properly interpret the statements.
The people who wrote the original code and F and G "knew" what
they intended all along, but had no way to clearly express that.
In the Fortran version, once they wrote the original statement,
they were expressly saying the side effects of F and G were *not*
important to any particular invocation; otherwise, they would have
made them subroutines instead of functions. In other words, for
them to make the same changes in the Fortran version as might have
been made in the C version(s), the Fortran programmers would have
to go back and change the original line of code! This sounds like
a disadvantage to a write-once-read-never-type programmer, but
it's an *advantage* that the original code must be changed so that
future readers know something *important*, and rather subtle,
has changed vis-a-vis that line of code.)
The effect of all this is what I've observed, in practice, for
several decades: good *tools* are worth using, but often do not
scale up well to multi-programmer, large-scale, long-term programming
projects; good *languages* often do, and so should be preferred
when making recommendations except in very specific situations.
Thus, while I have no objection at all to using C, C++, Forth,
etc. on limited-life, small-scale, single-person projects (for
example), and while I'm definitely not a fan of using Fortran for
my own (non-numerical) work, I certainly will and do object to
anyone who publicly celebrates C or C++ as "preferred" languages
for numerical work over Fortran, especially when they appear to
hand-wave concerns like I've expressed above.
There are other linguistic-design issues I've only hinted at in
the above, such as designing for close-focus correctness, but I
have yet to take any significant chunks of time studying up on
what has already been learned from real studies of the issues
and/or writing down what my own views are. Though I suppose a
DejaNews search of my posts on these topics here, and in
comp.compilers, over the years would prove somewhat helpful.
Usually I find I've got more understanding of these issues than
99% of the programmers who love to post about how Fortran is
dead, but significantly less understanding than the people who
actually, e.g., run large-scale programming projects (though they
often indicate their appreciation of my willingness to tackle
these issues in public, often pointing me to references they
think I'd enjoy reading -- if only I had the time).
James Giles
>Since you can explicitly achieve any of those possibilities by other
>means, there is no reason why it should be defined either. You
>don't *need* more than one way to achieve anything. You may want
>alternatives, but you don't need them.
It's not clear that the Fortran standard presently provides a
way (explicitly or not) to force the both functions in the
following expression to be called regardless of the value
that either returns.
x = F(y) .OR. G(z)
Besides, if there are explicit ways to get the the whole
variety of intended behaviors already in the language
why permit the ambiguous operation above. I agree
that more than one mechanism is not needed. Indeed
a redundant alternative that is ambiguous is definitely
*undesireable*.
>In C, a similar thing happens with
>
> f(a(), b());
>
>In this example, the order of invoking functions a() and b() is
>also undefined. I suspect the reasoning is the same; some
>people will assume left to right evaluation order, others will
>assume right to left evaluation. Others (e.g. on parallel
>machines) could assume both function calls are invoked in parallel
>for speed purposes. At least part of your audience will be
>unhappy if they assume a particular order of evaluation. By
>not defining an order, the language definition hands the
>responsibilty back to the programmer to do things right.
Which is fine if it's straightforward to specify something
explicitly. For example:
if (a(x) .or. b(y)) then
...
endif.
What is the clear way to explicitly specify that a(x) should be
evaluated and that b(y) should not be if the result of a(x) is
true? That is, how does one insist on the "short-cut" semantics
of the OR operator? The standard permits an implementation
to short-cut but doesn't require it.
On the other hand, how does one insist that both functions must
always be called regardless of the value returned by either? The
standard permits short-cuts after all.
Now, the first of these can be done with multiple if tests (checking
each condition in turn) and with GOTOs. Many people object to
using GOTOs however. The second of these objectives *might*
be forced if you evaluate the functions in separate statements,
save the results in temporary LOGICAL variables, and then test
the those temporaries. But its not clear that the standard does not
permit eliminating the calls anyway if the compiler notices that
the only use of their result values is in the IF statement.
As Dick Hendrickson recently pointed out to me, the same problems
arise in other contexts:
x = f(r) * g(s)
Here, if f(r) is zero, is the execution of g(s) guaranteed or not? How
does one force the evaluation of both functions? How does one force
the short-cut if that's what's desired.
Now, as I keep pointing out, if the functions are PURE the fact of
whether they are short-cut or not is irrelevant. The issue only
arises when the functions in question have side effects. (Oh, the
ability of *forcing* the short-cut interpretation is useful even when
imPURE functions are not allowed such as IF(x==0 .OR. y/x > 5)...)
Since the short-cut semantics can always be forced by multiple
if's, the question really ends up being how to force the operations
*not* to short-cut. I can't really see that the present standard
permits the user any means of guaranteeing that his compiler
won't decide to short-cut on occasion. Well, you can convert
all your functions into subroutines - they always get called when
control passes through the CALL statement. But, isn't this begging
the question? The standard permits functions to have side effects.
The uses of such functions should be well defined.
--
J. Giles
James Giles
Greg Lindahl wrote in message <6lrnh8$j...@news3.newsguy.com>...
>> The question at hand is: does
>> second() get called in the following code fragment?
>>
>> if (first() .and. second()) then
>> ...
>> endif
>
>And the answer is well known. I already told you how to force the
>answer to be yes, no, or undefined, using current Fortran syntax. But
>you don't seem to care.
If you claim there is a way to force the above to always
execute second() regardless of the value of first(), then
you don't understand the standard. If you claim that some
*other* code sequence can be written that guarantees
the evaluation of both functions, that is not an answer to
the question. The question, once again, is what can the
user *rely* upon happening with the above code. Any
suggested rewrite of the above code will be rejected as
non responsive to the issue.
Someone can always use other code, or even another
language. That still does not excuse the language definition
treating a common - and legal - code construct in an ambiguous
way. The standard should either provide a clear definition
of the above code fragment or make it illegal. I have proposed
several alternatives which would clearly define the feature.
Making it illegal is probably not a likely thing for the committee
to do.
--
J. Giles
James Giles
Craig Burley wrote in message ...
>The people who wrote the original code and F and G "knew" what
>they intended all along, but had no way to clearly express that.
>In the Fortran version, once they wrote the original statement,
>they were expressly saying the side effects of F and G were *not*
>important to any particular invocation; otherwise, they would have
>made them subroutines instead of functions. [...]
I don't think this is a common line of thought followed by most
Fortran programmers. I think that most people who write
side effects into functions consider them quite important.
The decision about whether to use a function or a subroutine
is usually a matter of making the invocation as convenient
as possible (that is, they regard the difference as purely
a syntactic difference in how the procedures are called).
Now that Fortran (95) has the concept of PURE, it
could change the rules of expression evaluation so the
functions *not* declared as PURE would always be
evaluated regardless of the values of the other operands
in the expression. This would preserve the (very real)
advantages of Fortran's logical operators you've been
describing, but would eliminate the ambiguity over whether
side effects (when present) could be counted upon. Certain
kinds of side effects (like, those which effect other operands
in the same expression) would still be prohibited, of course.
--
J. Giles
James Giles
Greg Lindahl wrote in message <6mcbd2$e...@news1.newsguy.com>...
>"James Giles" <james...@worldnet.att.net> writes:
>
>> If you claim there is a way to force the above to always
>> execute second() regardless of the value of first(), then
>> you don't understand the standard.
>
>I already gave that example:
>
> a = first()
> b = second()
There is, I'm told (I haven't seen it yet), an official interpretation
of section 7.1.7.1 of the standard which casts some doubt on
whether this is guaranteed to work. However, all this is aside
from the issue being discussed.
>You can fill in the rest. Good luck.
>
>> If you claim that some
>> *other* code sequence can be written that guarantees
>> the evaluation of both functions, that is not an answer to
>> the question.
>
>Only if you have a very narrow mind. The way to guarantee shortcutting
>in Fortran also involves an "other" code sequence.
You still appear to be interested in changing the subject. The issue
is not "is there a way to do X in Fortran?" The issue is whether
the rules of Fortran pertaining to a legal and fairly common type
of expression are well defined or whether they constitute a trap
for the unwary. If the rules of Fortran *are* ill defined (as can
be seen fairly easily) it should be corrected. I've proposed solutions
to that issue. Why do you insist on debating other constructs?
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> If you claim there is a way to force the above to always
> execute second() regardless of the value of first(), then
> you don't understand the standard.
I already gave that example:
a = first()
b = second()
You can fill in the rest. Good luck.
> If you claim that some
> *other* code sequence can be written that guarantees
> the evaluation of both functions, that is not an answer to
> the question.
Only if you have a very narrow mind. The way to guarantee shortcutting
in Fortran also involves an "other" code sequence.
But, I'm repeating myself. I apologize for not doing real work instead.
-- g
ess...@ix.netcom.com
James Giles wrote:
> is not "is there a way to do X in Fortran?" The issue is whether
> the rules of Fortran pertaining to a legal and fairly common type
> of expression are well defined or whether they constitute a trap
> for the unwary. If the rules of Fortran *are* ill defined (as can
> be seen fairly easily) it should be corrected.
Rest easy -- the statement is well defined as it assures that the
expression is always evaluated correctly. Whether second() is evaluated is
as inconsequential as the status of the toilet once you find the bathroom
locked... so, hold off your recommendations for a fix where none is needed.
---
bv
-----------------------------------------------
Eclipse Software
Dynamics * Simulation * Modeling
http://www.netcom.com/~essoft
-----------------------------------------------
James Giles
ess...@ix.netcom.com wrote in message <358AFABE...@ix.netcom.com>...
>James Giles wrote:
>
>> is not "is there a way to do X in Fortran?" The issue is whether
>> the rules of Fortran pertaining to a legal and fairly common type
>> of expression are well defined or whether they constitute a trap
>> for the unwary. If the rules of Fortran *are* ill defined (as can
>> be seen fairly easily) it should be corrected.
>
>Rest easy -- the statement is well defined as it assures that the
>expression is always evaluated correctly. Whether second() is evaluated is
>as inconsequential as the status of the toilet once you find the bathroom
>locked... so, hold off your recommendations for a fix where none is needed.
Well, I'm in the middle of a long discussion with the chairman of
the Fortran committee and one of the other members. Neither of them
consider this a non-issue. Indeed, it has apparently been an
important issue for a few of years now.
ans = first(x) .OR. second(y)
The statement *is* well defined as far as the value of the computed
expression is concerned. The *program* as a whole is not well
defined if some side effect (I/O, alters a SAVEd internal variable,
modifies a global variable, etc.) is performed by second() (or first()
for that matter - Fortran doesn't specify which order in which to
evaluate the operands). The program may then contain the worst
of all possible types of error: plausible generation of *wrong* answers
with no error messages, warnings, or any other indication of a problem.
The problem is that Fortran *permits* functions to have side-effects.
So, it's not an adequate answer to tell the user not to do the above.
It's legal. Further, there's the related (but different) issue I mentioned
before:
ans = f(x)
The question here is: do the side-effects of function f() get performed
if the above assignment is executed? The answer, according to an
official Fortran interpretation is: maybe not. Are you really claiming
this to be a non-issue?
--
J. Giles
Walt Brainerd
lin...@pbm.com (Greg Lindahl) writes:
> "James Giles" <james...@worldnet.att.net> writes:
>
> > If you claim there is a way to force the above to always
> > execute second() regardless of the value of first(), then
> > you don't understand the standard.
>
> I already gave that example:
>
> a = first()
> b = second()
As James points out, there is no assurance that either function
is called. The standard says (and has for many iterations said)
that a function does not need to be called if its value can be
determined in some other way. Also, statements can be executed
in any order as long as the program gets the "right" answers (a
simple example is taking a loop invariant assignment out of a
loop).
and "James Giles" <james...@worldnet.att.net> writes:
> Well, I'm in the middle of a long discussion with the chairman of
> the Fortran committee and one of the other members. Neither of them
> consider this a non-issue. Indeed, it has apparently been an
> important issue for a few of years now.
. . .
> The question here is: do the side-effects of function f() get performed
> if the above assignment is executed? The answer, according to an
> official Fortran interpretation is: maybe not. Are you really claiming
> this to be a non-issue?
I recall giving a presentation about this at an (X3)J3 meeting with
the hope of getting some words into the standard that make this
explicit (at least incorporate the F77 interpretation somehow into
the text of the standard) and making these discussions less necessary,
but all I got was a bunch of yawns, so I gave it up. If these important
J3 folks now think it is an important issue, that would be nice.
Making the current situation clear would be a first step. Possibly
"fixing" the problem could follow (or things could be left as is).
--
Walt Brainerd wa...@fortran.com
Unicomp, Inc. +1-505-797-8989 856-1501 (fax)
1874 San Bernardino Ave NE +1-500-Fortran (367-8726)
Albuquerque, NM 87122 USA http://www.fortran.com/fortran
James Giles
Walt Brainerd wrote in message <6mh0e8$o...@llama.swcp.com>...
>I recall giving a presentation about this at an (X3)J3 meeting with
>the hope of getting some words into the standard that make this
>explicit (at least incorporate the F77 interpretation somehow into
>the text of the standard) and making these discussions less necessary,
>but all I got was a bunch of yawns, so I gave it up. If these important
>J3 folks now think it is an important issue, that would be nice.
Well, you can be a little happier about this than you seem. One of the
people I'm discussing this with now actually referenced your talk at
the Incline Village meeting. You may have perceived a lack of
interest, but the way it was stated to me is that members are convinced
of the importance of the issue but are tired of arguing over proposed
solutions. Regardless, any clarification may not come soon, and
any fix is apparently not likely for some time. Too bad.
--
J. Giles
ess...@ix.netcom.com
James Giles wrote:
> Well, I'm in the middle of a long discussion with the chairman of
> the Fortran committee and one of the other members. Neither of them
> consider this a non-issue. Indeed, it has apparently been an
> important issue for a few of years now.
Considering that Fortran turned forty last year then a sudden burst of concern
over "ill defined code" is indeed questionable. Apparently billions of lines of
code are doing just fine -- hardly a reason for rewriting the rules and
degrading performance just to please semantic fanaticism. Language, as is,
provides ample "ammunition" for assuring execution of any particular piece of
code.
Jeff Templon
ess...@ix.netcom.com writes:
> Considering that Fortran turned forty last year then a sudden burst of concern
> over "ill defined code" is indeed questionable. Apparently billions of lines of
> code are doing just fine -- hardly a reason for rewriting the rules and
> degrading performance just to please semantic fanaticism. Language, as is,
> provides ample "ammunition" for assuring execution of any particular piece of
> code.
On the contrary, it would appear that Fortran folks are growing up,
just like the rest of the programming world (except for possibly
those folks who think C++ is a *real good idea*). If you want to
see what kind of problems ill defined code can cause, spend a few
hours reading comp.risks sometime. Programming is maturing into
an engineering discipline, and the concern over ill-defined code
is a symptom.
To put it in perspective, whip out a sketch of some part you want
machined and take it to your local professional machine shop.
They will quickly point out all your ocurrences of "ill-defined
code" and either correct it on the spot, or ask you to get an
engineering drafting book, go back, and redraw it correctly.
See for example Hammond et al, "Engineering Graphics", p. 348-352
(these are the pages in the 2nd edition, there is probably a
newer edition -- the section heading is "tolerance in dimensioning").
Another good way to put this semantic fanaticism in perspective
is to go off and read some of Les Hatton's papers and books.
For example "Safer C" is a good one, although it does not mention
too much about Fortran.
JAT
Greg Lindahl
wa...@swcp.com (Walt Brainerd) writes:
> > a = first()
> > b = second()
>
> As James points out, there is no assurance that either function
> is called. The standard says (and has for many iterations said)
> that a function does not need to be called if its value can be
> determined in some other way.
So, at worst, you might have to resort to subroutines, which must be
called. Still, this will get you to guaranteed "both things called"
with the existing language. I suppose you agree that my different
syntax to get shortcutting is also correct with the existing language.
Shortcutting is by far the most interesting need.
-- g
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> You still appear to be interested in changing the subject. The issue
> is not "is there a way to do X in Fortran?"
I'm amazed that you have yet to notice that we're talking about
different things. I've mentioned this repeatedly.
> Why do you insist on debating other constructs?
Because they make what you're saying moot. But I said that before, too.
-- g
James Giles
Greg Lindahl wrote in message <6mu3gf$o...@news3.newsguy.com>...
>"James Giles" <james...@worldnet.att.net> writes:
>
>> You still appear to be interested in changing the subject. The issue
>> is not "is there a way to do X in Fortran?"
>
>I'm amazed that you have yet to notice that we're talking about
>different things. I've mentioned this repeatedly.
I believe I've consistently pointed out that *you* are indeed
talking about something different. Since your comments are
not germaine to the question I'm addressing, you are still
merely interested in changing the subject.
>> Why do you insist on debating other constructs?
>
>Because they make what you're saying moot. But I said that before, too.
Does the mere existence of other constructs (which I've already
proven make no guarantees anyway) automatically fix legacy
code that needs to be ported to new environments? I think not.
Does the mere existence of those other constructs make the one
I'm discussing illegal? No. Does such existence automatically
make users aware of the pitfalls? No.
The point I'm making is not moot. Making the standard enforce
predictable behavior, or having the standard disallow the ambiguous
construct entirely - either of those choices would make the issue
moot. It is the mere existence of other constructs which is (in
the case) moot.
--
J. Giles
Does the mere existance
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> >I'm amazed that you have yet to notice that we're talking about
> >different things. I've mentioned this repeatedly.
>
> I believe I've consistently pointed out that *you* are indeed
> talking about something different. Since your comments are
> not germaine to the question I'm addressing, you are still
> merely interested in changing the subject.
I never said I was talking about the exact micro-topic that you
were. I never said I wanted to address the same question you are. Feel
free to ignore me.
> Does the mere existence of other constructs (which I've already
> proven make no guarantees anyway) automatically fix legacy
> code that needs to be ported to new environments? I think not.
No, legacy code is not magically fixed.
But the other construct for shortcutting does guarantee something, and
the "both always called" syntax actually does work if you use
subroutines. So I'm not sure what you proved. I know what you _think_
you proved...
And I can say that I have never seen legacy code which broke because
of the ambiguity you discuss. I've only waded through a few million
lines of it, so I'm hardly an expert, but I can name many other things
that are worse problems.
> Does the mere existence of those other constructs make the one
> I'm discussing illegal? No.
Illegal, no. Dull, yes.
> It is the mere existence of other constructs which is (in
> the case) moot.
I think you've proven in considerable detail that I've been wasting my
time attempting to talk to you. But I'm sure you'll reply again.
-- g
James Giles
Greg Lindahl wrote in message <6n1ob9$7...@news1.newsguy.com>...
>But the other construct for shortcutting does guarantee something, and
>the "both always called" syntax actually does work if you use
>subroutines. So I'm not sure what you proved. I know what you _think_
>you proved...
You've proved nothing at all. Your point appears to be that if
the language contains alternative forms which express a desired
algorithm, then the most clear and straight-forward way to express
that algorithm may be made as ambiguous as the committee wants
and it won't bother you. I have never heard of anyone else that
thinks so. Indeed, quite the reverse. Most people consider
the expressiveness of a language its most important characteristic.
I just think the most legible, maintainable form of expression
ought to be easily verifiable. You seem to think that it's
a *good* thing for a common construct not to be well
defined.
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> You've proved nothing at all. Your point appears to be that if
> the language contains alternative forms which express a desired
> algorithm, then the most clear and straight-forward way to express
> that algorithm may be made as ambiguous as the committee wants
> and it won't bother you.
No, I never said that. But thanks for the proof that you haven't been
reading what I write; I can now give up with the knowledge that I have
completely wasted my time.
-- g
James Giles
Greg Lindahl wrote in message <6n8o4d$2...@news1.newsguy.com>...
Based on the e-mail I've received, everyone has come to the same
conclusion I have regarding the nature of your articles. I agree that
you've wasted your time. You've wasted everyone's time. You have
not contributed a single sentence that has any value to anyone reading
this newsgroup. I've wasted my time in treating your articles as
a serious attempt to debate an issue.
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> Based on the e-mail I've received, everyone has come to the same
> conclusion I have regarding the nature of your articles.
You should know better than to use the Kent Paul Dolan defense on
Usenet.
> I've wasted my time in treating your articles as
> a serious attempt to debate an issue.
Because you mistook my articles for an attempt to debate the issue you
were debating. I was talking about something different. But you still
just don't get it.
Fortunately, I can still express shortcutting in F77.
-- g
James Giles
Greg Lindahl wrote in message <6n8udk$1...@news3.newsguy.com>...
...
>Because you mistook my articles for an attempt to debate the issue you
>were debating. I was talking about something different. But you still
>just don't get it.
I have repeatedly stated as explicitly as I can that I understand
that you're talking about somethiong else. I'm saying so again
right now. You are talking about something different. Something
that was never in dispute.
>Fortunately, I can still express shortcutting in F77.
No one in this entire discussion has suggested, even indirectly, that
you could not express shortcutting. Nor (in the beginning) did anyone
suggest the you could not force the absence of shortcutting (that only
arose when it became evident that your original solution was itself
ambiguous in a related way - so presumably you've learned something
even if you haven't contributed in any useful way).
Since your position regarding the alternative constructs was *never*
in dispute, it is very difficult to understand the vehemence with which
you have conducted this discussion. Along the way you really have
convinced a large number of people that you actually think ambiguity
of the kind that *is* under discussion is a *good* idea. I don't care
if there is a Kent Paul Dolan (whoever that is) that have made similar
claims on other subjects. In this case, it is true - you really are
considered
by many to have made such a claim - repeatedly. Your consistent
opposition to this topic can only be taken as opposition to those
of us wanting to resolve the ambiguity. I really don't see any other
way to interpret your participation is this thread.
--
J. Giles
Ivan frohne
James Giles wrote in message <6n948r$h...@bgtnsc01.worldnet.att.net>...
>
>Greg Lindahl wrote in message <6n8udk$1...@news3.newsguy.com>...
>...
Dear Friends,
I started this thread. Can I stop it?
You two seem to be locked in an eternal embrace.
James calls Greg, who calls James ...
--Ivan Frohne
Jeff Drummond
In article <6n8stn$b...@bgtnsc01.worldnet.att.net>, "James Giles" <james...@worldnet.att.net> writes:
|> Greg Lindahl wrote in message <6n8o4d$2...@news1.newsguy.com>...
[ snip ]
|> I can now give up with the knowledge that I have
|> >completely wasted my time.
[ snip ]
|> I've wasted my time in treating your articles as
|> a serious attempt to debate an issue.
Now that you're both in agreement (that you're wasting your time; and
everyone else's, for that matter), I suppose it's too much to ask that
you let this poor horse rest in peace (or at least take it to email)?
Thanks,
-Jeff j...@cray.com
--
Usenet: where strawmen go to fight.
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> No one in this entire discussion has suggested, even indirectly, that
> you could not express shortcutting.
Good. I'll ignore the fact that you repeatedly said I couldn't, and we
can let this horse expire.
-- g
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> >Because they make what you're saying moot. But I said that before, too.
>
> Does the mere existence of other constructs (which I've already
> proven make no guarantees anyway) automatically fix legacy
> code that needs to be ported to new environments?
But of course you never said or implied that the shortcutting syntax
that I suggested would not work. I guess I don't read very well when I
convert your statement above to one about (1) shortcutting, and (2)
"always execute in this order", which I believe everyone agreed was
the case when you use subroutines.
-- g
Jim Klein
As Dilbert's boss said once:
"the words are all misspelled and there are too many semicolons"
I'll stay in the cave with my Fortran compiler.
Jim Klein
James Giles
Greg Lindahl wrote in message <6nbiug$7...@news1.newsguy.com>...
If you convert someone's statement you're always bound to be wrong
about its meaning. Why not just read what I said instead of converitng
it to something else? What I was talking about above was shortcutting
within *expressions*. Since it's not even possible to call a subroutine
within an expression, your 'conversion' of my statement is not sound.
What I, and everyone else, was talking about was an ambiguity
concerning *expressions*. No one said anything about multiple nested
IFs, subroutine calls, or any of the other things you brought up until
you made vehement claims that we were all wrong!
The fact remains that the Fortran standard's rules for evaluating
expressions which contain references to functions with side-effects
are ambiguous. Yes, you can rewrite your code so that it uses
subroutines instead of functions. You can rewrite with multiple
nested IF statements to force any shortcutting to occur (or not)
at your explicit control. No one in this discussion has ever suggested,
even indirectly, that you could not do so. No one has proposed
any changes to Fortran which would prevent you from continuing
to do so. No one has even suggested any changes which would alter
the interpretation of such alternative constructs in any way.
But, those *expressions* remain ambiguous. That's what we
were all talking about when you jumped into the discussion
claiming it was all a waste of time and that we were all wrong
to even consider addressing the problem. Your vehement opposition
to any discussion about a means to correct an ambiguity in the current
standard can only be interpreted as active support for the continued
presence of that ambiguity. That's just wrong. Active support
for an ambiguous language feature is something I will oppose
every time it occurs, and for as long as needed. It's simply one
of the worst language design ideas anyone can possibly have.
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> If you convert someone's statement you're always bound to be wrong
> about its meaning. Why not just read what I said instead of converitng
> it to something else? What I was talking about above was shortcutting
> within *expressions*.
I never talked about shortcutting with expressions; every time I
brought up the issue I explicitly stated that extra syntax was
required. If you were disproving something I said, and that's what you
claimed you did, you must have been talking about my shortcutting
syntax.
Given this, you'll have to forgive my confusion.
> The fact remains that the Fortran standard's rules for evaluating
> expressions which contain references to functions with side-effects
> are ambiguous.
Um, I never talked about that statement.
> Yes, you can rewrite your code so that it uses
> subroutines instead of functions. You can rewrite with multiple
> nested IF statements to force any shortcutting to occur (or not)
> at your explicit control. No one in this discussion has ever suggested,
> even indirectly, that you could not do so.
The text I quoted directly suggested that you could not do so. I'm
glad that you've now clarified your statement. It's a shame that it
took a few dozen postings to accomplish what 1 could do: I state that
today's Fortran has alternate syntax that gives you precision.
If you don't care about my statement, don't respond to it.
> But, those *expressions* remain ambiguous. That's what we
> were all talking about when you jumped into the discussion
> claiming it was all a waste of time and that we were all wrong
> to even consider addressing the problem.
I could care less how you spend your time.
I just wanted to point out that you're making a big ado about very
little.
> Your vehement opposition
> to any discussion about a means to correct an ambiguity in the current
> standard can only be interpreted as active support for the continued
> presence of that ambiguity.
If I'm not with you, I must be against you? How funny.
-- g
James Giles
Greg Lindahl wrote in message <6nchr7$e...@news3.newsguy.com>...
>I never talked about shortcutting with expressions; every time I
>brought up the issue I explicitly stated that extra syntax was
>required. If you were disproving something I said, and that's what you
>claimed you did, you must have been talking about my shortcutting
>syntax.
I never said I disproved anything you said about shortcutting.
I *did* disprove your original method of *preventing* shortcutting.
You did not understand that functions may, or may not be called
no matter where or how they are referenced. That is the only
thing you've said that I've ever claimed to have disproved in
this whole thread.
As for your "shortcutting syntax": you've never posted any.
Shortcutting, as the word itself implies, is when the optimizer
decides not to do something that the code, taken at face value,
requires. Your examples involving multiple nested IFs involve
no shortcutting. They are using the IFs as their explicit definition
requires. Neither the optimizer, nor any other part of the
implementation is able to make any changes to that sequence.
I pointed this out the first time you posted an example of
multiple nested IFs. The examples you gave have no relevance
to any discussion about shortcutting - since your alternative
constructs involve no potential for shortcutting to occur.
(Yes, in discussing this issue in this thread, I find that
I've fallen into the sloppy semantic practice of calling
your explicit multiple IFs a form of "shortcutting" - as
in the quote you include below. What I should have
said was that you could force the same operational
behavior as a shortcut expression would give by using
explicit alternative means.)
Now, your techniques are perfectly reasonable (as I've also
pointed out before) for someone to use who has already
discovered that the compiler is (or might be) doing undesired
things to expressions. This is of use only *after* the programmer
has discovered the problem and does not address the language
design issue. The fact that there's a verbose, less legible, alternative
means of accomplishing what you should reasonably expect
the expressions themselves to do is useful as a temporary
workaround. Better would be to have the language standard
explicitly remove the problem. A workaround for a problem
is not nearly as good as not having the problem in the first
place.
The rest of us were talking about shortcutting - the optimizer
leaving out operations which the code itself actually references. This
happens (in ways relevant to this discussion) *only* in *expressions*.
>> The fact remains that the Fortran standard's rules for evaluating
>> expressions which contain references to functions with side-effects
>> are ambiguous.
>
>Um, I never talked about that statement.
That's the only thing the rest of us were talking about. Further, this
is a new claim on your part. In the past you have persistently claimed
that you covered the topic thoroughly in a previous thread and people
should go back and read that and stop wasting your time. Now you
are claiming never to have talked about the *only* topic this thread
was ever intended to address.
>> Yes, you can rewrite your code so that it uses
>> subroutines instead of functions. You can rewrite with multiple
>> nested IF statements to force any shortcutting to occur (or not)
>> at your explicit control. No one in this discussion has ever suggested,
>> even indirectly, that you could not do so.
>
>The text I quoted directly suggested that you could not do so. [...
No, it didn't.
> ...]
I'm
>glad that you've now clarified your statement. [...
As far as I'm aware, you are the only one claiming that my
position needed clarification. And this is a new claim on your
part, or do I have to search for the quote in which you said
you understood my position quite clearly an thought my point
was moot?
> ...] It's
a shame that it
>took a few dozen postings to accomplish what 1 could do: I state that
>today's Fortran has alternate syntax that gives you precision.
>If you don't care about my statement, don't respond to it.
You also stated that the rest of us were wasting our time, and
in quite vehement terms. I don't care for you posting suggestions
irrelevant to the topic under discussion and then claiming that those
off-topic suggestions prove that the problem the rest of us *are*
addressing is moot. I've said this before - numerous times.
>> But, those *expressions* remain ambiguous. That's what we
>> were all talking about when you jumped into the discussion
>> claiming it was all a waste of time and that we were all wrong
>> to even consider addressing the problem.
>
>I could care less how you spend your time.
Then don't post vehemently worded articles that oppose
how we spend our time.
>I just wanted to point out that you're making a big ado about very
>little.
It's a significant problem. Whether *you've* experienced it or not
is irrelevant. Indeed, many people who've had the problem had it
for *years* before they even realized there was an error. Years
of wrong results that have to be recomputed is not a minor problem.
In fact, since your original suggestion for how to avoid shortcutting
was itself ambiguous for related reasons it seems likely to me that
you have a lurking problem in your own code.
>> Your vehement opposition
>> to any discussion about a means to correct an ambiguity in the current
>> standard can only be interpreted as active support for the continued
>> presence of that ambiguity.
>
>If I'm not with you, I must be against you? How funny.
No. If you explicitly, and vehemently, say that you're against
us, you must be against us. It's really comical to see you now
claiming not to have done so.
--
J. Giles
Greg Lindahl
"James Giles" <james...@worldnet.att.net> writes:
> I never said I disproved anything you said about shortcutting.
I quoted it before.
> I *did* disprove your original method of *preventing* shortcutting.
Which is trivially fixed by using subroutines.
> As for your "shortcutting syntax": you've never posted any.
if (first()) then
if (second()) then
...
This is shortcutting as most people understand it, and in fact is an
exact representation of what the C expression (a() && b()) does. If
you continue to make such absolute and yet incomprehensible
statements, it's no surprise that people have a hard time
understanding what you're saying.
> Shortcutting, as the word itself implies, is when the optimizer
> decides not to do something that the code, taken at face value,
> requires.
No, the C code (a() && b()) does not "at face value" require b to be
called. That is human language semantics.
> Now, your techniques are perfectly reasonable (as I've also
> pointed out before)
Then why do you continue to respond to my posts?
> The rest of us were talking about shortcutting -
That horse is dead. Stop beating it.
> In the past you have persistently claimed
> that you covered the topic thoroughly in a previous thread and people
> should go back and read that and stop wasting your time.
Wrong -- I said other people covered similar topics in a previous
thread, one that you could use a good re-read of. I don't believe I
posted much in that earlier thread.
> Now you
> are claiming never to have talked about the *only* topic this thread
> was ever intended to address.
Who cares what you intended? I have never discussed what you intended,
and no one cares if I was on your topic or not.
> You also stated that the rest of us were wasting our time,
No, only you. Please stop broadening my statments.
> I don't care for you posting suggestions
> irrelevant to the topic under discussion and then claiming that those
> off-topic suggestions prove that the problem the rest of us *are*
> addressing is moot. I've said this before - numerous times.
Well, gee, you have a right to your opinion, and you've said this
enough times that I'm sure everyone heard you.
> >I could care less how you spend your time.
>
> Then don't post vehemently worded articles that oppose
> how we spend our time.
I think you're very confused.
> >If I'm not with you, I must be against you? How funny.
>
> No. If you explicitly, and vehemently, say that you're against
> us, you must be against us. It's really comical to see you now
> claiming not to have done so.
I never said I was against you. Go away.
-- g
Jeff Templon
Hey Guys,
[ guys meaning James and Greg ]
If you didn't often post useful articles as well, you'd be in my
kill file by now.
Any chance you could move this to email, or alt.flame?
JAT
Greg Lindahl
Jeff Templon <tem...@studbolt.physast.uga.edu> writes:
> If you didn't often post useful articles as well, you'd be in my
> kill file by now.
OK, I'll post from a special Giles-baiting address in the future so
you can kill all those postings.
-- g