MASON-INTEREST-L Archives

August 2012

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Sun, 12 Aug 2012 01:08:11 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (37 lines)
On Aug 11, 2012, at 5:37 PM, Chris Hollander wrote:

> 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.)

All Sparse Grids must have a height and width -- but the height and width may exist solely to guide the GUI as to what part to draw by default.

You can use Sparse Grids either bounded, meaning that your objects are only stored at locations from <0,0> to <width,height>.  Or they can be
toroidal, meaning that they're stored at any location but you assume wrap-around semantics.  Or they can be unbounded, meaning that your objects
can be stored at any location you like.

> 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.

Actually I would guess that unbounded is the second most common situation after toroidal.   More importantly, it's one of the distinguishing features of SparseGrid2D.  I myself use unbounded quite a bit.

> So...
> It seems like you have to assume that if toriodal = true then bounded
> = true, otherwise how do you decide when to start wrapping around?

We have two bits, thus four cases.  But we only have three possibilites.  So it's

toroidal = true
toroidal = false and bounded = true
toroidal = false and bounded = false

> 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
> most users.

I've considere this.  But there's two evils here.  There's the evil of returning more locations or objects than the user expected.  And there's the evil of not returning locations or objects.  The first is a WTF moment.  The second is a silent and potentially disastrous bug.  That's what spooks me.

Sean

ATOM RSS1 RSS2