[starlogo-users] patch and global variables...

[josh]

Hi Ken,

also good points and thank you for your friendly neutral reply, since I
noticed after I hit send that "not too pretty hack" wasn't the tone I
had intended! ;-)

Though I disagree with hacking the patches into a global which stores
coordinates of patch properties, I agree with what you say about patches
being basically immobile agents. It would be a conceivable
generalization to have the patches simply be agents that have a
"mobility" characteristic set to false. Would there be any advantage to
this, though?

Btw, trees and buildings, etc. in sltng are in fact agents, not patches!
Just the surface the agents move upon are patches.

Thank you for the correction on 3d environments being triangles!

cheers,

-j

Ken Kahn wrote:
> Hi. Interesting points.
>  
> When there is a good use of patches, like the terrain example you give,
> then I would rather see language support for modelling that with agents
> rather than patches. I repeat -- what is a patch other than an immobile
> agent? From a modelling perspective (rather than a programming one) why
> should trees be modelled by patches while sheep by agents? I agree that
> terrain seems different but I'm OK with using agents for that as well.
>  
> 2D applications are based upon pixels which are small patches but 3D
> ones (e.g. your "sophisticated VR environments") are typically based
> upon triangles whose corners have x, y, and z coordinates. The graphics
> card converts them to pixels for the display but those pixels are not
> part of the programming model only the vectors making up the triangles.
>  
> Best,
>  
> -ken
>  
> On 12/03/07, *josh* <jbuhl_nospam at gmx.de <mailto:jbuhl_nospam at gmx.de>>
> wrote:
> 
>     Dear Ken,
> 
>     I disagree with your statement whole-heartedly.  The idea that the
>     agents can react to the different types of terrain they are standing on
>     or in front of, etc., is very useful for the simulation/modeling nature
>     of starlogotng. The /concept/ of patch variables is exactly how this
>     should be done cleanly. What you suggest could be done internally to
>     implement the patch variables efficiently and save computing resources,
>     but as far as the programming interface and programming style go your
>     suggestion is a not too pretty hack.
> 
>     While you are correct that sltng is currently confined to a rough grid,
>     this is only a question of resolution. Digital fotography is also made
>     up of little squares, but there are simply a lot of them, so a circle
>     still looks like a circle.
> 
>     It would be interesting to be able to make the grid variable in size,
>     then by adjusting the agent size, you could have whichever resolution
>     you need to model the environment you want. I'm sure the most
>     sophisticated VR environments we have today still can be  broken down at
>     the lowest level into tiny pixels, i.e. a grid.
> 
> 
>     -j
> 
>     Ken Kahn wrote:
>     > Your patch variable example points to a shortcoming with the
>     concept of
>     > patches. If indeed only a few patches are poisoned then why not
>     keep a
>     > global variable listing the coordinates of the poisoned patches and
>     > check for membership. The check may take a few extra nanoseconds
>     but you
>     > don't waste 10,000 memory locations.
>     >
>     > I'm glad to hear that "Patches are a less active part of StarLogo
>     TNG"
>     > since I dislike the idea of having something that are really
>     agents but
>     > they can't move. It just complicates the computation model. There
>     can be
>     > an efficiency argument for low-level support of non-mobile agents
>     but I
>     > think it is often less efficient to support patches -- e.g. the poison
>     > example. Also it pushes one's model towards a uniform rectangular grid
>     > while there are plenty of other ways to model the environment. Maybe
>     > poison is spread out over circles of radius 10 while other
>     variables are
>     > at different patch sizes. Patches are too special purpose to be
>     part of
>     > a language.
>     >
>     > Best,
>     >
>     > -ken
>     >
> 
>