Prev: size of a derived type containing pointers...
Next: Problem with Matmul
From: Richard Maine on 26 Mar 2010 12:07
bing999 <thibaultgarel(a)gmail.com> wrote:

> Thanks but PACK does not return the index of the array, right? i need
> the index since my 2 arrays have same dimensions (and by the way my
> problem is more complicated than just grab the positive values...)

Ok. Pack does what your example shows, but apparently the example isn't
adequately representative. Another possibility is the Fortran WHERE
construct. It also doesn't return index values. In fact, it doesn't
return anything at all, being a construct instead of a procedure. But it
does allow you to do some things on the selected elements of multiple
arrays having the same dimensions. Admitedly, the things you can do are
very limitted.

Otherwise, if you really do want an array of the index values as you
say, then I'll give an answer much like that I gave to another recent
inquiry. Broaden your focus to realize that there are ways to operate on
arrays other than whole array expressions. It is pretty simple to do
this one with a DO loop. The only thing that makes it non-trivial is
that you don't know the size of the needed array of index values until
after the fact. You can address this either by determining the size as a
separate first step or by dimensioning the array to the maximum possible
size (which is the size of the original array).

As in

allocate (indices(count(condition-involving-array-a)))
n = 0
do i = 1 , size(a)
if (condition-involving-a(i)) then
n = n + 1
indices(n) = i
end if
end do

or

allocate(indices(size(a)))
... the same loop as above
! Optionally followed by
a = a(1:n) !-- Assuming f2003 allocatable assignment.

As an aside, note that an array of index values is not a particularly
handy form in Fortran in general. In particular, you can't directly use
such a thing for the multi-dimensional case; you'd have to break it
appart, probably in a loop. You can use it in the one-dimensional case,
but there are restrictions on the usage and, depending on details, you
might find it inefficient.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: dpb on 26 Mar 2010 12:42
Richard Maine wrote:
....

> Otherwise, if you really do want an array of the index values as you
> say, then I'll give an answer much like that I gave to another recent
> inquiry. Broaden your focus to realize that there are ways to operate on
> arrays other than whole array expressions. It is pretty simple to do
> this one with a DO loop. The only thing that makes it non-trivial is
> that you don't know the size of the needed array of index values until
> after the fact. You can address this either by determining the size as a
> separate first step or by dimensioning the array to the maximum possible
> size (which is the size of the original array).
....

And, I'll note for OP that while in environments such as IDL or Matlab
where there may be a significant performance penalty in looping
constructs as compared to figuring out how to vectorize the code, since
Fortran is compiled there will not be such a penalty at run time to
worry about. The offsetting condition is it may take a little more
coding effort in Fortran than in one of these languages.

Also, there's a distinct possibility that the concise Fortran constructs
may not compile/optimize as well as the straightahead DO construct;
whether that's true or not will, of course, depend on the actual
construct as well as the specifics of a given compiler.

--
From: glen herrmannsfeldt on 26 Mar 2010 15:15
dpb <none(a)non.net> wrote:
(snip)

> And, I'll note for OP that while in environments such as IDL or Matlab
> where there may be a significant performance penalty in looping
> constructs as compared to figuring out how to vectorize the code, since
> Fortran is compiled there will not be such a penalty at run time to
> worry about. The offsetting condition is it may take a little more
> coding effort in Fortran than in one of these languages.

and R and Mathematica. After the question a few days ago, and then
this one, I was about to write the same thing. The key to fast
code in such interpreted languages is using the array operations,
or even more specialized built-in operators.

> Also, there's a distinct possibility that the concise Fortran constructs
> may not compile/optimize as well as the straightahead DO construct;
> whether that's true or not will, of course, depend on the actual
> construct as well as the specifics of a given compiler.

The array operations can easily require temporary arrays that are
not needed in the DO loop case. Using array operators tends to
require more passes through the array. Also, like in the one a few
days ago, the DO case can often exit early without processing the
whole array. The array operation case usually can't do that.

While compilers are getting better, I believe the statement that
I made years ago is still true: Array operations are likely
at least as fast for simple operations, but often slower
(and also less readable) for more complicated operations.

They do make nice entries for Obfuscated Code contests, though.

-- glen
First  |  Prev  | 
Pages: 1 2
Prev: size of a derived type containing pointers...
Next: Problem with Matmul