> On May 15, 1:25am, Robin Vowels wrote:
> > Subject: Re: Extension of {MIN,MAX}{LOC,VAL} to LOGICAL arrays?
> >
> > [ plain text
> > Encoded with "quoted-printable" ] :
> > On May 15, 12:29am, Robin Vowels wrote:
> > > > Subject: Re: Extension of {MIN,MAX}{LOC,VAL} to LOGICAL arrays?
> > > >
> > > > [ plain text
> > > > Encoded with "quoted-printable" ] :
> > > i = lbound(array)
> > > > do while (array(i))
> > > > i = i + 1
> > > > if (i > ubound(array) exit
> > > > end do
> > > >
> > > > is likely to be shade faster....
> > > > ----------
> > > > > Thanks for both suggestions. Both, however, are likely to
> > > > > create large temporary arrays and be considerably slower than
> > > > > DO i=1,SIZE(array)
> > > > > IF( .NOT. array(i) )EXIT
> > > > > END DO
> > >
> > >
> > > Why? Because you don't have to enter the loop body if the first
> > > element is .FALSE. ?
> > > -P.
> >
> > No, it's because the loop has one lesss operation in it. The array
> > element is not complemented in the test.
>
> Yes, I see. But I'm not certain the operation would have to be
> performed. At the machine-instruction level, I don't think
> a test for equality is any faster than a test for inequality,
> and presumably both loops would boil down to such tests at the
> machine level. For instance, if a logical FALSE is represented
> as a 0 word and TRUE by anything else, you would be testing for
> array(i).NE.0 and I would be testing for array(i).EQ.0, at the
> machine level.
> -P.
That may well be the case for an optimizing compiler,
but it's not likely to be the case otherwise. The .not.
would most likely take place.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|