Wait, so don't reverse the bits in all of the variable values, but just swap the order in each 1-bit adder?
No. Addition is commutative. The kind of swapping you're thinking of wouldn't change anything. No, it's changing the left-right order. Just read your code, see which variables you're adding in the rightmost adder, and see which inputs correspond to those variables.
Oh, alright. I'll try that this time.
It was so close to solving my problem! Is there anything I messed up on with this one?
I think what you're doing here is imagining that Snap! pays attention to what name you give each variable and understands what you mean it to be. But maybe I'm wrong and, like a lot of people, you just never really understood place value.
Here is the header of your block definition:
You want each set of four to be a binary numeral, as usually shown, i.e., 1000 means eight, not one. Right?
So the variable 1.1 is the leftmost bit, the one that represents eight, right? But because you called it ".1" you use it as input to adder1. Adder1 is the one that computes the rightmost bit of the answer. (We know that because you use carry1 as an input to adder2.)
So you need to take a deep breath and then work out which is left and which is right.
P.S. There are other issues, too; you seem to be doing the addition twice, and I don't understand why.
You mean the carry in value? That's for the ALU, to check for subtraction.
I'm just recreating this.
Never mind, SUM OF turns out to be a selector, not a computation. The name confused me.
But okay, look at DECIMAL CONVERT. You are multiplying adder1 by eight. Because it's the leftmost input to DECIMAL CONVERT you think it should be the most significant bit. But that doesn't fit with how you computed it.
Oh, sorry! I didn't think it would confuse anyone, but I see it now.
Alright, I guess it's starting to make sense. Could you explain a little bit more?
I don't know what more to say. Just take the bit that you think should represent eight and follow it through your code!
Alright.
Sorry that I need you to explain all this to me, I didn't know it'd be so difficult for me to copy such a simple thing into Snap!.
Yeah, I'm just dumb.
I feel like this would be simple for anyone else, but I'm just to inexperienced and stupid to figure it out.
The closest I've gotten is technically the correct answer, but its reversed.
So, 0100 is 4 in binary right?
When I run the block, it technically gives me 2 in binary, which is the reversed variant of 4.
Meaning: it outputs 0010 and the carry is 0.
What I want is the carry to still be 0, but the main output to be 0100, not 0010.
I know you're giving me the solution every time you reply, but the issue is I just can't understand it for some reason even though it should be obvious.
C'mon. You have a misunderstanding. Once you clear it up you'll be fine.
Maybe the easiest way to do this is just by converting the binary inputs to decimal numbers, add them, then convert it into a binary output. That way, there's no complication from the variables and 1-bit adders, and it's just using the basic pre-made addition reporters in the block palette.
I mean, it'd be easier to understand. (Probably not to code, though.)
All it'd be is this:
report (binary convert 4-bit (decimal convert 4-bit (binary input 1) (aka a list of boolean to binary conversions)) + (decimal convert 4-bit (binary input 2)))
That does seem simpler, right? It definitely has to be less blocks than originally.
I think that'd be considered cheating. The whole object of the exercise is for you to understand how binary works, not for you to just do what you already know. Anyway, your DECIMAL CONVERT has the same problem as the rest of the program, so you'd still need to understand what you're doing wrong.
I actually forgot to mention this, but I changed the decimal convert to a "full check" boolean function that checks if the output of all of the inputs will be greater than 14, and will report true if it is.
By the way, where did the 14 come from? 1111 binary is fifteen.
Yes, and 15 is greater than 14. That's what I check in the script.
My point is, 15 isn't an error.
then ill change it to >15
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.