Intrinsoc function as argument to intrinsic function question
Author Message
Intrinsoc function as argument to intrinsic function question

Hello there,

Can someone f90-standard-wise tell me if

number = MINLOC( SUM( the_array, DIM=2 ) )

is a legal statement given:

INTEGER, PARAMETER :: fp_kind = SELECTED_REAL_KIND( 15 )
INTEGER, PARAMETER :: M = 10, K = 20

INTEGER, DIMENSION( 1 ) :: number
REAL( fp_kind ), DIMENSION( M, K ) :: the_array

and "the_array" is actually filled with something useful?

A number of platforms process the statement quite happily (i.e. I get the
correct result I expected), but one does not (I get a result and it's
incorrect.) I guess I'm asking for info on how one is allowed to use various
intrinsic functions as arguments (as with the SUM above.) I looked in all the
f90 books I have but couldn't find anything that says something like "you cannot
use these intrinsic functions as arguments".

If the above *is not* allowed, does that any implications for the
standard-conforming-ness of the compilers on the platforms where it is executed
correctly? I know I shouldn't use compilers as de{*filter*}s, but this seems (to me)
like such a subtle point that finger-burning is likely (for those who use a
multitude of different platforms at least).

Thanks for any info.

cheers,

paulv

--
Paul van Delst           A little learning is a dangerous thing;

Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
Alexander Pope.

Wed, 14 Jan 2004 07:27:16 GMT
Intrinsoc function as argument to intrinsic function question

Quote:
> Can someone f90-standard-wise tell me if
>   number = MINLOC( SUM( the_array, DIM=2 ) )
> is a legal statement given:

[reasonable-looking declarations elided]

Looks perfectly ordinary to me.

Quote:
> I guess I'm asking for info on how one is allowed to use various
> intrinsic functions as arguments (as with the SUM above.) I looked in all the
> f90 books I have but couldn't find anything that says something like "you cannot
> use these intrinsic functions as arguments".

You aren't likely to find discussions like that.  There aren't any
restrictions on what kinds of expressions you can use as arguments.
About the only relevant restrictions relate to the fact that what you
have is an expression rather than a variable.  This places limits on
the dummy argument.  For example, the dummy can't be intent(out),
intent(inout), a pointer, or a couple of other things that really
don't make any sense with expressions as actual arguments (for
example, the dummy couldn't be a dummy procedure).  But these
limitations just have to do with the actual argument being an
expression at all - the details of the expression don't matter.

I'd place reasonable odds that you are running into a compiler bug.
Although what you wrote is legal (unless I missed something, in which
case I'm sure I'll be corrected), it's implementation does imply a
compiler-generated temporary array (either that or a compiler smart enough
to recognize how to optimize this).  It's not unusual for compilers to
have bugs in that area.

--
Richard Maine
email: my last name at domain
domain: qnet dot com

Wed, 14 Jan 2004 08:55:28 GMT
Intrinsoc function as argument to intrinsic function question

Quote:
> I'd place reasonable odds that you are running into a compiler bug.
> Although what you wrote is legal (unless I missed something, in which
> case I'm sure I'll be corrected), it's implementation does imply a
> compiler-generated temporary array (either that or a compiler smart enough
> to recognize how to optimize this).  It's not unusual for compilers to
> have bugs in that area.

Although I would bet on your side here, there is the possibility
also that Paul has two rows, say row i and row j, such that
abs(sum(the_array(i,:))-sum(the_array(j,:))) is not much
bigger than spacing(maxval(abs(the_array((/i,j/),:)))), that
is to say, two of the elements of sum(the_array,2) are close
to each other.  In that case, different compilers could compute
the row sums in different orders (for example one compiler
might add the elements up one at a time for simplicity
while another might choose to execute the sums using four
accumulators, adding up the four partial sums at the end
to cover up the latency of fp addition) and so they could
arrive at slightly different sums.  If the sums are close
enough to each other in the first place, this could affect
their order as tested by MINLOC.

Wed, 14 Jan 2004 09:47:47 GMT
Intrinsoc function as argument to intrinsic function question

Quote:

> > I'd place reasonable odds that you are running into a compiler bug.
> > Although what you wrote is legal (unless I missed something, in which
> > case I'm sure I'll be corrected), it's implementation does imply a
> > compiler-generated temporary array (either that or a compiler smart enough
> > to recognize how to optimize this).  It's not unusual for compilers to
> > have bugs in that area.

> Although I would bet on your side here, there is the possibility
> also that Paul has two rows, say row i and row j, such that
> abs(sum(the_array(i,:))-sum(the_array(j,:))) is not much
> bigger than spacing(maxval(abs(the_array((/i,j/),:)))), that
> is to say, two of the elements of sum(the_array,2) are close
> to each other.  In that case, different compilers could compute
> the row sums in different orders (for example one compiler
> might add the elements up one at a time for simplicity
> while another might choose to execute the sums using four
> accumulators, adding up the four partial sums at the end
> to cover up the latency of fp addition) and so they could
> arrive at slightly different sums.  If the sums are close
> enough to each other in the first place, this could affect
> their order as tested by MINLOC.

True, I could see that happening. But I don't think that the problem I'm having
here. There doesn't appear to be any ambiguity in what the result should be as
the elements of summed vector are values that are quite different (see below.)
The array (a Hilbert matrix) is created:

INTEGER, PARAMETER :: fp_kind = SELECTED_REAL_KIND( 15 )
INTEGER, PARAMETER :: M = 10, K = 20
REAL( fp_kind ), PARAMETER :: ONE = 1.0_fp_kind

INTEGER :: im, ik
INTEGER, DIMENSION( 1 ) :: number

REAL( fp_kind ), DIMENSION( M, K ) :: the_array
REAL( fp_kind ), DIMENSION( M )    :: the_vector
REAL( fp_kind ) :: rm, rk

INTRINSIC SUM, MINLOC, REAL

DO ik = 1,K
rk = REAL( ik, fp_kind )
DO im = 1,M
rm = REAL( im, fp_kind )
the_array(im,ik) = ONE / ( rm + rk - ONE )
END DO
END DO

and the statements:

the_vector = SUM( the_array, DIM=2 )
number = MINLOC( the_vector )

produce the correct result:
VECTOR RESULT
-------------
The values:
3.5977396571436819,  2.6453587047627298,  2.1908132502172744,
1.9009581777535067,  1.6926248444201735,  1.5326248444201738,
1.4044197162150456,  1.2985996103949398,  1.2093138961092256,
1.1326855436188039

The result:
MINLOC M-index:  10
M-index= 10   Sum result= 1.1326855436188039

but foregoing the variable "the_vector":

number = MINLOC( SUM( the_array, DIM=2 ) )

produces an incorrect result.

ARRAY SLICE RESULT
------------------
The values:
3.5977396571436819,  2.6453587047627298,  2.1908132502172744,
1.9009581777535067,  1.6926248444201735,  1.5326248444201738,
1.4044197162150456,  1.2985996103949398,  1.2093138961092256,
1.1326855436188039

The result:
MINLOC M-index:  1
M-index= 1   Sum result= 3.5977396571436819

I have been in contact when the vendor and have been told that the manual states
(quoting from thier email) "SUM is a transformational intrinsic function.  The
name of this intrinsic cannot be passed as an argument."

What I wanted to know was if this is was specifically mentioned in the standard.
THe inpression I get is that it's not but does that mean if a compiler vendor
decides to not allow an expression containing the SUM intrinsic (and,
presumably, other intrinsic functions) as arguments, it's "o.k.?" That is, is
the compiler standard conforming? I am, sadly, assuming it is as in the recent
past someone (I think maybe Richard Maine or James Giles or Dan Nagle or{*filter*}
Hendrikson) mentioned that the fortran standard is an inclusionary rather than
inclusionary document. Given that, it still would surprise me if the compiler in
question doesn't accept the latter example above for no apparent reason (to me)
other than that's how it was implemented.

My original question was worded the other way, i.e. if it *is* allowed, does
that violate the standard in some way, because the software engineer knows more

cheers,

paulv

--
Paul van Delst           A little learning is a dangerous thing;

Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
Alexander Pope.

Fri, 16 Jan 2004 20:38:21 GMT
Intrinsoc function as argument to intrinsic function question
Quote:

> What I wanted to know was if this is was specifically mentioned in the standard.
> THe inpression I get is that it's not but does that mean if a compiler vendor
> decides to not allow an expression containing the SUM intrinsic (and,
> presumably, other intrinsic functions) as arguments, it's "o.k.?" That is, is
> the compiler standard conforming? I am, sadly, assuming it is as in the recent
> past someone (I think maybe Richard Maine or James Giles or Dan Nagle or{*filter*}
> Hendrikson) mentioned that the fortran standard is an inclusionary rather than
> inclusionary document.

^^

Nuts.

paulv

--
Paul van Delst           A little learning is a dangerous thing;

Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
Alexander Pope.

Fri, 16 Jan 2004 20:58:12 GMT
Intrinsoc function as argument to intrinsic function question

| I have been in contact when the vendor and have been told that the manual
states
| (quoting from thier email) "SUM is a transformational intrinsic function.  The
| name of this intrinsic cannot be passed as an argument."

My understanding of that quote is that you cannot pass SUM where
EXTERNAL is expected, but *can* where an scalar/array is expected. Let's
consider
the case when SUM returns a scalar:

I = NINT(SUM(x(1:10)))

This is apparently allowed. For the reason of symmetry, SUM which returns
an array (operating on a matrix argument) has to be allowed too. Now, either
I'm ignorant, or their tech support is ignorant (not to mention worse
possibilities)?

Jugoslav

Fri, 16 Jan 2004 21:14:38 GMT
Intrinsoc function as argument to intrinsic function question

Quote:
>   INTRINSIC SUM, MINLOC, REAL

CVF 6.5A objects to this. If I uncomment this line, both versions of the code
generate the correct result. Also, it is clear that at least this particular
example is not numerically unstable, as was suggested by somebody else.

I think 187.facerec would fail to compile if the reason you were given was
correct.

Jan

Fri, 16 Jan 2004 22:26:13 GMT
Intrinsoc function as argument to intrinsic function question

Quote:
> I have been in contact when the vendor and have been told that the manual states
> (quoting from thier email) "SUM is a transformational intrinsic function.  The
> name of this intrinsic cannot be passed as an argument."

That frankly leaves me most unimpressed with whoever the vendor is.  If they
do that poor a job of reading standard-speak, then its going to be pretty
rough going for them in the parts that are actually tricky.  This one isn't.

Nor is this some new, complicated f90 thing.  I suppose the next thing
they will tell you is that you can't pass real(42) as an actual
argument.  (You cannot pass the name of the REAL intrinsic as an
actual argument).

The name of the function is not being passed as an argument in your case.
The name of the function in question is SUM.  It is not
"SUM(a-bunch-of-stuff)".  What is being passed as an actual argument
is an expression, not a name.

Anything that talks about passing a function (or the name of a
function - both phrases are used) as an actual argument is talking
about passing the function itself - not an expression that happens to
use the function.  There are indeed restrictions on passing some
functions as actual arguments - mostly issues involving things that
are normally done at compile time, but can't easily be so done in a
context like that.  One example is resolution of generics; the resolution
depends on the actual arguments, which aren't given when you pass just
the name of the procedure.  Resolution of generics is intended to be
done at compile time, so there are restrictions about using generic
names in contexts where that won't work.

The only way those restrictions come up is when the dummy argument
is a procedure.  If the dummy argument isn't a procedure, then neither
may the actual argument be, and all these restrictions have to do with
procedures as arguments.

--
Richard Maine                       |  Good judgment comes from experience;
email: my last name at host.domain  |  experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov |        -- Mark Twain

Fri, 16 Jan 2004 23:00:03 GMT
Intrinsoc function as argument to intrinsic function question

Quote:

> >   INTRINSIC SUM, MINLOC, REAL

> CVF 6.5A objects to this.

On what basis?  Looks benign to me.  What's the error message say?

--
Richard Maine                       |  Good judgment comes from experience;
email: my last name at host.domain  |  experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov |        -- Mark Twain

Fri, 16 Jan 2004 23:02:57 GMT
Intrinsoc function as argument to intrinsic function question

Quote:

> > I have been in contact when the vendor and have been told that the manual states
> > (quoting from thier email) "SUM is a transformational intrinsic function.  The
> > name of this intrinsic cannot be passed as an argument."

> That frankly leaves me most unimpressed with whoever the vendor is.  If they
> do that poor a job of reading standard-speak, then its going to be pretty
> rough going for them in the parts that are actually tricky.  This one isn't.

> Nor is this some new, complicated f90 thing.  I suppose the next thing
> they will tell you is that you can't pass real(42) as an actual
> argument.  (You cannot pass the name of the REAL intrinsic as an
> actual argument).

> The name of the function is not being passed as an argument in your case.
> The name of the function in question is SUM.  It is not
> "SUM(a-bunch-of-stuff)".  What is being passed as an actual argument
> is an expression, not a name.

Ah ha! I knew there was more to that sentence and the para above made it click.
They're confusing between passing "SUM" as a procedure argument rather than, as
you say, the expression "SUM(a-bunch-of-stuff)". Cool! Thanks!

Cheers,

paulv

--
Paul van Delst           A little learning is a dangerous thing;

Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
Alexander Pope.

Fri, 16 Jan 2004 23:17:10 GMT
Intrinsoc function as argument to intrinsic function question

Quote:

> | I have been in contact when the vendor and have been told that the manual
> states
> | (quoting from thier email) "SUM is a transformational intrinsic function.  The
> | name of this intrinsic cannot be passed as an argument."

> My understanding of that quote is that you cannot pass SUM where
> EXTERNAL is expected, but *can* where an scalar/array is expected. Let's
> consider
> the case when SUM returns a scalar:

> I = NINT(SUM(x(1:10)))

> This is apparently allowed. For the reason of symmetry, SUM which returns
> an array (operating on a matrix argument) has to be allowed too. Now, either
> I'm ignorant, or their tech support is ignorant (not to mention worse
> possibilities)?

Jeez, steady on. "Ignorant" is a wholly unnecessary word here (applying to you
or the tech support folks - who contacted me, BTW, not me them.) - the sort that
can be taken out of context and used to bend peoples noses outta shape. My
experience on this newsgroup with respect to interpreting the standard (well,
reading other's interpretations) is that a couple to-and-fro's are required for
me to understand the consequences. What I'm looking for is wording that
effectively states that if a compiler does not allow (*) the following,

number = MINLOC( SUM( the_array, DIM=2 ) )

then it is not standard conforming. Me (or you) simply stating that it *should*
allow it without something a bit more meatier makes the position of pursuing the

I think I'm gonna have to buy meself a copy of The Standard.

cheers,

paulv

(*) Note that the source code compiles without any errors/warning, so the
compiler does accept (allow) the source - it just produces an executable that

--
Paul van Delst           A little learning is a dangerous thing;

Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
Alexander Pope.

Fri, 16 Jan 2004 22:55:58 GMT
Intrinsoc function as argument to intrinsic function question

Wed, 18 Jun 1902 08:00:00 GMT
Intrinsoc function as argument to intrinsic function question

Quote:

> >   INTRINSIC SUM, MINLOC, REAL

> CVF 6.5A objects to this. If I uncomment this line, both versions of the code
> generate the correct result.

Huh. I don't see how that could affect the result (makes me think something is
haywire with CVF 6.5A) but I trie dit anyway. Commenting out the INTRINSIC
statement had no affect - same incorrect result.

Quote:
> I think 187.facerec would fail to compile if the reason you were given was
> correct.

What's 187.facerec?

cheers,

paulv

--
Paul van Delst           A little learning is a dangerous thing;

Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
Alexander Pope.

Fri, 16 Jan 2004 23:32:38 GMT
Intrinsoc function as argument to intrinsic function question

Wed, 18 Jun 1902 08:00:00 GMT
Intrinsoc function as argument to intrinsic function question

Quote:
> What I'm looking for is wording that
> effectively states that if a compiler does not allow (*) the following,

>   number = MINLOC( SUM( the_array, DIM=2 ) )

> then it is not standard conforming. Me (or you) simply stating that it *should*
> allow it without something a bit more meatier makes the position of pursuing the

See my other post (which you've already responsed to) for why the restriction
the vendor cited doesn't apply.

I'm afraid that it is hard to point to a particular piece of the
standard that says you you *CAN* do this (and thus that a compiler
that gets it wrong is non-conforming).  That's a lot like trying to
find where it says that you can pass "2 + 2" as an argument.  You
won't find anything that addresses that particular case - just stuff
just as valid an expression as 2+2.

To cite a section of the standard, I'd have to fall back to the real
basics of section 155, Conformance (from f95 - f90 has similar words):

A program (2.2.1) is a standard-conforming program if it uses only
those forms and relationships desribed herein and if the program
has an interpretation according to this standard.

Your program uses only forms and relationships described in the
standard.  The standard does describe the form of an expression to
include forms like the one you show, it describes expressions as
actual arguments, and there isn't any prohibition against this case.
The standard also describes how to interpret all those things.

Then, in the next para:

A processor conforms to this standard if

(1) It executes any standard-conforming program in a manner that
fulfills the interpretations herein, subject to any limits
that the processor may impose on the size and complexity of
the program; .....

The basic message here is that if the code uses forms defined by
the standard, and there isn't an explicit prohibition against
something it does, then its ok (and a processor that doesn't execute
it correctly is non-conforming).

I'm afraid you aren't going to do much better than that, which is
awfuly vague.  But those are the words that basically say that the
code is inocent until proven guilty - you need to find specific
restrictions to prove that the code is disallowed - you won't find
specific things about every combination of operations that is allowed;
that would be a combinatorically impossible task.

Quote:
> I think I'm gonna have to buy meself a copy of The Standard.

It's gotten a lot cheaper recently.  A scanned elextronic version
can be purchased for \$18.  See

<http://webstore.ansi.org/ansidocstore/find.asp>

and search for 1539.  It is just a scanned version - not as nice
as if they had come to the editor (ahem) to get an original in
a form other than paper.  But it is a completely legal copy for
about a tenth of what one used to cost.

--
Richard Maine                       |  Good judgment comes from experience;
email: my last name at host.domain  |  experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov |        -- Mark Twain

Fri, 16 Jan 2004 23:58:48 GMT

 Page 1 of 2 [ 18 post ] Go to page: [1] [2]

Relevant Pages