why different MAX and MAXVAL in f90 ?
Richard Moss
Couldn't they (and logically shouldn't they) be rolled into one?
Why can't you do something like:
real, dimension(20) :: a
real :: maxn
maxn = max( a )
when now you have to do:
maxn = maxval( a )
But you _can_ do:
maxn = max( a, a )
or
maxn = max( 1.0, a )
gracias,
Richard
Prof. Loren Meissner
>
> I was wondering why there are two separate functions MAX and MAXVAL.
> Couldn't they (and logically shouldn't they) be rolled into one?
>
> Why can't you
I used to tell my kids I would never answer any question they ask
that begins with "Why did God ..."
On comp.lang.fortran the rule should be somewhat similar. There is no
way to answer "Why does Fortran ..." or "Why doesn't Fortran ..."
It probably came up at a committee meeting once and did not get enough
support.
======
If you really mean that you would like to see some changes made in
future versions of Fortran, you can make some suggestions. Fortran 95
is pretty much "water under the bridge", proposals for F2000 are now
being seriously considered; there will also be a couple of interim
updates in the form of "technical reports."
Here is an old version of the instructions (from Fortran Forum, Sep 93)
Submit a "Proposed Fortran Requirement" by email to
x3...@ncsa.uiuc.edu
or on paper [this is a current address 11/95]:
X3J3 JOR Subgroup
c/o X3J3 Secretary
Prof. C. M. North, Box 150
Rose-Hulman Institute
Terre Haute IN 47803]
Proposal should be 1-2 pages long and include:
Title (1 line)
Requirement -- succinct but complete description of functionality
Justification -- such as: how would users benefit? how is it better
than existing features? how would it impact existing codes?
Other
--Loren Meissner
Robert Hamilton
> If you really mean that you would like to see some changes made in
> future versions of Fortran, you can make some suggestions. Fortran 95
> is pretty much "water under the bridge", proposals for F2000 are now
> being seriously considered; there will also be a couple of interim
> updates in the form of "technical reports."
>
While you are on the subject, I am curious about something....
Is there any movement at all toward object-oriented Fortran?
Also, perhaps you could tell us a little bit about Fortran 95!
What's in the works?
Robert
Prof. Loren Meissner
>
> Is there any movement at all toward object-oriented Fortran?
>
> Also, perhaps you could tell us a little bit about Fortran 95!
> What's in the works?
To answer your second question first, F95 seems to be well on its
way to standardization -- probably some (nearly) final actions will
be taken at the WG5 (international) and X3J3 (USA) standards committee
meetings between Nov 6 and 17. Right now, they seem to be moving
commas around.
The F95 draft was published as the June 95 issue of Fortran Forum;
copies while they last are available (cheap) from ACM...@ACM.ORG
F95 is a "minor upgrade" of F90. It has 3 "biggies": FORALL, PURE procedures,
and default initialization of structures and pointers. A longer list
appeared in Fortran Forum March 95 p 37:
--IEEE arithmetic conformance (negative zero, inf, NaNs)
--Initialization (biggie #3)
--Deallocation of allocatable arrays at procedure exit
--User-defined functions in specification expressions
--Nested WHERE constructs
--FORALL and PURE (biggies #1 and #2)
--Minimal field width on edit descriptors
--Comments in NAMELIST
--User-defined elemental procedures
--CPU_Time intrinsic
--MAXLOC etc. sometimes return scalar result
=================
Between F95 and F2000, there will be perhaps 3 interim "technical
reports", covering:
-- Floating Point Exception Handling
-- Enhanced Derived Types (allocatable components and parameterized types)
-- Interoperability with C
The second one may have hit a snag, however.
=================
X3J3 has a subgroup on Object-Oriented Programming. I think there are
definite plans to put something in Fortran 2000.
=================
A good way to keep up with this sort of thing is to subscribe to
Fortran Forum ($10 per year if you are an ACM member; otherwise $20)
<ACM...@ACM.ORG>
-- or subscribe to Fortran Journal ($28) <wa...@fortran.com>
--Loren Meissner
(Editor, Fortran Forum)
boroczky
>Richard Moss <r...@seymour.chem.ubc.ca> wrote:
>>
>> I was wondering why there are two separate functions MAX and MAXVAL.
>> Couldn't they (and logically shouldn't they) be rolled into one?
>>
>> Why can't you
>
>I used to tell my kids I would never answer any question they ask
>that begins with "Why did God ..."
>
>On comp.lang.fortran the rule should be somewhat similar. There is no
>way to answer "Why does Fortran ..." or "Why doesn't Fortran ..."
>
>It probably came up at a committee meeting once and did not get enough
>support.
>
I did not see the original posting, but assume from the snippet included that
Richard Moss feels similar to myself.
Till now, I have not had much exposure to F90, but am currently working through
Digital's Language Reference Manual. A gap of about 14 years between standards
obviously meant that a lot of new features were added. But the plethora of new
intrinsics makes me wonder whether it was just a case of everyone throwing into the
pot what they thought might be useful.
The two mentioned in this topic are an excellent example of overkill (to at least me
and seemingly to Richard). Since MAX as it stands requires at least two simple
variables, then a call with one variable can be taken to be a MAXVAL where the
argument is an array (the compiler can check me on this). DIM and MASK, if required,
are keywords so there should be no problem there. O.K., a bit more work for the
compiler writers, but less learning for the programmers.
An extension to the topic question is why MAXVAL and MAXLOC? Years ago when I was
working on an in-house library, a similar problem arose. Do we provide a routine to
return the value, the index or both (a single or separate routines)? And we need
this for each type, so how many routines do we write and maintain???
Since the user of the in-house library could trivially find a MAXVAL from a MAXLOC
routine, it was decided only to provide the latter. No complaints, evryone was happy
to write MAXVALA = A(MAXLOC(A)).
Regards, Paddy O'Brien
(Using a colleagues account)
Prof. Loren Meissner
> An extension to the topic question is why MAXVAL and MAXLOC? Years ago when I was
> working on an in-house library, a similar problem arose. Do we provide a routine to
> return the value, the index or both (a single or separate routines)? And we need
> this for each type, so how many routines do we write and maintain???
>
> Since the user of the in-house library could trivially find a MAXVAL from a MAXLOC
> routine, it was decided only to provide the latter. No complaints, evryone was happy
> to write MAXVALA = A(MAXLOC(A)).
It's a good idea, but you have to be careful about defining what happens
in special cases. Remember that F90 permits a MASK: MaxLoc(A, MASK = A < Key)
finds the largest element of A that is less than Key, which might give
a nice way to search in an ordered array. However, there may be no TRUE
elements of MASK -- what then??
I think that part of the reason for redundant intrinsics has to do
with special cases such as empty arrays or empty masks etc.
--Loren Meissner
Leonard J. Moss
boroczky <boro...@interconnect.com.au> wrote:
>...
>>Richard Moss <r...@seymour.chem.ubc.ca> wrote:
>>>
>>> I was wondering why there are two separate functions MAX and MAXVAL.
>>> Couldn't they (and logically shouldn't they) be rolled into one?
>>>
>>...
>...
>
>I did not see the original posting, but assume from the snippet included that
>Richard Moss feels similar to myself.
>
>Till now, I have not had much exposure to F90, but am currently working
through
>Digital's Language Reference Manual. A gap of about 14 years between standards
>obviously meant that a lot of new features were added. But the plethora of new
>intrinsics makes me wonder whether it was just a case of everyone
throwing into the
>pot what they thought might be useful.
>
>The two mentioned in this topic are an excellent example of overkill (to
at least me
>and seemingly to Richard). Since MAX as it stands requires at least two simple
>variables, then a call with one variable can be taken to be a MAXVAL where the
>argument is an array (the compiler can check me on this). DIM and MASK,
if required,
>are keywords so there should be no problem there. O.K., a bit more work
for the
>compiler writers, but less learning for the programmers.
Requiring the DIM keyword to disambiguate MAX and MAXVAL calls would be
highly irregular -- no other procedures, intrinsic or user-defined require
the use of keyword arguments unless a preceding positional argument is
omitted (the MASK argument, on the other hand, must be of type LOGICAL and
so could be distinguished without the keyword). Without a required DIM
keyword, there would be a definite ambiguity; given a 2x3 array A with the
value,
[ 0 3 2 ]
[ 4 1 5 ]
then MAX( A, 1 ) and MAX( A, 2 ) are the 2x3 arrays,
[ 1 3 2 ] and [ 2 3 2 ]
[ 4 1 5 ] [ 4 2 5 ]
whereas MAXVAL( A, 1 ) and MAXVAL( A, 2 ) are the vectors,
[ 4 3 5 ] and [ 3 5 ]
respectively.
IMHO it would be coneptually very confusing to overload an elemental and
an array reduction intrinsic function.
>
>An extension to the topic question is why MAXVAL and MAXLOC? Years ago
when I was
>working on an in-house library, a similar problem arose. Do we provide a
routine to
>return the value, the index or both (a single or separate routines)? And
we need
>this for each type, so how many routines do we write and maintain???
>
>Since the user of the in-house library could trivially find a MAXVAL from
a MAXLOC
>routine, it was decided only to provide the latter. No complaints,
evryone was happy
>to write MAXVALA = A(MAXLOC(A)).
The MAXLOC function always returns an integer vector, which Fortran 90
does not permit you to use as you suggest, i.e., as the _complete_
subscript list to select a single element from an array. Instead, F90
permits integer vectors to be used as _single_ subscripts to specify
arbitrarily permuted array sections ("vector-valued subscripts"). Thus,
if only MAXLOC were provided, you'd have to do something like,
INTEGER :: INDEX( n ), A( d_1, ..., d_n )
...
INDEX = MAXLOC( A )
MAXVALA = A( INDEX( 1 ), ..., INDEX( n ) )
to obtain the value of the largest element of A.
In principle, I don't think there would be any syntactical ambiguity if
F90 permitted vector subscripts to be used both ways, i.e., either as a
complete subscript list or as a single subscript. However, I think using
such similar syntax for two quite different functionalities would be quite
confusing. On the other hand, inventing some new syntax to permit an
index vector to be used to select a single element from an array might be
quite useful. If nothing else, how about an ELEMENT intrinsic function?
I'll leave the invention of a more compact syntax as an exercise for the
reader (but here's a hint: try to avoid using ASCII "national-use"
characters like square brackets ;-).
>
>Regards, Paddy O'Brien
>(Using a colleagues account)
--
Leonard J. Moss <l...@slac.stanford.edu> | My views don't necessarily
Stanford Linear Accelerator Center | reflect those of SLAC,
MS 97; P.O. Box 4349; Stanford, CA 94309 | Stanford or the DOE