>>>>>Thanks, Tamar
>>>>>
>>>>>That's exactly as I learnt it and understood it (if you read my question then I roughly described it thus). OK I was interested in how George would do that in a do while loop.
>>>>>
>>>>>Terry
>>>>>
>>>>>>>... As I learnt it in college it means going backward and foreward in the list, halving the distance as you go (in essence). If that's so, please could you indicate how does ascan() do it, and how you would do it via a do while?
>>>>>>>
>>>>Terry,
>>>>
>>>>Here's an example. I'm doing this off the top of my head, so it hasn't been debugged. Nevertheless, it should be close enough. If there are questions (or mistakes) please let me know. This function will return either the offset into a single dimension array, or the next greatest value. Naturally, the array is passed by referene

FUNCTION BArraySearch
>>>>
>>>>LPARAMETERS tarray, tsearchfor, tlsoftsearch
>>>>
>>>>LOCAL lnfirst, lnlast, lnmid, llfound, lnresult
>>>>lnfirst = 1
>>>>lnlast = ALEN(tarray, 1)
>>>>llfound = .F.
>>>>lnresult = 0
>>>>DO WHILE NOT llfound AND lnfirst < lnlast
>><b>  lnmid = INT((lnfirst + lnlast) / 2)</b>
>>>>  llfound = (tsearchfor = tarray[lnmid])
>>>>  IF NOT llfound THEN
>>>>    IF tsearchfor > tarray[lnmid] THEN
>>>>      lnfirst = lnmid + 1
>>>>    ELSE
>>>>      lnlast = lnmid - 1
>>>>    ENDIF
>>>>  ENDIF
>>>>ENDDO
>>>>IF llfound THEN
>>>>  lnresult = lnmid
>>>>ELSE
>>>>  IF llsoftsearch THEN
>>>>    lnresult = lnlast
>>>>  ENDIF
>>>>ENDIF
>>>>RETURN lnresult

The beauty of this is that it can be implemented, not only with a array, but an ordered list or cursor.
>>>
>>>George, are the following assumptions correct?
>>>1. You assume that the list is ordered.
>>
>>This is correct. A binary search requires an ordered list or table
>>
>>>2. ASCAN() is not available.
>>
>>Doesn't matter. ASCAN() performs a sequential search and is much slower.
>>
>>>3. lnmid = INT(lnfirst + lnlast) should actually be lnmid = INT(lnlast/2) for the first time around the loop and then add or subtract half the remainder for subsequent iterations.
>>
>>Not quite. You're right that the calculation isn't correct. My mistake. It should be, as shown above

lnmid = INT((lnfirst + lnlast) / 2)

>>
>>>4. If you start at the mid point and decrement then you are either going to loop forever or get a subscript out of bounds error when it gets to 0.
>>
>>The correction above takes care of that.
>
>George my friend,
>PMFJI and more if jumping in wrong place:)
>I agree there are places do while is preferred over for..endfor. Thinking original thread was about 'evils' < bg > which I disagree doesn't your code also would be faster with 'evils' (I know that you already have corrected code:)?

Cetin,

You never have to use PMFJI. We've been friends for too long for you to have to use that.< s >

To answer you're question...I don't know. It might be faster with one of the "evils", but by how much? IOW, would it really make a significant difference? I don't think so.

Regards,