Simple question:

[Lior]

I have a simple math question which I think has no solution at all:

How can I convert two numbers into one number, that when I'll tell my friend this number, he will be able to tell me what were the two original numbers.

Remark: All of the numbers are natural numbers between 0-255.

Thanks in advance,

[kedaman]

I think you should give up. If someone here could beat the already known compression algoritms even slightly, it's probably very hard to get any marketting benefit of it, but most of all, they wouldn't spend their genious minds on giving you the profits.

[Lior]

What are you talking about?

I just asked a simple question, if you dont have an idea for a solution - why to post?

[kedaman]

for your simple qwestion, there is no solution.
I posted since you've been trying to make a compression algoritm for ages, and don't seem to have a clue what you are on yet.

[DavidHooper]

...I'll give it some thought and let you know if I have any bright ideas.

I would proceed along these lines of thought:

1)Prime Factors. Not straight-forward.
2)Something like, if one number is x and the other is y then use say:

256^x + 256^y = z. then each solution of z is unique.

Whether it would be easier to use * instead of + and maybe a number other than 256...

[Lior]

Well... Thanks for trying to help, but you have to remember that the output number should be also between 0-255.

Besides, let's say that you dont have the convert each 2 numbers into only 1, try to convert n numbers into less than n numbers.

it can be 10 into 8 or 8 into 5 etc...

Besides, it doesnt have to be so nice like an equation that each X numbers are converted into exactly Y numbers.

A method that converts while it depends on the sequence of the numbers, is also good.
I mean, a sequence of 10 numbers can be converted into 8 number or sometimes under certain circumstances, it will be converted into only 5, e.g.


Thanks again.

[nishantp]

kedaman is soo right. The only reason you could want something like this is for a compression algorithm. You even say that the nums should be less than 255, which by coincidence happens to be the number of codes in the ASCII character set. If someone did have code like that...they're way to smart to be roaming around here.

[Lior]

So I guess I've found another one who doesn't know the answer for this, nevermind, another one to the collection of such minds.

[DavidHooper]

Well Lior, the only way I can think of doing this would be to reserve lots of the numbers between 0 and 256.

So, assuming you're doing compression, then two ASCII codes between 90 and 116 (or whatever a-z is in ASCII codes) would be changed to a reserved number between 0 and 90 or 116 and 256.

There aren't enough reserved codes for all combinations though so you would have to scan for the most used combinations.

Then you need a table included with the compressed file to decode the information.

[Lior]

Thanks but:
1. there are not enough reserved codes for all combinations, as you said.

2. when I save 2 chars into one char, when extracting it back, the program will not know if the char is acctually 2 chars encoded, or a separate char that was not given a reserved code.

But thanks anyway.

[unformed]

here's why it's not possible, at all:

1) you want to turn two 1-byte numbers (0-255 each) into one 1-byte number (0-255) and be able to retrieve the two original numbers.

The output has a maximum of 256 distinct possibilities, but the input has a maximum of 256*256 (65536) possibilities.

There is absolutely no way you can give each set of two numbers a unique one-number match.

Hopefully that made some sense...

[nishantp]

Unformed is right Lior. You make say im another one who doesnt knoe the answer...well there is no answer. Its **impossible**, but of course im sure that wont stop you from trying.Lol have fun.

[Destined Soul]

I agree with uninformed and nishantp - you will have to put restrictions on the range of the original two numbers, or expand the range of the final one.

As well, you might be able to use probabilities and combinations to guess what the input numbers were, but this won't be a 1-to-1 transformation.

(if I pick two numbers, and tell you the result was 100, who was to say that one of my two original numbers (if not both) isn't 100?)

However, one thing that wasn't mentioned is that the decoder might have a "key" that helps him/her how to determine the numbers. Just a thought. :cool:

Destined