caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Matt Gushee <matt@gushee.net>
To: caml-list@pauillac.inria.fr
Subject: Re: [Caml-list] Multi-keyed lookup table?
Date: Fri, 8 Aug 2003 15:30:37 -0600	[thread overview]
Message-ID: <20030808213037.GA21525@swordfish> (raw)
In-Reply-To: <D4DBD8568F05D511A1C20002A55C008C11AC05E6@uswaumsx03medge.med.ge.com> <3F32D078.7060705@ozemail.com.au> <3F32D210.6060302@ozemail.com.au> <38641.141.155.88.179.1060292970.squirrel@minsky-primus.homeip.net> <Pine.LNX.4.33.0308071457590.2616-100000@eagle.ancor.com>

Thanks for the very informative answers. Even if I end up not exactly
following any of your suggestions, this thread has given me some very
good information about data structures in general.

On Thu, Aug 07, 2003 at 03:16:49PM -0500, Brian Hurt wrote:
> 
> In the general case, this is hard.  In this specific case, you might 
> consider just hard coding your levels.  So you'd end up with a data 
> structure like:
> 
>              All font
>              /   |   \
>             /    |    \
>          medium bold light   <-- pick the weight
>                 / | \
>               [ ..... ]

Interesting idea, and not one that I had considered at all. It seems
quite efficient, too. On the other hand, it looks like the fixed search
path would make it rather hard to implement fallback rules in case an
exact match isn't found. It seems to me that that's fairly important for
fonts: there are many situations where it is preferable to produce some
output with some fonts not quite right rather than producing nothing.

Maybe it should be up to the application to handle that. But then if my
library only implements an exact-match-or-nothing approach, you could
easily end up an application that has to handle a whole lot of Not_found
exceptions. I'd rather create a library that can do a closest-match kind
of thing.


On Thu, Aug 07, 2003 at 05:49:30PM -0400, Yaron Minsky wrote:
> This might be too simplistic, but how about creating a union type the
> includes all of the different things you might want to index on, and then
> use that as the key to a hashtable.  The efficiency of that would hinge on
> the efficiency of the hash function, I would think.   I would expect it to
> be simple to implement and pretty quick.

You mean something like:

  type font_spec = (font_family * font_weight * font_style * font_width
                    * encoding)

?

I thought of doing something like that, but then how would you handle
something like:

  (_, Bold, Italic, _, _)  (* Not intended to represent real code, 
                              just illustrating the concept *)

?

I was actually thinking of doing a little bitmask voodoo, e.g.

  let candidates =
    List.filter (fun key font -> (key land pattern) == pattern) all_fonts

  (BTW, why isn't there an Array.filter function?)


On Fri, Aug 08, 2003 at 08:19:36AM +1000, John Max Skaller wrote:
> 
> Since you have 'arbitrary' keying, the ideal data structure
> is clearly a relational database :-)

Now why didn't I think of that? I may actually follow that
semi-suggestion. Or rather, having thought through my idea a little
more, it becomes clear that having a good runtime data structure is
only part of the problem. A persistence mechanism is also important,
and if we use, say, an RDBMS or DBM, it probably doesn't make much sense
to layer an OCaml data structure on top of that. Or does it? Does
caching have much value when the data being cached is a bunch of short
strings?

Anyway, I think what I'm going to do is--since what I have in mind is a
pretty simple utility that does one thing--to whip together a library
with several backends--Dbm, Postgres, etc.--and see how they work out.

Again, thanks for the ideas.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2003-08-08 21:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-07 19:41 Matt Gushee
2003-08-07 20:16 ` Brian Hurt
2003-08-07 21:49   ` Yaron Minsky
2003-08-07 22:26     ` John Max Skaller
     [not found]       ` <D4DBD8568F05D511A1C20002A55C008C11AC05E6@uswaumsx03medge.med.ge.com>
2003-08-08 21:30         ` Matt Gushee [this message]
2003-08-08 22:13           ` Brian Hurt
     [not found]           ` <005d01c35e51$7c927200$6628f9c1@zofo>
2003-08-09 16:57             ` [Caml-list] Array.filter (was Multi-keyed lookup table?) Matt Gushee
2003-08-09 18:48               ` ijtrotts
2003-08-10 19:53                 ` Michal Moskal
2003-08-10  2:34                   ` ijtrotts
2003-08-11  5:48                     ` David Brown
2003-08-10 18:53                       ` ijtrotts
2003-08-10 20:23                   ` Marcin 'Qrczak' Kowalczyk
2003-08-10  2:37                     ` ijtrotts
     [not found]                   ` <200308102222.16369.qrczak@knm.org.pl>
2003-08-10 20:43                     ` Michal Moskal
2003-08-10 21:59                       ` Ville-Pertti Keinonen
2003-08-10 20:55                 ` [Caml-list] Array.filter Jean-Baptiste Rouquier
2003-08-11  9:46                   ` Michal Moskal
2003-08-10 22:29                 ` [Caml-list] Array.filter (was Multi-keyed lookup table?) Shawn Wagner
2003-08-11 11:51           ` [Caml-list] Multi-keyed lookup table? Remi Vanicat
2003-08-07 22:19 ` John Max Skaller
2003-08-12  6:34   ` Florian Hars
2003-08-12  9:58     ` Michael Wohlwend

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=20030808213037.GA21525@swordfish \
    --to=matt@gushee.net \
    --cc=caml-list@pauillac.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;
as well as URLs for NNTP newsgroup(s).