From: "Harrison, John R" <john.r.harrison@intel.com>
To: Berke Durak <berke.durak@exalead.com>
Cc: Caml-list List <caml-list@inria.fr>
Subject: RE: [Caml-list] Canonical Set/Map datastructure?
Date: Thu, 6 Mar 2008 10:36:43 -0700 [thread overview]
Message-ID: <DCC19446A892D84FBB89AE7C94F0C04E01D98FB2BE@azsmsx501.amr.corp.intel.com> (raw)
In-Reply-To: <47CFBF04.9030703@exalead.com>
Hi Berke,
| However, the idea of combining hash-consing and Patricia trees,
| however elegant, does not suit my problem. Basically, you are
| cheating by using an auxiliary data structure, the hashtable (which is
| also O(n^2) worst-case).
The code I pointed you to uses hashes, but not hash tables. As for the
worst-case efficiency, what you say is true, but it's unlikely to
matter in practice. And I suspect it may be unavoidable in principle,
which is the interesting thing I learned last time this was discussed.
See for example the following paper and its references:
"New Tight Bounds on Uniquely Represented Dictionaries"
Arne Andersson and Thomas Ottmann
SIAM J. vol 24, pp. 1091-1103, 1995.
The paper is available online as
http://user.it.uu.se/~arnea/ps/andetigh.ps
Note in particular the following paragraph:
"Hence we show that there is a huge gap between unique and non-unique
representations of dictionaries. We feel that these findings point
to a fundamental fact in the theory of data structures".
| As I was improving my IO combinator library with sets and maps, the
| structures need to be self-contained, and not need a description as a
| bitstring (which could be done by using Marshal.to_string but I don't
| think the performance would be there). Maybe some wizardry relying on
| the physical representation of objects would permit storage of
| arbitrary values in Patricia trees, but I remain skeptical. --
My code uses OCaml's polymorphic hashes internally, but these do not
appear in the interface and the user doesn't need to supply anything.
Indeed, you may regard OCaml's polymorphic hash as a hack, but it is
available in OCaml for every type just as surely as polymorphic
equality. So I'm not sure I quite understand the nature of your
objection.
John.
next prev parent reply other threads:[~2008-03-06 17:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-05 16:49 Berke Durak
2008-03-05 17:16 ` [Caml-list] " Brian Hurt
2008-03-05 17:27 ` Alain Frisch
2008-03-05 19:53 ` Jean-Christophe Filliâtre
2008-03-05 20:03 ` Jon Harrop
2008-03-05 21:56 ` Alain Frisch
2008-03-06 7:45 ` Jean-Christophe Filliâtre
2008-03-05 17:34 ` Harrison, John R
2008-03-06 9:53 ` Berke Durak
2008-03-06 17:36 ` Harrison, John R [this message]
2008-03-07 10:09 ` Berke Durak
2008-03-07 17:13 ` Harrison, John R
2008-03-07 10:19 ` Alain Frisch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DCC19446A892D84FBB89AE7C94F0C04E01D98FB2BE@azsmsx501.amr.corp.intel.com \
--to=john.r.harrison@intel.com \
--cc=berke.durak@exalead.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox