toughy math with averages

Started by
24 comments, last by ironfroggy 22 years, 9 months ago
b = c - 18

There is too a solution, just not a definite one...

incidently, TI will fully back up my claim that the matrix I represented has no existing inverse... that, or their 86 calcs don''t work right
--Tr][aD--
Advertisement
Well, if we were seeking relatoionships between the variables, then b = c - 18 would be a solution. But as we''re seeking the values of the four variables a, b, c and d, we have no (definite) solution.

Why do I belabor these things? Oh, well...
Don''t worry about this, it is IMPOSSIBLE as I now see.
If anyone ever does solve it, they have a way to compress ANY amount of data to only 4 bytes. Do that, and you are God.

(http://www.ironfroggy.com/)(http://www.ironfroggy.com/pinch)
We appear to have five equations and three unknowns, but watch what happens:

A2 = (a+b)/2
A3 = (b+d)/2
A4 = (a+c)/2
A5 = (c+d)/2

Without much effort:
a = d + 2*(A2-A3)
a = d + 2*(A4-A5)
b = c + 2*(A2-A4)
b = c + 2*(A3-A5)

All this means is that A2-A3 = A4-A5 and A2-A4 = A3-A5. Which means that in fact, you really only had three distinct equations to begin with.

Therefore, you have three equations and four unknowns, which makes solving it impossible. Simple.

For the record, there is no such thing as a compression algorithm which can compress everything - think about it.

Edited by - Beer Hunter on July 2, 2001 7:04:12 PM
Yea I knew that, pretty much. But I was sure these unknowns could be found. So, I''ve been trying to find out why its impossible for sure. Too bad. Imagine if it COULD work.

// God.c
void main() {
WORLD Earth;
LIFE People = Earth.CreateLife(HUMAN);
GiveHope(&People);
delete Earth;
EvilCackle();
}
(http://www.ironfroggy.com/)(http://www.ironfroggy.com/pinch)
as a random thought, if you write a bitwise compressor, it is possible to make a compressor that will never produce a ''compressed'' file significantly larger than the source... compress the file in ''blocks'' and put a bit in front of each block for ''compressed'' or ''uncompressed'', and at worst, it''ll be 1 bit bigger per block of the file

--Tr][aD--
--Tr][aD--
I used a method like that for the image format my game uses. It has some nice compression by interleaving RLE and RGB data, well, better that TGA anyhows
If at first you don't succeed, redefine success.
Actually, Triad, thats exactly what I am doing. Creating a Bitwise Compressor, as you call it. Its called BSZIP (check out sourceforge.net). The webpage isn''t up yet and no beta is finished yet either. I have a seperate library done tho, pretty much, for accessing data by bits. You can create sequences, copy them, reverse, read/write bits and sequences, etc. Soon I will add math to it. Anyone need to work with a 4 billion bit number? :o)

I have other methods of compression tho so this isn''t a big loss. Thats the big part of BSZIP, being able to use multiple methods of compression.

// God.c
void main() {
WORLD Earth;
LIFE People = Earth.CreateLife(HUMAN);
GiveHope(&People);
delete Earth;
EvilCackle();
}
(http://www.ironfroggy.com/)(http://www.ironfroggy.com/pinch)
Actually, I was thinking about mentioning that "use several algorithms" part... it sounds like a good idea...

...and no, I don''t want to work with that number, thank you

--Tr][aD--
--Tr][aD--
Interleaving RLE and RGB? Isn''t that what RLE is supposed to do anyway?

This...
222222 313346 2222222 44444 33333

should compress to this...
62 06313346 72 54 53

...according to the windows help. Check under BITMAPINFOHEADER, I think.


Huffman compression is good for using in conjunction with other algos. On its own, it averages out at about 30% compression, which is quite powerful. It works on a per character basis, replacing the most common characters with shorter bit strings than the less used ones. And it can generate the best bit strings to use, too.


And now, an explanation as to why there are no magic compressors.

Let''s say a compresser could compress every file of x bits in length. There are 2^x possible files of x bits in length. Each one of these has to compress to a file smaller than x bits. Since there are only 2^x - 1 possible files of less than x bits, at least two files of x bits in length must compress to the same output file. But these two identical files cannot decompress to two different files, and this is a contradiction.

Therefore, you cannot compress all files of x bits in length, where x = anything.

This topic is closed to new replies.

Advertisement