James Newton <[EMAIL PROTECTED]> wrote > Brennan <[EMAIL PROTECTED]> wrote: > > I discovered this curiosity; > > > > b = [1,256,999] > > sort b > > put b.findposNear(1000) > > -- 4 > > Hi Brennan, > > findPosNear() has always worked this way, at least since Director 5. I > suppose that the name "findPosNear" was chosen instead of the more accurate > "findPosIdenticalOrNext" in order to go easy on our typing fingers.
It is indeed this special subclass of the word 'near' that confounded my expectations. Given AustinPowersOfTwo = [1,2,4,8,16] sort AustinPowersOfTwo My own internal mix of gestalt psychology and mathematics would indicate that, say, 17 would be 'nearer' to position 5 than the imaginary position 6 which we might assume to contain 32. Clearly, the question of whether the implementation of findPosNear is intuitive or not depends a great deal on what the list represents in the mind of the programmer. > I do not consider this to be a bug or even a quirk. If findPosNear() were > to round to the nearest value, you would have to check if the nearest value > were higher or lower than the value expected, which would give you the same > result but would probably take more clock cycles. I can see that. Thanks for explaining the thinking behind it, but what if you weren't interested in whether it was higher or lower and simply wanted the value which was 'nearest' on the number line? Example: I have a lookup table (sorted list of floats) : They are coarsely resolved angles describing a circle divided into 66 equal parts (don't ask), and I have code which generates angles at a finer resolution than I want. I'm using findPosNear to give me the 'nearest' coarse angle when I supply the fine one. The implementation of findPosNear therefore *adds* cycles to my code because I have to test whether the value I get back is greater than the number of items in the table, and if so, to decide whether the first or the last coarse value is the better one to take. > The current > implementation is simple and logical. Certainly, but I think the name is misleading, and it's a shame that the implementation is incompletely described in the Lingo dictionary. > What behavior do you expect from findPosNear()? If the value was beyond the maximum value in the list, I think I was expecting to get 0 back, or perhaps the index of the last item, i.e. count(). Actually I can't remember any more what I expected, or whether I expected anything specific so I suppose there's room for multiple implementations of findPosNear(). I know for sure that count()+1 was not what I expected, and there's nothing in the docs to suggest that my expectations were unreasonable. Tab Julius <[EMAIL PROTECTED]> wrote > 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. ...or more 'smoothly': findPosNear returns the index of the first value which is 'greater than or equal to' the parameter provided. AustinPowersOfTwo = [1,2,4,8,16] sort AustinPowersOfTwo put findPosNear(AustinPowersOfTwo,9) -- 5 > Unfortunately, this is neither correct (there is no fourth value) nor > necessarily valid (the fourth value may be MUCH larger, and not necessarily > nearer). Exactly my point. I can live with this, I just wish it were documented, because depending on what angle (no pun intended) you are approaching this function from, it can seem very counter-intuitive. > Congrats, you found a bug (not sure if it's already documented or not). I'd agree with James that it is not a bug, but that the shortcomings in the documentation make it seem like one. Anyone else using sorted lists? I'd be interested to hear what you're using them for. -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!]
