I would call this a well-intentioned bug.
I think the reasoning is that if the value isn't in the list, identify the position that would be higher. So, for a search for -1, the position that would be higher is 1 (both the position and the value in this case). For a search for 999.000001 or 1000, the highest value found was 999 (searching iteratively) so the next position that would qualify is 4. The thinking being that the list is sorted, so the fourth position would be higher. Unfortunately, this is neither correct (there is no fourth value) nor necessarily valid (the fourth value may be MUCH larger, and not necessarily nearer). Congrats, you found a bug (not sure if it's already documented or not). - Tab At 09:33 PM 10/21/01 +0200, Brennan wrote: >For the first time I find myself using sorted lists. > >I haven't done any benchmarking, but I suspect they may be faster to >access under certain circumstances. (Anyone want to check? I can't be >bothered.) I'm actually using them for reasons other than performance, so >any performance gains are just a bonus for me, but I discovered this curiosity; > > >b = [1,256,999] >sort b >put b.findposNear(1000) >-- 4 > >(Observed in D7 and D8 on Mac.) > >Quite useful perhaps, if this is the expected behavior. (You can find out >very quickly whether the value is 'too big'). Unfortunately 'too small' >values always return 1 rather than something else. > > >put b.findposNear(-1) >-- 1 > >Just to make the point even clearer: > >put b.findposNear(999.00001) >-- 4 > >Can anyone explain the thinking behind this? > >-Brennan [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]) Lingo-L is for learning and helping with programming Lingo. Thanks!]
