MASON-INTEREST-L Archives

August 2012

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Proportional 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:
Chris Hollander <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Wed, 15 Aug 2012 13:56:09 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
So I tested out this code today at work... and when the distance gets
REALLY big, there are problems. For "normal" ranges, say making the
distance equal to the width, it seems to work fine... but it breaks
when the distance is say, 2 * width.

Consider a 20x20 grid with an agent at location (10, 10). Now, use a
distance of 50...

Based on the new code:

int xmin = x - dist;              // 10 - 50 = -40
int xmax = x + dist;            // 10 + 50 = 60

// next: is xmax - xmin humongous?  If so, no need to continue wrapping around
if (xmax - xmin >= width)  // too wide     - Yes, 100 >= 20
    xmax = xmin + width - 1;           // xmax = -40 + 20 - 1 = -21

...

for( int x0 = xmin ; x0 <= xmax ; x0++ )     // for x0 = -40; x0 <= -19; x0++
                {
                final int x_0 = stx(x0, width);
// x_0 = stx(-40, 20)  => -40 + 20 = -20
                for( int y0 = ymin ; y0 <= ymax ; y0++ )
                    {
                    final int y_0 = sty(y0, height);
                    xPos.add( x_0 );
                    yPos.add( y_0 );
                    }
                }
            }


So it appears that because of how stx() is coded, really large
distances as compared to the grid size don't work out too well....

stx is given as:

    final int stx(final int x, final int width) {
        if (x >= 0) {
            if (x < width) {
                return x;
            }
            return x - width;
        }
        return x + width;
    }

So when it's passed -40 and 20, x < 0 and so it returns -40 + 20 =
-20. That -20 then gets added to the list of x positions, which assume
to make the assumption that the values are valid, since the bags are
passed directly to getObjectsAtLocations. This of course returns null,
which then explains why you get no neighbors with really big
distances.




On Sat, Aug 11, 2012 at 10:09 AM, Seth Tisue <[log in to unmask]> wrote:
> On Fri, Aug 10, 2012 at 6:38 PM, Sean Luke <[log in to unmask]> wrote:
>> Okay, I see the issue.  You're doing toroidal lookups.  The toroidal code presently runs from max to min, doing toroidal wrap-around, without considering if a grid cell was looked up twice.  For example, if you have a 10x10 grid and are in location <5,5>, and do a 5-element range lookup, cell <5,0> will be in that collection, along with cell <5,10>, which is the exact same cell.
>
> I remember when NetLogo had this same bug :-)
>
> --
> Seth Tisue | Northwestern University | http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

ATOM RSS1 RSS2