Editing NetLogo Rebellion Code- THREATS-ON expected input to be a turtle agentset or patch agentset or turtle or patch but got the number 0 instead - formatting

I am attempting to use the rebellion model from the models library as a template for an alliance forming model but am still encountering issues
making the model run..
breed [ agents an-agent]
breed [ threats threat ]
globals [
k ; factor for determining attack probability
threshold ; by how much must D - BS > A to make a state burden share
]
agents-own [
conflict-aversion ; R, fixed for the agent's lifetime, ranging from 0-1 (inclusive)
perceived-threat ; T, also ranging from 0-1 (inclusive)
active? ; if true, then the agent is actively burden-sharing
; if false, then the agent is free-riding
conflict ; how many turns in conflict remain? (if 0, the agent is not in conflict)
]
patches-own [
neighborhood ; surrounding patches within the vision radius
]
to setup
clear-all
; set globals
set k 2.3
set threshold 0.1
ask patches [
; make background a slightly dark gray
set pcolor gray - 1
]
if initial-threats-density + initial-agent-density > 206 [
user-message (word
"The sum of INITIAL-THREATS-DENSITY and INITIAL-AGENT-DENSITY "
"should not be greater than 206.")
stop
]
; create threats
create-threats round (initial-threats-density * .01 * count patches) [
move-to one-of patches with [ not any? turtles-here ]
display-threats
]
; create agents
create-agents round (initial-agent-density * .01 * count patches) [
move-to one-of patches with [ not any? turtles-here ]
set heading 0
set conflict-aversion random-float 1.0
set perceived-threat random-float 1.0
set active? false
set conflict 0
display-agent
]
; start clock and plot initial state of system
reset-ticks
end
to go
ask turtles [
; Rule M: Move to a random site within your vision
if (breed = agents and conflict = 0) or breed = threats [move]
; Rule A: Determine if each agent should be active or quiet
if breed = agents and conflict = 0 [ determine-behavior ]
; Rule C: Threats attack a random active agent within their radius
if breed = threats [ attack ]
]
; Agents engaged in conflict have the duration reduced at the end of each clock tick
ask agents [ if conflict > 0 [ set conflict conflict - 1 ] ]
; update agent display
ask agents [ display-agent ]
ask threats [ display-threats ]
; advance clock and update plots
tick
end
; AGENT AND THREAT BEHAVIOR
; move to an empty patch
to move ; turtle procedure
if movement? or breed = threats [
; move to a patch in vision; candidate patches are
; empty or contain only jailed agents
let targets neighborhood with [
not any? threats-here and all? agents-here [ conflict > 0 ]
]
if any? targets [ move-to one-of targets ]
]
end
; AGENT BEHAVIOR
to determine-behavior
set active? (burden-sharing - conflict-aversion * estimated-conflict-probability > threshold)
end
to-report burden-sharing
report perceived-threat * (1 - alliance-protection)
end
to-report estimated-conflict-probability
let t count (threats-on neighborhood)
let a 1 + count (agents-on neighborhood) with [ active? ]
; See Info tab for a discussion of the following formula
report 1 - exp (- k * floor (t / a))
end
; THREAT BEHAVIOR
to attack
if any? (agents-on neighborhood) with [ active? ] [
; arrest suspect
let suspect one-of (agents-on neighborhood) with [ active? ]
move-to suspect ; move to patch of the jailed agent
ask suspect [
set active? false
set conflict random max conflict
]
]
end
; VISUALIZATION OF AGENTS AND COPS
to display-agent ; agent procedure
set color cyan
set shape "triangle"
end
to display-threats
set color red
set shape "circle 2"
end
; Copyright 2004 Uri Wilensky.
; See Info tab for full copyright and license.

First, a suggestion: when you copy a block of code into a Stack Overflow question or answer, you should format it as a code block. It is much easier to read that way.
The problem that you are encountering is because the patches-own variable neighborhood has not been initialized and therefore NetLogo uses the number zero as the default. In modifying the library's rebellion code you dropped the 4th and 5th lines of
ask patches [
; make background a slightly dark gray
set pcolor gray - 1
; cache patch neighborhoods
set neighborhood patches in-radius vision
]
the lines in setup that initialize each patch's neighborhood variable. Adding them back should take care of the error you are encountering.

Related

How to increase Transcript buffer size?

I am working with Pharo 3 and I use the Transcript to record operations.
However the size of the current buffer is short for my needs. How to increase it? There is characterLimit but this is a method constant and therefore not easy to set up without changing a core package.
I do not want to use NonInteractiveTranscript because I want to stay in the image.
No, there is no other way to change the buffer length of the Transcript then to modify #characterLimit (usually of ThreadSafeTranscript). However, try inspecting ThreadSafeTranscript allInstances and you'll see that the underlying stream is much longer (50000 something is the write limit there). So, whatever you're printing to Transcript is not actually lost but just not visible.
That being said, using Transcript for extensive output is generally not a good idea because:
output is cut off (as you've already seen)
Transcript is really slow when called repeatedly:
try
1 to: 10000 do: [ :i | Transcript show: i ]
vs.
Transcript show: (String streamContents: [ :stream |
1 to: 10000 do: [ :i | stream nextPutAll: i asString ] ])
you can't use the output somewhere else (e.g. to write to file or pass along to a method)
In my opinion Transcript is ok for occasional quick debugging but shouldn't be used for anything application related.

How do I remove all "black pixels" from a binary (image)?

I am looking for the best performing code, which removes all black pixels = #{000000} from a binary. Code Example:
img: make image! [100x75 0.0.255]
loop 1000 [change at img random 99x74 0.0.0]
probe length? foo: copy img/rgb
probe delta-time [remove-each [r g b] foo [ all [zero? r zero? g zero? b] ]]
probe length? foo
foo: copy img/rgb
probe delta-time [trim/with foo #{000000}]
probe length? probe foo
Trim performs quite fast but doesn't work as supposed, as it removes all zero-byte #{00} from the binary.
What is the fastest code to remove all "black pixels" = three zero-bytes = #{000000} from a binary? Any further suggestions? Might be using parse performs better?
Using PARSE and creating a new binary series should be the fastest method:
probe length? foo: copy img/rgb
new: make binary! length? foo
probe delta-time [
parse foo [any [s: #{000000} | 3 skip (append/part new s 3)]]
]
probe length? new
Here it performs almost twice faster than using REMOVE-EACH.
four times faster than Remove-each example :-)
print "=========="
probe length? foo: copy img/rgb
new: make binary! length? foo
probe delta-time [
parse foo [
here:
there:
any [
#{000000} (append/part new here there ) here: there:
| 3 skip there:
]
(append/part new here there )
]
]
probe length? new
results
; remove-each
==========
0:00:00.003395
19683
; parse with concatenated append
==========
0:00:00.000872
19683

How do I sleep for a few seconds in Smalltalk Pharo, and be able to interrupt this?

I'm debugging some keyboard event code and I want to loop with a sleep (to give me a chance to create the keyboard event), however when I do this Pharo won't let me quit with Command-. so debugging is difficult. I had to wait 500 seconds to fix something in the code below...
100 timesRepeat: [
Transcript show: 'Type an a... '.
(Delay forSeconds: 5) wait.
(Sensor keyPressed: $a) ifTrue: [ Transcript show: 'you pressed a' ].
]
So how can I make Command-. work, or is there something more suitable than (Delay forSeconds: 5) wait.?
Works fine in Squeak on Mac OS X (using peekKeyboardEvent, it does not have keyPressed:). So it's not your code's fault, interrupting this should work fine.
I am not entirely shure this works in Pharo, but in Squeak you can just fork your code in a new process, so it does not block the UI:
[
100 timesRepeat: [
Transcript show: 'Type an a... '.
(Delay forSeconds: 5) wait.
(Sensor keyPressed: $a) ifTrue: [ Transcript show: 'you pressed a' ].
].
] fork.
I just started with Pharo and it seems what you're really running into is still an issue among beginners (myself included). Looking at your code it seems you want to the Transcript to update every 5 seconds. Here is how to do it (comments included to make certain nuances clear).
| process | "If you're running outside a playground, you should declare the variable, otherwise you should not declare it because it needs to bind to the playground itself"
process := [
100 timesRepeat: [
Transcript show: 'Type an a... '; cr. "I like a newline, hence the cr"
(Delay forSeconds: 5) wait.
"In Pharo 10, the following doesn't work, still need to figure out how to do this"
"(Sensor keyPressed: $a) ifTrue: [ Transcript show: 'you pressed a' ]."
]
] fork.
process terminate. "You can run this to terminate the process inside the playground"
process suspend. "Also possible"
process resume.

Minimise namespace pollution when copying data with parse

When using parse to extract values from data I often end up declaring globals to capture the copy data.
For example,
numbers: none
rule: [ thru 5 copy numbers to 10 to end ]
parse [ 1 2 3 4 5 6 7 8 9 10 ] [ rule ]
What would be the best way to do this without using numbers as a global?
Should I define a context to wrapper the whole lot or is there a more elegant solution?
In terms of R2. Yes, wrapping the whole lot in a context (using CONTEXT) is straight forward. You could also do this using USE:
use [numbers][
numbers: none
rule: [ thru 5 copy numbers to 10 to end ]
parse [ 1 2 3 4 5 6 7 8 9 10 ] [ rule ]
]
And as Graham says, use the local variable of a function which will set NUMBERS to none by default.
I often will use USE to convey to myself that the context is transient, or to create a private context.
A context won't work without declaring the variables inside the context
>> unset 'a
>> context [ parse "aa" [ copy a to end ]]
>> a
== "aa"
In the same way you can use your parse rules inside a function with the variables declared as local to stop them polluting the global name space.

How to tell an IP address with 4 LEDs?

I am developing a net-managed device with the .NET Micro Framework. Since the idea is to have a bunch of devices in an office, sometimes it is necessary for the user to know the IP address of a specific device.
So I've been trying to come with ideas on how to indicate the IP address the user. The only user interface is 4 LED lights that I can blink on and off at varying speeds.
So far, the best idea I could come up with is this: seeing how the IP address has 4 parts and I have 4 LEDs, it would make sense that each LED be responsible for a single IP address part.
So for address like 192.168.0.34, I'd have LED1 blink once, then pause, then blink 9 times, pause, then blink 2 times. The action would then shift to the LED2, which would blink out 168 in a similar manner and so on. Number 0 would be indicated by blinking really fast for half a second.
Any other ideas?
Use all 4 displays at once for each number, showing it in binary. Blink all 4 really fast for a 0, light all 4 longer to denote a point.
[ ] [ ] [ ] [x] # 1
[x] [ ] [ ] [x] # 9
[ ] [ ] [x] [ ] # 2
[x] [x] [x] [x] # . (long)
[ ] [ ] [ ] [x] # 1
[ ] [x] [x] [ ] # 6
[x] [ ] [ ] [ ] # 8
[x] [x] [x] [x] # . (long)
[x] [x] [x] [x] # 0 (short)
Alternatively you can use an un-used number (ie: 10) to denote 0
[ ] [ ] [ ] [x] # 1
[x] [ ] [ ] [x] # 9
[ ] [ ] [x] [ ] # 2
[x] [x] [x] [x] # .
[ ] [ ] [ ] [x] # 1
[ ] [x] [x] [ ] # 6
[x] [ ] [ ] [ ] # 8
[x] [x] [x] [x] # .
[x] [ ] [x] [ ] # 0
Having a lookup table ready by the device should be enough for those who don't know binary.
I'd do the reverse. From a control station, I would bring up a list of all IPs used by my devices. I'd then select one to start blinking in a pattern that would be easy to recognize (like 1 2 3 4 over and over) until shut off. That way I could ask everybody who's LEDs are blinking like that and know what device owned that IP.
I'd then write the IP on the bottom of the device in magic marker. There's an amazing amount of bandwidth in a sharpie.
Provide a well-mounted cord for the user to swing the device around in the air like a lasso
Then flash the LEDs like a propeller clock
(source: embedds.com)
You might also consider binary, displaying a single digit at a time. But this would require the user to know (or take a crash course on) binary.
9: 1 0 0 1
8: 1 0 0 0
7: 0 1 1 1
6: 0 1 1 0
5: 0 1 0 1
4: 0 1 0 0
3: 0 0 1 1
2: 0 0 1 0
1: 0 0 0 1
0: 0 0 0 0
To indicate the decimal point, you could show 1 1 1 1. It would be ideal if you had a button or some form of user interaction so that you could iterate through the digits.
You could translate the number to HEX and print off the hex representation in binary.
F: 1 1 1 1
E: 1 1 1 0
D: 1 1 0 1
C: 1 1 0 0
B: 1 0 1 1
A: 1 0 1 0
9: 1 0 0 1
8: 1 0 0 0
7: 0 1 1 1
6: 0 1 1 0
5: 0 1 0 1
4: 0 1 0 0
3: 0 0 1 1
2: 0 0 1 0
1: 0 0 0 1
0: 0 0 0 0
192.168.0.34 becomes C0.A8.00.22. Very similar to the solution put forth by #JYelton, just taken a step further to reduce the amount of work an individual needs to do to read the message out of the LEDs. Still require a bit of translation though because you have to go from hex to decimal again (standard calculator is an easy/handy tool).
I'm thinking outside the box.. but one of the biggest complaints I see here is the translation. What about an app that takes a video (recording or prerecorded) and does the interpretation? This reminds me of iphone apps that can read upc codes.
Alternatively, but along the same thought, what about a parallel port or usb?
Why don't you get an external LCD screen... no teaching users binary and you can display loads more information. If you provide me with which micro framework device you are using I may be able to provide more detailed help.
LCDs - SparkFun <= good products and service
LCDs - Jameco
LCDs - Mouser
Could do it the way that the pulse dialing worked in the phone system. Basically one blink is zero, and it counts up from there.
1 = ** (2 blinks)
9 = ********** (10 blinks)
2 = *** (3 blinks)
Long Blink
1 = ** (2 blinks)
6 = ******* (7 blinks)
8 = ********* (9 blinks)
Long Blink
0 = * (1 blink)
0 = * (1 blink)
1 = ** (2 blinks)
Long Blink
2 = *** (3 blinks)
4 = ***** (5 blinks)
1 = ** (2 blinks)
Depending on how geeky your users are, you could also use:
Morse code
Display IP as a sequence of digits in binary
...
if it's DHCP, and they can access a list of the devices ip addresses on a computer next to the devices' MAC addresses, you could write the MAC address on each device and then they'd be able to tell which device had which IP.
If you think MAC addresses would be too un user friendly then you could have a table of the MAC addresses with a short description or the name of the devices.
Even more, you could write a program that got the list of ip addresses next to MAC addresses and matched it up with the table of device names next to MAC addresses.
If you replace one of the leds with an IR led, you can write an app for a cell phone IR sensor that decodes and displays the binary pattern for the IP address.
What about Broadcasting UDP packets and using a winforms app to listen for those packets. If you have multiple of these devices, the following might work.
Open Windows Client that is listening on the correct port.
Reset device or push a button on it to activate the UDP Broadcast.
Maybe combine the LED's flashing actively on that unit for 1 minute.
The Windows Client would then receive the IP Address and any other status information.
There may be an option here to set a unique ID (1-16 binary) in the device that is displayed on the device and broadcast with the IP Information. (??DIP Switches??)
This gets away from having users interpreting binary flashing of the LED's.
So device 1010 shows it's LED's and the output in the Windows App shows
On, Off, On, Off = 192.168.0.150
If you got fancy with this using Images of an LED On and Off would be even better.
I'm in a similar situation and haven't tested these theories yet.
Well, does the IP address need to be interpreted by a machine or by a human? Because your suggestion is using decimal digits, which is wonderful for humans but very complicated for computers to understand.
IP addresses are actually just a 32-bit binary number. The IP 192.168.0.34 is seen by the router (and broadcasted across the internet) as 11000000 10101000 00000000 00100010
If you're having a computer or other hardware device interpret the IP address, I suggest just using binary. You could have one light which displays the next digit, and another which toggles a "ready" light to indicate that the digit is in fact the next one and not a repetition of the previous one. This would only require 2 LEDs, and you would essentially display the aforementioned address like so:
on on,
on off,
off on,
off off,
off on,
off off,
off on,
off off,
on on,
off off,
on on,
off off,
on on,
off off,
off on,
off off,
etc.
Make sure the second bit has toggled before reading the first bit, otherwise you could read the same number twice.
If you want to display it using four LEDs for human interpretation then having the LEDs blinks according to digit might be difficult since humans have trouble counting 4 numbers simultaneously. It may be easier if you just went through all the digits 1, 9, 2, 1, 6, 8, 0, 0, 0, 0, 3, 4 (3 digits per number) and displayed these in binary using all four LEDs.
off off off on,
on off off on,
off off on off,
etc.
With a pause in between each one.
Adding an LCD display would work really well, but would add a lot to the cost. However, what about using 8 LEDs instead of 4? If you purchase the 8 LEDs in the form of a 7-segment LED display with decimal point, it might not cost much more than 4 discrete LEDs, but it would let you display the decimal digits of the IP address sequentially. No complicated translation scheme for the users to master.
It depends on your environment, but I'd not display an entire IP address, just the component that is relevant, and map that itself to a single 4-bit number. This assumes you only need to uniquely identify < 2^4 entities. If you need more, then just use more LEDs (if possible).
In this way, you'd only need to indicate a local mapping, which could then be used to look the actual IP address up via a local internal website. You can use the typical binary strategy that's been described in this thread already to have the LEDs flash out a 4bit number, and it should be pretty easy to train people on (which appropriate labeling on the device).