A+B=C

[fredreload]

As the equation says A+B=C, let's say I add 7(A) and 9(B) to get 16©, is it possible to reverse engineer 7 and 9 by only knowing 16? It can be in binary or anything. I'm trying to get the value for A and B with C=16 and without knowing what A and B are

 

An idea would be to mesh the binary bits together like, A=0111, B=1001, C=0111 1001, but that makes C bigger to have a value of C=64+32+16+1 = 113. I need to make this value smaller then the previous two numbers, which should only contain 4 bits, so the maximum value would be 1111 which is 15

 

 

Reverse half adders?

Edited August 19, 2016 by fredreload

[swansont]

As the equation says A+B=C, let's say I add 7(A) and 9(B) to get 16©, is it possible to reverse engineer 7 and 9 by only knowing 16? It can be in binary or anything. I'm trying to get the value for A and B with C=16 and without knowing what A and B are

 

An idea would be to mesh the binary bits together like, A=0111, B=1001, C=0111 1001, but that makes C bigger to have a value of C=64+32+16+1 = 113. I need to make this value smaller then the previous two numbers, which should only contain 4 bits, so the maximum value would be 1111 which is 15

 

 

There are a number of values that would work, e.g. 8+8, or 10+6, so no, you can't reverse-engineer this.

 

Two unknowns means you need two (independent) equations in order to come up with a unique solution.

[fredreload]

 

 

There are a number of values that would work, e.g. 8+8, or 10+6, so no, you can't reverse-engineer this.

 

Two unknowns means you need two (independent) equations in order to come up with a unique solution.

Make sense, but all I need are smaller numbers , working on a compression algorithm

 

 

There are a number of values that would work, e.g. 8+8, or 10+6, so no, you can't reverse-engineer this.

 

Two unknowns means you need two (independent) equations in order to come up with a unique solution.

My bad, it does matter, I'm thinking the circuits' unique setup would distinguish the numbers, I could be wrong

[fredreload]

Swap the bits so that a 0 and 1 with 0 always on top

[michel123456]

As the equation says A+B=C, let's say I add 7(A) and 9(B) to get 16©, is it possible to reverse engineer 7 and 9 by only knowing 16? It can be in binary or anything. I'm trying to get the value for A and B with C=16 and without knowing what A and B are

 

An idea would be to mesh the binary bits together like, A=0111, B=1001, C=0111 1001, but that makes C bigger to have a value of C=64+32+16+1 = 113. I need to make this value smaller then the previous two numbers, which should only contain 4 bits, so the maximum value would be 1111 which is 15

 

 

Reverse half adders?

So you want to keep in C the "memory" of A + B?

The best way is not to make the operation at all, simply keep A+B

 

Otherwise the result C can be the result of many other operations as Swansont pointed.

Edited August 20, 2016 by michel123456

[Sensei]

An idea would be to mesh the binary bits together like, A=0111, B=1001, C=0111 1001, but that makes C bigger to have a value of C=64+32+16+1 = 113.

Actually, %0111 and %1001 in half-bytes, is %01111001 which is decimal 121, not 113.

 

It's called left-bitwise-shift, arithmetic shift.

https://en.wikipedia.org/wiki/Bitwise_operation

 

a=%0111;

b=%1001;

c=(a<<4) | b;

(left-shift a by 4 (=multiplication by 16), then bitwise or b (there is 0 in these bits))

 

I need to make this value smaller then the previous two numbers, which should only contain 4 bits, so the maximum value would be 1111 which is 15

If you add %0111 + %1001 what you will get is %10000, not %1111 (15).

If you want to keep result in 4 bits,

it should be min(a+b,15),

or

c=a+b;

if( c >= 16 ) c=15;

(of course you will lose higher values than 15)

Edited August 20, 2016 by Sensei

[Strange]

An idea would be to mesh the binary bits together like, A=0111, B=1001, C=0111 1001, but that makes C bigger to have a value of C=64+32+16+1 = 113. I need to make this value smaller then the previous two numbers, which should only contain 4 bits, so the maximum value would be 1111 which is 15

 

 

The sum of two N bit numbers will require up to N+1 bits.

 

The product of two N bit numbers will require up to 2N bits.

[fredreload]

 

 

The sum of two N bit numbers will require up to N+1 bits.

 

The product of two N bit numbers will require up to 2N bits.

Hi Strange, alright the idea about addition is that it is commutative, meaning if you walk backward on that full adder circuit you always have to choose between a 01 or 10. The thing is for a substract it is not commutatibe, but a full substractor circuit you need to keep the current going in order to move backwards and decode what the original information is because you don't have the information on carry in and carry out bit, so maybe some way of putting these two circuits together

 

http://ustudy.in/sites/default/files/fullsub.gif

 

P.S. My idea is I'm trying to make a compression algorithm by shrinking the bits, if I can get an 8 bits information from 4 bits alone it would be wonderous, but I doubt it's possible

Edited August 22, 2016 by fredreload

[Sensei]

P.S. My idea is I'm trying to make a compression algorithm by shrinking the bits, if I can get an 8 bits information from 4 bits alone it would be wonderous, but I doubt it's possible

 

You can do that by using library of common repeated patterns, and using index/id to that array, as stored compressed data.

Library can be static and not attached to data, or dynamic and be part of data, or mixture of both.

f.e. you have my text reply. Find repeating characters,words in it, and assign the smallest possible number of bits to the most repeatable parts.

Normal character is taking 8 bits. If you assign code to the whole word, the whole phrase, you can compress size dozen of times.

Edited August 22, 2016 by Sensei

[Strange]

Hi Strange, alright the idea about addition is that it is commutative, meaning if you walk backward on that full adder circuit you always have to choose between a 01 or 10.

 

That is not what commutative means.

 

 

The thing is for a substract it is not commutatibe, but a full substractor circuit you need to keep the current going in order to move backwards and decode what the original information is because you don't have the information on carry in and carry out bit,

 

That makes absolutely no sense.

 

 

P.S. My idea is I'm trying to make a compression algorithm by shrinking the bits, if I can get an 8 bits information from 4 bits alone it would be wonderous, but I doubt it's possible

 

Maybe you should study compression algorithms. You might be surprised to find that a lot of work has been done on this already. You could start with run length encoding as one of the simplest (and still useful) techniques.

 

Whether you can (on average) compress 8 bits to 4 depends on the data.

[fredreload]

Modify the D output for substractor? RLE is quite efficient if I use the factorial hmm

[Strange]

RLE is quite efficient if I use the factorial hmm

 

Why do you keep mentioning factorials? How is that connected?

 

The efficiency of RLE depends on the structure and patterns in the data. Which is true for all compression algorithms.

[fredreload]

Man, and I really thought there's a way to do this, you had my hope up Strange = =

[fredreload]

Ah I get it, eventually you'll get a single BORin, BORout, and D and you move backward from there

I forgot BORin and BORout can be 0

[fredreload]

My bad guys, I should mention that if you want to back solve the circuit eventually you need all Borin Borout and D to back solve A and B, if Borout is missing it won't work either

[fiveworlds]

P.S. My idea is I'm trying to make a compression algorithm by shrinking the bits, if I can get an 8 bits information from 4 bits alone it would be wonderous, but I doubt it's possible

 

Most compression algorithms use bits that aren't normally used. For instance lets say my computer can read 64-bit which is

 

0000000000000000000000000000000000000000000000000000000000000000

 

Then lets say that I want to store numbers I can store a number with 4 bits.

 

0 = 0000

1 = 0001

2 = 0010

3 = 0011

4 = 0100

5 = 0101

6 = 0110

7 = 0111

8 = 1000

9 = 1001

 

Now lets say my computer stores the number 19 in 64 - bit it could be stored something like this (It probably isn't).

 

00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000001001

 

The same number in 4 bits is

 

00011001

 

We can see the excessive use of space here a bad compression algorithm could use 64/4 or 16 numbers

 

0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0001

 

however a good compression algorithm could have 2^64/16 or 1152921504606846976 numbers.

 

Decompression was generally handled by the cpu until hd televisions came out then gpu accelerated video decoding became more of a thing.

[blue89]

As the equation says A+B=C, let's say I add 7(A) and 9(B) to get 16©, is it possible to reverse engineer 7 and 9 by only knowing 16? It can be in binary or anything. I'm trying to get the value for A and B with C=16 and without knowing what A and B are

 

An idea would be to mesh the binary bits together like, A=0111, B=1001, C=0111 1001, but that makes C bigger to have a value of C=64+32+16+1 = 113. I need to make this value smaller then the previous two numbers, which should only contain 4 bits, so the maximum value would be 1111 which is 15

 

 

Reverse half adders?

 

 

hi , I am not engineer. I am mathematician and my studies are closely related with mathematical engineering.

I could not understand well your question well why (presumably) because of I have not enough knowledge relevant engineering.

 

but ;

 

AS EXTERNAL INSTRUCTION

 

I would remind that we cannot write this equation everytime: A+B = C

for instance if A is element of R³ and B is element of R⁴ ,then we will not be able to write this equation ..

but with extreme probability ajb's knowledge is higher than mine on this subject,I know this cannot be written everytime.

if he has enough time ,maybe he help you about your question.

 

blue

Edited August 27, 2016 by blue89

[fredreload]

 

 

hi , I am not engineer. I am mathematician and my studies are closely related with mathematical engineering.

I could not understand well your question well why (presumably) because of I have not enough knowledge relevant engineering.

 

but ;

 

AS EXTERNAL INSTRUCTION

 

I would remind that we cannot write this equation everytime: A+B = C

for instance if A is element of R³ and B is element of R⁴ ,then we will not be able to write this equation ..

but with extreme probability ajb's knowledge is higher than mine on this subject,I know this cannot be written everytime.

if he has enough time ,maybe he help you about your question.

 

blue

Hi blue, my solution for compression is actually in the A-B=C thread, you're free to check my math and come up with a better notation, I came up with it on the whim so it could be wrong. Thanks for your time

 

Most compression algorithms use bits that aren't normally used. For instance lets say my computer can read 64-bit which is

 

0000000000000000000000000000000000000000000000000000000000000000

 

Then lets say that I want to store numbers I can store a number with 4 bits.

 

0 = 0000

1 = 0001

2 = 0010

3 = 0011

4 = 0100

5 = 0101

6 = 0110

7 = 0111

8 = 1000

9 = 1001

 

Now lets say my computer stores the number 19 in 64 - bit it could be stored something like this (It probably isn't).

 

00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000001001

 

The same number in 4 bits is

 

00011001

 

We can see the excessive use of space here a bad compression algorithm could use 64/4 or 16 numbers

 

0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0001

 

however a good compression algorithm could have 2^64/16 or 1152921504606846976 numbers.

 

Decompression was generally handled by the cpu until hd televisions came out then gpu accelerated video decoding became more of a thing.

Hi fiveworlds, I came up with a solution on the A-B=C thread, I haven't found a way to reverse A and B from a circuit. My idea about the compression is pretty much A+B=C. Let's say you have 128 bits pattern like the one you have, you split it in half left and right so you have 64 bits on the left, that is your A, and 64 bits on the right, that is your B, the end result C is gonna have 64 bits. With this you've successfully reduced 128bits with A and B down to 64 bits C only. And it can be recursive, meaning you use C as 64 bits and you split it into 32 bits on the left, that is your A, and 32 bits on the right, that is your B. Eventually you are going to reduce all 128 bits into a single bit of either 0 or 1, my other thread of A-B=C requires you to store the bit information of A and B which takes around 2^6=32 or 6 bits to store this information for A and another 6 bits for B. You add this character bits on the way down that is 6+5+4+3+2+1 = 21 bits total from an 128 bits information. You can also reduce this character bits of 21 bits keys to a smaller value as well, but the work gets a bit tedious at this point. I would like to start with a 256 bit, essentially double of 128bits and it can be reduced down to 7+6+5+4+3+2+1=28 bits. But again managing this 256 information would be kind of tedious as well since it is out of the scope of ordinary integer storage so, well I'd love to hear from you guys

Edited August 28, 2016 by fredreload