>>The reason that the llfound variable is used is that it allows for a "soft search" which can be quite handy. The above doesn't.
>
>You need the "found" information in any case to decide what to return <g>,
>but that info should be not gathered inside every loop-run.
>Here personal styles will differ even more:
>Some would prefer something wordy like
>
>

>lnresult = 0
>DO WHILE lnfirst < lnlast
>...
>ENDDO
>IF tsearchfor = tarray[lnmid] THEN
>  lnresult = lnmid
>ELSE
>  IF llsoftsearch THEN
>    lnresult = lnlast
>  ENDIF
>ENDIF
>RETURN lnresult
>

>
>while some would call my probable favorite "too tricky"
>[still giving all possible return values at one glance]
>
>

>LOCAL lnfirst, lnlast, lnmid, lnFoundExact
>lnfirst = 1
>lnlast = ALEN(tarray, 1)
>* INTENDED: Local, but no init for lnFoundExact
>DO WHILE m.lnfirst < m.lnlast
>  lnmid = INT((m.lnfirst + m.lnlast)*0.5)
>  Do Case
>    case m.tsearchfor > tarray[m.lnmid]
>      lnfirst = m.lnmid + 1
>    case m.tsearchfor < tarray[m.lnmid]
>      lnlast = m.lnmid - 1
>    otherwise
>      lnFoundExact = m.lnMid
>      exit
>  EndCase
>ENDDO
>return  iif(vartype(m.lnFoundExact)=="N", m.lnFoundExact, ;
>        iif(m.llsoftsearch, m.lnLast, 0))
>

>
>I still believe "exit" enhances this particular code -
>which was one of the argument starters of this thread.
>
>Any chance to get something thread-recursive here ? ;-)
>
thomas,

I don't know about "...thread recursive" here< s >, but some of the basic algorithms I have seen do implement this recursively. My problem with that is that it not only tends to "cloud" things, but doesn't perform as well because of the recursive calls.