I am using a touch sensor that reports the status of twelve sensors as a decimal number. This number must be converted to binary to determine the state of the sensors. For example, if the sensor chip reports the number 5, this would resolve to the binary output "1 0 1", indicating that sensors 1 and 3 were being touched.
I wrote a procedure to convert the decimal number provided by the touch sensor chip to binary:
Yes, your algorithm, using MOD to pull off digits, is mathematically elegant. Having said that, one of the times I lost an argument in developing BJC for high school students is that all my EDC colleagues said that kids can't understand that algorithm, and that instead the way to do it is
See this BJC page.
I think you'll agree that this is mathematically uglier, but apparently long experience shows that most kids get it this way but not your way.
I see you made that picture of your script by screen capture. Do you not know about the "script pic" feature?
Your actual code is needlessly ugly because you use imperative rather than functional programming. Here's how you should write it:
(The reported list has the low-order bit first; if you wanted to display the binary numeral you'd report a text string made with JOIN with the inputs in the other order. But IN FRONT OF has to be in this order.)
You have pushed one of my buttons. There is no such thing as "converting decimal to binary." What we are doing here is converting a number to a binary numeral. Numbers don't have bases. The reason everyone gets confused about this is that, of course, you can't display a number directly; you have to use some representation, and in modern European-influenced cultures the convention is to use base ten Arabic numerals. (Unicode has different Chinese digits, and I'm not sure those are used base ten, but I'm pretty sure that even the Chinese mostly use Arabic digits these days, in left-to-right order, even.) But when Snap! displays a string of decimal digits to you, it's doing its best to show you a number. It's the number that matters, not the fact that we happen to represent it in decimal.
This isn't just quibbling; the reason students find it hard to write programs to do the conversion is that they think the input and the output are comparable data types, namely, representations of numbers in two different bases. But if you look at the code carefully, you'll see that we operate on the input using arithmetic functions: / and mod. By contrast, we don't do arithmetic on the output; we assemble it as a string of digits. Compare this:
Here we use text string processing on the input, and we use arithmetic functions to compute the output. Note that the input to this procedure has type text, not type number (i.e., it's a rectangular slot).
Even this is sort of cheating. This code takes advantage of the fact that Snap! does automatic conversion between numbers and strings of (decimal) digits. Where it says it really should say
. This would be important if we wanted to convert between numbers and hexadecimal numerals, some of which don't look like numbers to Snap!. (Go ahead, write that program in both directions — an exercise for the reader. :~) )
I am glad that you think the algorithm is elegant, because it is your algorithm. (I just borrowed it.) [smile]
I see you made that picture of your script by screen capture. Do you not know about the "script pic" feature?
Everyone in the lab but me uses "script pic", and loves it. I used screen capture back in the day, and never adapted to modern conveniences.
Your actual code is needlessly ugly because you use imperative rather than functional programming.
This is the part in which I am most interested. Even though the method that I used works (i.e., reports the status of the touch sensors correctly), the recursive approach that you illustrated is more elegant.
We're developing this in the process of developing a library to enable Snap! to communicate with microcontroller via MicroBlocks. Since the point of a library for MicroBlocks is to relieve users of the fine details required to communicate with the microcontroller, I'm assuming that most folks won't have a reason to look under the hood. But if anyone does, it would be nice for it to provide a good model for implementation.
Thanks so much for these thoughtful recommendations.
Did you know, since v8, when someone uses the script pic function to bring a script to the forum, we can import that script directly into a snap project without having to re-write all the code.
What browser are you using? In chrome, when I save a file (such as by making a script pic) the file's name shows up on a bar at the bottom of the browser window, from which it can be dragged into the forum window. Easy peasy!
The same thing works in Firefox if you install the Download Statusbar extension.
We should probably start a new thread with a different title for this topic, but I tried script pic, and it seemed to work as advertised.
However, that leads to two questions:
We use DropBox for all of our joint work. However, script pic (in my case, at least) put the image in the downloads folder of the local PC. That is not unexpected, but it is a hassle to fish it out of the downloads folder on the local PC, and put it in the correct folder of DropBox. SnagIt, the Techsmith Capture program that I use, allows me to set a default directory for captures. ... Is it technically feasible to do this with scrip pic? It would save quite a bit of overhead.
I imported a scrip pic image into a PDF. Not unexpectedly, saving the image from the PDF stripped out the scrip pic magic. If images of blocks in a PDF could be saved out with the scrip pic magic intact, this would be a useful resource for students. Do any PDF gurus know if there is a clever way to do this?
As for your second question, it sounds as if your pdf-creation program is removing the metadata on purpose (perhaps as a privacy option?). Or, if you tell it to change the size or something, that will generate a new png without the metadata. In short, it's beyond our control.
Yes, for that I would need to post in a PDF Forum rather than the Snap! forum. However, the range of expertise of the Snap! community goes so far beyond Snap! across many different topics that I thought that I would check here first.
We compose our documents in Word before converting to PDFs, so I thought I would start by exploring whether a script pic could be imported into Word without loss of metadata. I thought that part of the answer might lie in enabling the option to turn off image compression.
However, that appears not to be the entire answer. As a next step, I'll need to ask some of the CS folks to look into it, and determine what's required to import an image into Word without loss of metadata.
it really should say 
and enable choosing what folder/filename downloads go into, then this problem evaporates
