So, @dardoro just helped me fix my 4-bit adder. Now there's a new issue that's way more complicated.
When I run the adder to do 0001 (1) + 0010 (2) + 1, the reporter thinks that it's greater than 14, but the result should just be 4. (Apr. 24 10:26 AM | Issue: all variables report 1, meaning the combined output is 1111, or 15. 15 > 14)
It's not just carrying. They're counting the ones bit as 8, and the eights bit as 1. (And similarly swapping 2 and 4.) Even if the particular numbers have no carrying, the answer will still be wildly wrong.
Read your code carefully! Look at the variables you're adding to make the ones bit of the answer, and look back to where those variables are named as inputs to your block. It's not some subtle mathematical thing; you understand the mathematics okay. You've just forgotten the names of your variables.
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.
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.
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.
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.
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.