good for anyway, it's just a bit of defensive programming. I might have implemented the algorithm slightly differently if I was allowed to test, but I thought "The heck, I'll just inflate the thing to the next 2^n size and save myself a couple of doubts without even losing performance (apart from a small constant)." I just ran into coding after seeing the initial statement before reading about any experiment so I tested it a few times. I had two bugs (mid = arr[(first+last)/2]; instead of mid = (first+last)/2; and no ending condition for the recursion for no result) that I found after about three test runs. I did it in C in twenty minutes or so and... it failed for half (when numbers to be find were on "right" part):( Then I took a deeper look into my code, I debugged it "by mind" several time before saying "it is right" ... and found the grand error: using size_t for indexes instead of signed int... so there was the condition that lead a while to loop forever or segmentation fault (r==-1 and l == 0 should stop the loop, but indeed r became 4billions or so, r &gt; l for sure and it tried to access the array at that huge index) fixed size_t to int, it worked properly Yes, Brian, so far as I am concerned, the point of this exercise is to get the algorithm right. So I think you can award yourself a pass (so long