Yeah, this on my list of things to do in my copious free time - make a “widget” version of the language so you can graduate to trying out the language on a “real” machine that will run it. It’ll come some day.
In the meantime, the artwork…is unfortunately made in a cockamamie format that I use to do graphics. At some point we should put into a google drawing format or something so it’s more universally accessible.
But…can’t you just take a screenshot of it from a document and paste that into an exam?
Hi there, @murzagaly-- it looks like @bhatnagars posted a response to @mmemmo’s question the first time around, but just to clarify:
answer keys are only available to teachers with validated accounts. this is to prevent students from accessing answer keys. if you are logged in with a validated account, you will see a blue ‘for teachers only’ box at the bottom of the linked page, containing links to the answer keys:
The blue For Teachers Only, never shows up on any of the pages I am on and I am logged into my account. I have filled out the above form as well. Please let me know asap how to access the KEY. The links on the side of the lessons, all go to the same place - the instructions; never the KEY. This is so frustrating!
Hi,
My students are getting confused between SHIFT and MOVE commands used in the Human Machine Language. Does anyone have a suggestion or a video that I can use to clarify this misconception.
Using them in context seems to reduce the possible ways they can be interpreted…
SHIFT is always followed by a direction, L or R. (ex: SHIFT RH to the L)
MOVE is always followed by a position. (ex: MOVE RH to position 3)
Transitioning from the hand-written instructions to the Human Machine Language implementation of the same find-minimum-card algorithm is turning out to be quite a challenge. The HML requires, what seems to me to be, a completely different mind set; the need to translate Move, Shift, Compare to awkward branching requires all lines of code to be present (i.e. it is hard to just throw some commands out there and give it a try to see how well it works).
One out of four students has come up with a solution in HML, and that one student has had prior programming experience (I translate that into this situation as possibly having a bit more fortitude to endure the challenge). That solution was pretty bizarre in itself.
Is there a teaching design methodology that has proven helpful with transitioning the students to the constraints of the HML (beyond the examples afforded in the activity)?
My own design process of this activity started with an IF-Then-Else flowchart, then after three iterations of translation towards HML I finally got to a 7-line HML solution. It was great to be able to use the simulator https://perryma.tk/HML/?swap !
I agree that HML requires a very different mindset from hand-written instructions (basically computer code vs “plan English”).
I think the curriculum does help the transition by first having students learn to read/trace HML before they write, but I also agree that it’s bit jarring/challenging having the first “writing” practice being a relatively difficult algorithm (not many of my students got it either).
If I was willing to dedicate more time to it, I would try giving my students smaller/easier challenges so they get more practice writing with the commands - maybe stuff like “write an algorithm that makes the right hand stop at card value 8” (can even tier that, so assume the card is present, then write code that accounts for the card possibly not being present, or if the card is present at position 0).
The simulator is indeed awesome, but I use it with caution because without the simulator, students are forced to read/trace their own code. With the simulator, some students turn it into a game of wild guessing since it requires no work on their part to “check” their code (although I guess I could say that about any other time students are writing code on the computer…).
I would be happy to work on that and post it here; it reflects a standard structured design approach to the problem. But I am not quite sure it will help the teachers much in their effort as it is outside the scope of the lesson’s objectives and would add quite a bit of time to the lesson to mentor the students through.
I agree with frank_w_lee that time might be better spent with smaller design challenges where the HML can have a chance to shine in its simplicity rather than be an implementation obstacle in a more complicated challenge.
Here are the design iterations that it took me to get to a 7-line HML solution …
@teacher that makes sense. I was thinking it might be useful to see some of the logic of these programs broken down in another way since I agree with the other posters, the HML definitely requires you to think in new ways. I agree that some simpler challenges make a lot of sense as well. There’s nothing special about “find-minimum-card” other than it’s fairly easy to understand the goal of the task and it seemed like a good stretch-goal of an algorithm as we were designing the task.
Hi Frank,
The first activity on Human Machine Language - Part 2 (Min to Front)
“What does this program do”?
I might be over thinking it, but I did it 10 times or so, sometimes landing on position 1, sometimes landing on position 2, is that the answer?
Is the idea to simply try out SWAP?
George hinted that we should magically go back to the same positions.
not seeing that. And then there are duplicate numbers (which can happen).
I am starting hands on on zero and 1. Maybe should be same hand position as the diaagram?
You are correct in starting your hands at 0 and 1.
Note the entire sequence doesn’t depend at all on the value of any card (which also means it doesn’t matter if it’s a duplicate number or not). This means your hands should have the same ending place every time when reaching “STOP” (and it’s a different place than they start at). (The comparison statement compares Left Hand Position and Right Hand Position.)
Because you are swapping, you do manipulate the sequence of the cards.
So, you sent (The comparison statement compares Left Hand Position and Right Hand Position.)
So we are simply looking at the position, regardless of what the card in the position is worth?
I was thinking it was the value of the card that was in the Left Hand *Position or *Right Hand Position was dictating greater than.
Wow - if so I really missed the point! Thanks, we are doing this tomorrow.
Yes, it’s a crucial distinction, as it will definitely make a difference in what the program does - and it’s subtle enough that many people overlook it.
