Since when is 4 > 14?!

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)


And yes, I know I literally just had an issue with this thing not too long ago, I'm probably just a very bad coder.

The carry in is a 1, or true input to represent subtraction in Sebastian Lague's simulated ALU.

Update (Apr. 4 2:59 PM): the adder is working, but it's now just 1 bit off of reporting the output I want.


New script:
Solution Script?

You have the bits backward. They're in the right order in the block's header, but you set add1 to the sum of the two leftmost bits, etc.

Alright...
I don't know why this is so difficult for me, but it's fine.
Thanks though.

So, I should reverse the order like this?
New Script

Carrying goes from right to left (from less significant to more significant).

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.

I'm swapping the bits?
How?
I thought 4-bit binary bits were ordered 8 4 2 then 1.
Is that not correct, or is it Snap!'s logic doing it differently?

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.

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.