Surprise

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> For assumed size, it is usual
> to use a REAL dummy array.

[with a complex actual argument - at least that's what I assume this is
referring to]

Note that this hack is and has always been nonstandard. Yes, it will
usually work, and yes I know it has often been done. Those are different
things. In fact, it was often enough done that I recall once thinking
that it must be valid as a special case exception to the type agreement
rules for arguments. But unless I am blind, there has never been such a
special case in the standard. If it's there, I'd like to know. That's
not a request to explain all the systems on which it works and has been
used; I know about that. I am specifically talking about the Fortran
standard(s) and only the standard(s) (and not DF's definition of
"standard".)

I'm slightly reluctant to post to this thread at all. I certainly won't
respond to the OP (specifically, I sure won't respond if he in turn
replies to this). In spite of his claims not to be a troll, if it walks
like a duck and quacks like a duck... Maybe he even honestly thinks he
isn't trolling; in the end, that doesn't matter. That would just
indicate that he doesn't know what counts as trolling.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

kronecker@yahoo.co.uk wrote:
(snip)

> Not at all. I moved from Fortran to C and it was crap. No complex
> numbers. This was around 1987 of course. Having to write my own
> structures of complex numbers was just daft whenyou had them built in.
> I am not a troll and have used Fortran for around 20 years ...in fact
> more like 25 years. Is it now OO?

They were added to the C standard in 1999. 1987 was even
before ANSI C in 1989.

It might be that compilers implementing full C99 are arriving
even slower than Fortran 2003 compilers.

Even so, much Fortran work with complex numbers is not done
using complex variables. It is usual to write FFT routines
using real variables. It might be that the dummy array
for assumed shape has to be complex, but the rest of the
calculation is often done using separate variables for the
real and imaginary parts. For assumed size, it is usual
to use a REAL dummy array.

-- glen

kronecker@yahoo.co.uk wrote:
> Gosh, this was a big surprise. I though Fortran was dead as a Dodo!
> Why are people still using it? I was a great fan of it until about
> 1997 when I moved to Matlab...then LabView. Why the need to resurect
> Fortran? Yes, I know C is shite, has no complex numbers etc but that's
> not an excuse.
>
>
> K.

What a surprisingly foolish post!

glen herrmannsfeldt wrote:
....
> In PL/I you can do:
>
> REAL(X(I))=REAL(X(J));
>
> in Fortran, it would seem to be:
>
> X(I)=CMPLX(REAL(X(J),AIMAG(X(I),KIND(X))

As of F2008 you can write:

X(I)%RE = X(J)%RE

(The corresponding component for the imaginary part is
%IM.)

I like that a *lot* better than PL/I's function-like syntax.
I'm hoping this will be a feature implemented sooner than
even parts of F2003.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra

Richard Maine wrote:
(I wrote)

>>For assumed size, it is usual to use a REAL dummy array.

> [with a complex actual argument - at least that's what I assume this is
> referring to]

> Note that this hack is and has always been nonstandard. Yes, it will
> usually work, and yes I know it has often been done. Those are different
> things. In fact, it was often enough done that I recall once thinking
> that it must be valid as a special case exception to the type agreement
> rules for arguments. But unless I am blind, there has never been such a
> special case in the standard.

I don't think I ever found it, either. I do believe that the
standard requires the real and imaginary parts to be stored
sequentially, real part first. (I haven't looked for it recently.)

The main case where I might expect it not to work is when doing
bounds checking. In the case of a dummy dimensioned (1) bounds
checking usually fails, anyway.

Otherwise, how do you separately assign to the real or imaginary
parts of a complex array element?

In PL/I you can do:

REAL(X(I))=REAL(X(J));

in Fortran, it would seem to be:

X(I)=CMPLX(REAL(X(J),AIMAG(X(I),KIND(X))

Maybe compilers can figure that one out.

-- glen

James Giles <jamesgiles@worldnet.att.net> wrote:

> glen herrmannsfeldt wrote:
> >
> > X(I)=CMPLX(REAL(X(J),AIMAG(X(I),KIND(X))
>
> As of F2008 you can write:
>
> X(I)%RE = X(J)%RE
>
> (The corresponding component for the imaginary part is
> %IM.)
>
> I like that a *lot* better than PL/I's function-like syntax.
> I'm hoping this will be a feature implemented sooner than
> even parts of F2003.

I like this feature also. Among other things, it is also valid if, for
example, the imaginary part is undefined at the time.

And I haven't checked to be sure, but I think that with this feature it
will be perfectly legit to do such things as use x%re as an actual
argument for a dummy real. I can't think of any reason why it wouldn't
be ok. That doesn't work for the existing Fortran real and aimag
intrinsics if the dummy argument mught be modified (and it has a chance
of causing a temporary copy even in cases where the dummy argument is
not modified).

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Richard Maine wrote:
....
> And I haven't checked to be sure, but I think that with this feature
> it will be perfectly legit to do such things as use x%re as an actual
> argument for a dummy real. [...]

An actual argument can be a variable. A variable can be a
designator. And a designator can be a complex-part-designator.
So yes, a complex-part-designator can be used as an actual
argument.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra

On Aug 20, 8:56 am, Gib Bogle <bo...@ihug.too.much.spam.co.nz> wrote:
> kronec...@yahoo.co.uk wrote:
> > Gosh, this was a big surprise. I though Fortran was dead as a Dodo!
> > Why are people still using it? I was a great fan of it until about
> > 1997 when I moved to Matlab...then LabView. Why the need to resurect
> > Fortran? Yes, I know C is shite, has no complex numbers etc but that's
> > not an excuse.
>
> > K.
>
> What a surprisingly foolish post!

Why? Fortran was a great language for maths there is no doubt...but it
has had its day now surely.
Even C++ is being replaced by many industries with C#. Pascal is dead
too and Modula2. I remember them all.
None of them was as good as Fortran but I wouldn't dream of using it
now. Most scientific algorithms have moved across to libraries in
other languages. I expect oldies like myself who were never taught
formal programming except part of a maths syllabus would like to hold
on to it but...no. 15 years ago I would have died for Fortran but now
we have mathematica,matlab,mathcad etc etc why the hell would I bother
at all? For supercomputing maybe but the vast majority of applications
no. Let's examine it closely

Maths...yes definately..far superior to all languages.
Graphics...never.
Embedded systems...never in a million years.
Ascii text...not really
compilers..you kiddin!
AI...never.

So it has one main application..Maths number crunching which was what
it was invented for. If I was simulating with a parallel super-
computer I might use parallel fortran but for most smaller
applications..not on your Nelly!


K.

On Aug 20, 8:29*am, kronec...@yahoo.co.uk wrote:
> On Aug 20, 8:56 am, Gib Bogle <bo...@ihug.too.much.spam.co.nz> wrote:
>
> > kronec...@yahoo.co.uk wrote:
> > > Gosh, this was a big surprise. I though Fortran was dead as a Dodo!
> > > Why are people still using it? I was a great fan of it until about
> > > 1997 when I moved to Matlab...then LabView. Why the need to resurect
> > > Fortran? Yes, I know C is shite, has no complex numbers etc but that's
> > > not an excuse.
>
> > > K.
>
> > What a surprisingly foolish post!
>
> Why? Fortran was a great language for maths there is no doubt...but it
> has had its day now surely.
> Even C++ is being replaced by many industries with C#. Pascal is dead
> too and Modula2. I remember them all.
> None of them was as good as Fortran but I wouldn't dream of using it
> now. Most scientific algorithms have moved across to libraries in
> other languages.

As far as I know, many high levels softwares like Matlab and R still
use BLAS et similia which are all F77.

I expect oldies like myself who were never taught
> formal programming except part of a maths syllabus *would like to hold
> on to it but...no. 15 years ago I would have died for Fortran but now
> we have mathematica,matlab,mathcad etc etc why the hell would I bother
> at all? For supercomputing maybe but the vast majority of applications
> no. Let's examine it closely
>
> Maths...yes definately..far superior to all languages.
> Graphics...never.
> Embedded systems...never in a million years.
> Ascii text...not really
> compilers..you kiddin!
> AI...never.
>
> So it has one main application..Maths number crunching which was what
> it was invented for. If I was simulating with a parallel super-
> computer I might use parallel fortran but for most smaller
> applications..not on your Nelly!
>
> K.

I think you miss a fundamental point which may answer to your question
(if yours was ever a question).
FORTRAN (as well C C++ etc..) code can be integrated easily into
Matlab, R etc, and many (everyday) scientific computing problems
require the benefits of FORTRAN over the inefficiency of high level
software.
As an aside, some years ago I was involved in a project that required
working with odesolvers. I was using the "powerful" Matlab while my
older colleague was implementing the same work in FORTRAN (actually
F77). Well, the results were different and guess what? Matlab was
wrong as its loss of precision on chaotic trajectories led to
incorrect results.
If you had documented yourself a bit you would not have been
surprised.


Regards,

Simone

kronecker@yahoo.co.uk wrote:
> For supercomputing maybe but the vast majority of applications
> no.

Exactly.

For the vast majority of applications I'd never use Fortran.

But I don't use Fortran to write the vast majority of applications. I
use Fortran to write applications where I've found that it's the best
language to use. No one language will _ever_ be the answer for every
application, or even for the vast majority, so I'm not sure quite why
you're surprised that a language which, surprise surprise, is good for
some things but not others, is still alive and kicking. Every single
language out there is in exactly the same boat.

And number crunching is hardly _one_ application, or limited to
supercomputers, regardless of the language being used.

--
Catherine Rees Lay

Polyhedron Software Ltd. Registered Office: Linden House,
93 High St, Standlake, Witney, OX29 7RH, United Kingdom.
Registered in England No.2541693. Vat Reg No. GB 537 3214 57