> Gib Bogle wrote:

>> Dick Hendrickson wrote:

>>> Gib Bogle wrote:

>>>> Hi,
>>>> I'd like to know the fastest way to do a check on all elements of a
>>>> slice of an array, looking for any occurrence of a particular
>>>> condition. To be precise:
>>>>
>>>> fu(NX,NY,NZ) is an array of derived type, something like
>>>>
>>>> type fu_type
>>>> integer :: bar
>>>> integer :: status
>>>> ...
>>>> end type
>>>>
>>>> type(fu_type) :: fu(NX,NY,NZ)
>>>>
>>>> For a given x, and a status value stat0 I want to determine whether
>>>> there is any (y,z) 1<=y<=NY, 1<=z<=NZ, such that
>>>> fu(x,y,z)%%status /= stat0
>>>>
>>>> Is there a clever way to use the ANY intrinsic for this, or do I
>>>> have to use dumb loops?

>>> Depends on what you mean by "fastest". If the condition is an
>>> "unusual" condition, than letting the compiler generate code for the
>>> ANY intrinsic is almost always fastest. If the condition "almost
>>> always" occurs, then a DO loop with a short circuit exit on the
>>> first occurrence is likely to be fastest.
>>>
>>> The difference between "unusual" and "almost always" is processor and
>>> compiler dependent.
>>>
>>> Dick Hendrickson

>>
>> Right. In my case conditions span the whole gamut, so there is no
>> clear winner, I think.

> I was going to whimsically suggest that you write it both ways in an
> if-else block, using COUNT (test expression) < small_number as the IF
> condition. That way you could get the fastest version either way (at
> the cost of doubly computing everything). Then a serious idea popped
> up, try experimenting with FIRSTLOC. That will possibly short-circuit
> the tests when it finds a true instance. But, it's also likely that the
> compiler will generate efficient code (unrolling, pipelined execution,
> whatever) for the implied loop. Again, it will be hardware and compiler
> dependent; but, you might be surprised.
>
> Dick Hendrickson