OpenEuphoria

Re: binary search with reference to append

• Posted by DerekParnell (admin) Jun 15, 2014
• 1604 views

What is getting personal? I don't see that myself. I'm not offended by any of these exchanges. I welcome being challenged by my peers to do better.

Yes, I understand that these are you concerns with the current library code. However, I'm sure you also recognise that some of your arguments, like some of mine, are based on opinion rather than empirical evidence.

I thank you for your concern. I cannot see the errors in the code I've just presented, but I'd like to have them pointed out to me so I can improve my coding abilities. (I've been learning how to be a better programmer since 1972, by the way).

Whether that code is "both simpler and better" is a point of view. In any case, the published API needs to be respected, so therefore we are stuck with having to deal with the optional parameters for starting_point and ending_point. I think that if we were writing this function for inclusion into the library now, we would not have these optional parameters. In hindsight, they are probably a poor design decision. But here we are ... we are stuck with them. So let's just manage the best we can.

sp = start_point  
    if end_point <= 0 then  
        -- End point specified is relative to the end of the sequence.  
        ep = length(haystack) + end_point  
    else  
        ep = end_point             -- ep=3 => length?? (G) 
    end if  
      
    if ep > length(haystack) then  -- this cannot happen (G) 
        ep = length(haystack)  
    end if  
    if sp < 1 then  
        sp = 1  
    end if  
    if sp > ep then  
        if sp = ep + 1 then        -- if ep = length??   (G) 
            return -sp  -- Obviously the needle is never in an empty sequence/slice.  
                        -- if sp > ep then why assume the slice starts at sp? 
                        -- with ep = length -sp is out of range. (G) 
        end if  
        return 0  -- Slice starts after the end.  
    end if  

I'm assuming that the code extract above is some sort of attempt to demonstrate the errors in my code. I'm guessing this as you don't actually say what its here for. So sorry if I'm getting that wrong.

I have no idea what the comment "ep=3 => length?? " is meant to be saying to me.

Again, the comment "this cannot happen" doesn't make a lot of sense to me. As far as I can make out, it is quite possible to call this function with an end point specified that is greater than the length of the physical sequence to be searched, and I'm sure you agree with that, so I'm unsure as to the meaning of this comment.

if sp > ep then why assume the slice starts at sp? 
with ep = length -sp is out of range. (G) 

I 'assume' the slice starts at 'sp' because that what the caller told me it started at. That's the entire point of having this optional parameter --- to tell me where the slice starts.

I know that "with ep = length -sp is out of range.", and that again is the point of the code. This function is to return a negative value when the caller specified slice is valid AND the requested item in not in that slice. The magnitude of the returned value is an indication of where the item might have been located if it had of been in the slice. That is what the published API says (though not very well I have to admit).

No argument here. That is why we strive to write better code and to have it peer reviewed. Just because writing good code is difficult, that is no reason to shirk our responsibility to do exactly that: to write good code.

Thank for for helping me to be a better programmer.