Re: Use of ANY
  Home FAQ Contact Sign in
comp.lang.fortran only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: Use of ANY         

Group: comp.lang.fortran · Group Profile
Author: Dick Hendrickson
Date: Aug 13, 2008 08:08

Gib Bogle wrote:
> Dick Hendrickson wrote:
>> 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
>
> To my surprise, ifort doesn't know about FIRSTLOC. Is this a new
> intrinsic?
Boy, was I having a bad day. The function is FINDLOC and it's a new
F2008 intrinsic.

Dick Hendrickson
no comments
diggit! del.icio.us! reddit!