X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id 19AC49FA2DB
	for <pgsql-general-postgresql.org@localhost.postgresql.org>;
	Sat,  6 May 2006 17:46:30 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 93849-02
	for <pgsql-general-postgresql.org@localhost.postgresql.org>;
	Sat,  6 May 2006 17:46:20 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from svana.org (svana.org [125.62.94.225])
	by postgresql.org (Postfix) with ESMTP id 991BF9F9C9E
	for <pgsql-general@postgresql.org>;
	Sat,  6 May 2006 17:46:20 -0300 (ADT)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1FcTfL-00036W-JW; Sun, 07 May 2006 06:46:15 +1000
Date: Sat, 6 May 2006 22:46:15 +0200
From: Martijn van Oosterhout <kleptog@svana.org>
To: Volkan YAZICI <yazicivo@ttnet.net.tr>
Cc: pgsql-general@postgresql.org
Subject: Re: intarray internals
Message-ID: <20060506204615.GF4413@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
Mail-Followup-To: Volkan YAZICI <yazicivo@ttnet.net.tr>,
	pgsql-general@postgresql.org
References: <20060505214601.GA208@alamut> <20060506101303.GB4413@svana.org>
	<20060506143824.GB202@alamut>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="SxgehGEc6vB0cZwN"
Content-Disposition: inline
In-Reply-To: <20060506143824.GB202@alamut>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200605/259
X-Sequence-Number: 95051


--SxgehGEc6vB0cZwN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 06, 2006 at 05:38:24PM +0300, Volkan YAZICI wrote:
> > Well, it's probably trying to undo whatever g_int_compress. If you can
> > explain the algorithm used it will probably be clearer.
>=20
> Actually, algorithms used in the g_int_compress() and g_int_decompress()
> methods are quite awesome. (I don't know if this is the authors'
> creation, but if so, kudos.) But the problem I think is they're quite
> lossy compression methods. To clarify, here's a small explanation of
> algorithm used (if I understood right):

Well, you're right, the algorithm is quite neat. Note however that it's
only applied for integer sets with more than 100 values. I don't know
much about the intarray code, but this is a compression algorithm that
probably maps well to the domain. If you can find a lossless one that
will take 1,000 elements and can cram them into the space of 100
losslessly, we'd be glad to hear it.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to l=
itigate.

--SxgehGEc6vB0cZwN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEXQsXIB7bNG8LQkwRAjepAJ94a1Tp9hFgjs6V/uGD92FxXypdrwCfan+i
pYd6y33YaLV2r+Y+DPoPsbo=
=w343
-----END PGP SIGNATURE-----

--SxgehGEc6vB0cZwN--