Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
References: <205bfa4f-29de-43de-be5a-72a12d77d0c9@googlegroups.com> <mailman.1835.1383162420.18130.python-list@python.org> <c73c8aa6-cac4-4f02-ae83-31cea167c172@googlegroups.com> <s9ra79dvvnd01rpuqg9hfh6bija8u2q49h@4ax.com> <9d998707-a6e9-4911-a585-c2310e4a2b31@googlegroups.com> <q7im799jqj9ap3jb94lnqka1m0hnn9bnpv@4ax.com> <CAMjeLr8jao50FSqM9pT=77in0nPNCOA8SQwHC_Jm50eiQYTs+g@mail.gmail.com> <mailman.2161.1383863216.18130.python-list@python.org> <9b62770c-7ca1-4a4d-81a5-bf7251bac957@googlegroups.com> <mailman.2171.1383877064.18130.python-list@python.org> <13c04f06-f1f2-4f67-b975-3cff28714641@googlegroups.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <13c04f06-f1f2-4f67-b975-3cff28714641@googlegroups.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: "R. Michael Weylandt <michael.weylandt@gmail.com>" <michael.weylandt@gmail.com>
Subject: Re: Algorithm that makes maximum compression of completly diffused data.
Date: Thu, 7 Nov 2013 21:43:10 -0500
To: "jonas.thornvall@gmail.com" <jonas.thornvall@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2177.1383878602.18130.python-list@python.org>
Lines: 55
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:58740



On Nov 7, 2013, at 21:25, jonas.thornvall@gmail.com wrote:

> Den fredagen den 8:e november 2013 kl. 03:17:36 UTC+1 skrev Chris Angelico=
:
>> On Fri, Nov 8, 2013 at 1:05 PM,  <jonas.thornvall@gmail.com> wrote:
>>=20
>>> I guess what matter is how fast an algorithm can encode and decode a big=
 number, at least if you want to use it for very big sets of random data, or=
 losless video compression?
>>=20
>>=20
>>=20
>> I don't care how fast. I care about the laws of physics :) You can't
>>=20
>> stuff more data into less space without losing some of it.
>>=20
>>=20
>>=20
>> Also, please lose Google Groups, or check out what other people have
>>=20
>> said about making it less obnoxious.
>>=20
>>=20
>>=20
>> ChrisA
>=20
> Please, you are he obnoxious, so fuck off or go learn about reformulation o=
f problems. Every number has an infinite number of arithmetical solutions. S=
o every number do has a shortest arithmetical encoding. And that is not the h=
ard part to figure out, the hard part is to find a generic arithmetic encodi=
ng.
>=20
> I am not sure if it is just stupidness or laziness that prevent you from s=
eeing that 4^8=3D65536.

Chris's point is more subtle: the typical computer will store the number 655=
36 in a single byte, but it will also store 4 and 8 in one byte. So if your c=
hoice is between sending "65536" and "(4,8)", you actually loose efficiency i=
n your scheme. Don't think in decimal, but in terms of information needing t=
ransfer.=20

You might reply that you don't need a whole byte for 4 or 8 -- that's true. Y=
ou could, e.g., just encode the fourth and eight bits of a single byte and s=
end that: certainly gives some compression but at the cost of generality-- w=
hat would you do with 65^65? It's sort of like the mean-variance tradeoff in=
 statistics; it's much easier to encode certain data sets (e.g. powers of tw=
o as you noted) but only if you concede your algorithm will only work for th=
ose values.=20

More generally, check out the work of Claud Shannon; a very accessible and w=
orthwhile author.=20
> --=20
> https://mail.python.org/mailman/listinfo/python-list