I'm a part-time teacher (and full-time software engineer!) trying to write the disease spread simulation for BJC U5L2 before I have to teach it, and I gotta say, I'm not finding it easy. The jump from the cloning examples in TicTacToe and the touching sensing with Alonzo early on, to the disease spread simulation, seems a pretty big jump, unless I'm missing something obvious. Do other teachers report they are able to turn their students loose on this assignment as written in BJC and they are able to figure it out? I'm pretty sure almost none of my students could.
Anyways, here's what I've come up with for a start. But whether the clones successfully detect that they are touching each other and change their costumes depends how much wait time is given before the next 'move' signal is broadcast.
Is there some rule about timing for the 'touching' block? Have I organized the per-clone code in such an inefficient way the touching tests are taking longer than they should?
OK, I had never seen 'Stamp' mentioned in the BJC curriculum, or noticed it in Snap!, but searching, there it is. BJC suggests using clones for this exercise.
Pay no attention to him, of course you should use clones, because they move around.
The most important way to speed this up is to use the MY NEIGHBORS block, in Sensing. It gives you a list of the sprites (including clones) that are near the current sprite. When there are a lot of clones running around this is especially important.
Do you have access to our solution file for this page? If not, drop me an email (bh@cs.berkeley.edu).
Oh yeah, I forgot about the teacher's resource guide, I do have access and will check that out.
I saw 'my neighbors', but didn't get an understanding of what 'near' means.
I was a little concerned whether a mostly-solution should be posted, as an online shortcut that shouldn't be available to students. If necessary, I can de-embed from my original post.
OK I found the solution script, and played with it a little bit.
I was surprised, inside the 'touching infected person?' custom block, the touching and ask blocks left the first argument unfilled, rather than having to drag 'item' in from the for block. Is that a thing, for unfilled parameters inside for/item? I am familiar with keep/combine/map, but didn't know it was more general.
back to the original post, I was revisiting the bjc teachers' guide solution for the U5L2 disease spread simulation, and for some reason it is not operating correctly. All the clones initialize with a handful red/infected, and they wander around and quite clearly touch each other but no infection is ever passed on. Did something change?
(More generally, are the BJC materials to any extent a work in progress? or are they finalized/tightly version-controlled?)
ANNNNND today when I look at the same snap project I left in a tab, it's working as expected again.
Is there any reason (other than 'rebooting fixes things') a snap project would work one day and not the next? Or more probably run fast (enough) one day and not the next?
Yeah, someone posted about this problem on Piazza and I fixed it. The problem wasn't an error in the solution; it's that Snap! 6.7.2 changed the behavior of FOR EACH and I was relying on the old behavior, which was fine until a few days ago.
FOR EACH. The numeric FOR always behaved this way.
FOR EACH is like the child of FOR and MAP. In its youth, it didn't have the ITEM upvar; its name was FOR EACH ITEM OF, and it used implicit substitution, like MAP. Then we added the upvar, and for a long time it worked both ways. But every so often someone would want to use an empty text string as an input and would be confused by the result, so I finally gave in.
I had a similar problem (infection not spreading), but a different solution. When comparing my code to the solution, I noticed one difference in my "touching infected person?" block.
The issue was that when I dragged the "infected?" variable into the "ask _ for _" block, the ring disappeared. To restore the ring, I had to right-click on "infected?" and choose "ringify". After restoring the ring, my code worked correctly.
Thx, I had another thread where re-ringify was the answer, but I can't remember what that was. There was some discussion of whether there are some circumstances where Snap! should default to stay-ringified instead of de-ringifying.
Yeah, any time we use a "do what I mean" technique we run the risk that some people won't mean what we think they mean. :~) The saving grace is that the people who mean something different generally aren't beginners, so we can expect them to read the manual!
Another example is that when you make a clone, it shares some attributes and copies other attributes, based on Jens's idea of what you mean. I argued for sharing everything, but Jens pointed out that that would break all the projects in which people number the clones by incrementing a local variable each time they create one. And that convinced me.