RE: Re: filter list

Messages in this topic (4) Reply (via web post) | Start a new topic

.

Paul,

In fact, by making id a local variable, you turned the expression into one that can be evaluated entirely within the context of a patch. In the original expression NetLogo would have had to figure out that id actually meant [id] of myself — i.e. id would need to be evaluated in the context of the calling turtle, rather than any of the patches.

With your revised expression (or, alternatively, an expression that explicitly uses myself to refer back to the calling turtle), I agree that it could be reasonable to expect an uphill-like primitive to operate in much the same way that the max-one-of and min-one-of primitives work — namely, by evaluating an expression, rather than a single patch variable, across a set of patches, then returning the patch that gives the maximum value of the expresson (and finally, of course, moving the calling turtle to that patch).

On the other hand, it seems to me that uphill/uphill4 and downhill/downhill4 are intended to be fairly simple — not just in their invocation, but also their outcome. For example, in many applications, moving to the center of the destination patch, with a heading that is an integral multiple of 45, is going to be too simplistic a movement. So it might also be argued that more complex expression evaluation, like more complex movement, should be dealt with by the programmer, rather than the uphill & downhill primitives.

Anyway, I'd be interested to hear what some of the NetLogo development team might have to say on this issue. >

Regards,

Nick

--- In netlogo-usersyahoogroups.com, "Paul S. Coates" <P.S.Coates...> wrote:
>;
> Thanks nick, as you see from my most recent post we kind of did what you
> suggest. I take your point about uphill needing to reference a set of patches
&gt; by -own variable to get the maximum value but but really item id allscents
> shouldn't be too hard to parse, all patches have an allscents after all but
> netlogo is evaluating it too soon really isn't it, just sending uphill a
> value rather than an address
&gt;
>
>
>
>
> Paul S Coates AA Dip
> Programme leader for MSc Architecture:Computing & Design
>; School of Architecture and the Visual Arts
> University of East London
>; Docklands Campus
>; 4-6 University Way
> London E16 2RD
> tel +44 208 223 3220
>
> -----Original Message-----
> From: netlogo-usersyahoogroups.com [mailto:netlogo-usersyahoogroups.com] On
> Behalf Of Nick
> Sent: 09 March 2008 22:19
> To: netlogo-usersyahoogroups.com
>; Subject: [netlogo-users] Re: filter list
>
>
>
> Tim,
>
> That is a funny error message, in a somewhat existential way. In my
> experience, NetLogo seems to use "anything" to refer to an expression which
> might conceivably return any type of value. Perhaps the error message would
> have been clearer (but possibly still not entirely illuminating) if it had
> said: "Uphill expected a variable, but got something else instead." That's
>; basically what happened: you gave uphill an expression, instead of a
> variable. There are a few primitives like that, where a simple variable,
> rather than an expression, is required. For set (the first parameter),
> diffuse! , and diffuse4, for example, the reason for this is pretty clear:
>; we're actually supplying a reference to a variable whose value will be
> modified by the primitive. In the case of uphill and uphill4, it's not quite
> as clear why only a single variable is allowed; I suspect it's because it
> could otherwise be pretty difficult for NetLogo to determine and apply the
> appropriate evaluation context(s), when it evaluates an arbitrarily complex
&gt; expression across the current and neighboring patches. (As an alternative, I
> guess NetLogo could take the expression as is, and try to evaluate it identi!
&gt; cally in the context of each of the patches; but that could result in
> hard-to-debug errors, in my opinion.)
>
> If you look at the documentation for uphill and uphill4, you'll see that an
> equivalent fragment of code is given. That fragment is fairly easy to modify
>; for your purposes, and use in place of uphill. So, in your case, where
> turtles have an id variable and patches have an allscents variable, you could
> use a procedure like thi! s:
>
> to uphill-scent
> move-to patch-here
> let value-here (item id allscents)
> let best-neighbor (max-one-of neighbors [item ([id] of myself)
&gt; allscents])
> if ((item id ([allscents] of best-neighbor)) > value-here) [
> face best-neighbor
> move-to best-neighbor
> ]
> end
>
> Note that this procedure uses three different forms of the item id allscents
> expression, for the different evaluation contexts: one for evaluating in the
> current patch, one for evaluating over a patch agentset, and one for
> evaluating in a single patch other than the current patch. With some work,
> these expressions could be coerced into a single f0rm (especially if you
> wrote a reporter that would be evaluated by patches, with an id value as a
> parameter). However, either approach is arguably best left up to the
> programmer, rather than trying to have NetLogo do it automatically.
>
> I hope this helps.
>;
> Regards,
&gt;
> Nick
>
>
> --- In netlogo-usersyahoogroups.com, "timirelandesq" timirelandesq
> wrote:
>; >
> > Hi there,
>; >
> > I'm trying to make a turtle follow a particular value in a list - so
> > that it hillclimbs this particular value.
>; >
> > in my model turtles have identities which are equal to a particular
> > value in the list.
> >
> > So, each patch has a list of values; say [1 2 3 4]
> >
> > A turtle of identity 3 would follow the value '3'.
> >
> > We have written;
&gt; > set heading heading uphill (item id allscents)
> > , which means it should follow the value in the list relative to
> > its 'id' in the ascending direction - but it doesn't. It reports
> > that "uphill expected a variable but got anything instead".
> >
> > I think i should probably use 'filter' but have got stuck.
>; >
> > Can anyone help please?
&gt; >
> > Also, what is meant by "anythi! ng",can't find reference to this in
> > guides.
&gt; >
> > Thanks, tim
> >
>

Messages in this topic (5) Reply (via web post) | Start a new topic

.