I'm not sure I entirely understand why you mean by bounded vs.
unbounded... you mean in terms of a maximum possible height/width? (I
just woke up, so I'm not firing on all cylinder's yet.)
If this is the case, then how many people are actually assuming
unbounedness as the proper behavior? I would assume that almost
everybody using the GUI components is probably not, since you have to
specify a height and width. So then how many people are both never
using the GUI, and assuming unbounded behavior? It'd make sense if
you're looking at some sort of growth phenomena I guess, so I imagine
there's at least a couple cases...
It seems like you have to assume that if toriodal = true then bounded
= true, otherwise how do you decide when to start wrapping around?
It also seems like bounded should be set to true by default, if that's
the assumption made in the documentation and common assumption made by
On Sat, Aug 11, 2012 at 10:44 AM, Sean Luke <[log in to unmask]> wrote:
> I should follow up here to say that the proposed modification will *change* the results that these three functions have returned before. However I think it will change them so as to be more in-line with what people expect, reducing bugs.
> On Aug 11, 2012, at 4:15 PM, Sean Luke wrote:
>> So while debugging the last bug that was reported on this list, I came across something I really don't like about the getMaxDistance, getHamiltonianDistance, and getHexagonalDistance functions in SparseGrid2D and SparseGrid3D.
>> SparseGrid is different from other grids in that it has essentially *three* modes:
>> - Bounded
>> - Unbounded
>> - Toroidal
>> It's the "Unbounded" part that's a problem for me. These three functions take a "toroidal" parameter which lets you do wrap-around collection of locations or objects up to a certain distance away from a central point. But what if the "toroidal" parameter is turned off? It turns out that SparseGrid collects neighbor cells and objects as if it were *bounded*.
>> Bounded makes sense if you want to be consistent with collections made in other grids (ObjectGrid2D for example). But it makes it _impossible_ to do unbounded collection.
>> I'm going to make a some new versions of these functions which take a "bounded" parameter and a "toroidal" parameter. If toroidal=true, then bounded must = true (it'll throw an exception if not). Otherwise bounded can be true or false.
>> The question is how to define the older functions that don't have a "bounded" parameter. Do I:
>> 1. Define them as assuming bounded <- toroidal, that is, if it's not toroidal, it's unbounded. This is the behavior used in Continuous2D and I think it makes much more sense as a default for a potentially infinite grid.
>> 2. Define them as assuming bounded <- true. This is the behavior _assumed_ in the documentation of Grid2D. It would make the results returned by SparseGrid2D always consistent with those of other grids even if it's infinite (the out-of-bounds values would simply be ignored).
>> The question is: which is least surprise? My inclination is #1. People assuming boundedness will be surprised by extra values that show up in their results *if* for some reason they accidentally had placed objects outside the bounds. BUT if we did #2, then people assuming unboundedness would have results not show up at all, and that'd be bad.
>> What do you think?