Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: "Frédéric Gava" <frederic.gava@wanadoo.fr>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Objective Caml release 3.08.2
Date: 26 Nov 2004 10:34:52 +1100	[thread overview]
Message-ID: <1101425691.9291.69.camel@pelican.wigram> (raw)
In-Reply-To: <008001c4d319$693f0f40$b18780d9@mshome.net>

On Fri, 2004-11-26 at 05:05, Frédéric Gava wrote:

> > and order matters for folds if the operator being folded
> > isn't associative.
> Ok. That's right. This is why I thinks, another fold is necessary for
> associative operators (and thus for possible optimizations of this fold) and
> thus wihtout side-effects.

Perhaps that should be a question: are there optimisations
which can be performed if the ordering constraint is dropped?

This probably has two parts:

(a) Is Set.min_elt as fast as Set.choose?
(b) Are there any other optimisations (eg deforestation) 
which would benefit?

I don't know the answer to either question in the particular
case of Set.

Perhaps there would be some benefit for a Set' data type,
which was unordered.

ISO C++ STL has an ordered Set type (which typically does use
a red black tree), and in Technical Report 1 (TR1), there
is an unordered set type, intended to be implemented with
a hash table.

So I would tend to think it may well be worthwhile adding
an unordered set to Ocaml. I guess some operations may
change from O(log N) to O(1), or from O(N log N) to just O(N),
eg fold.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net




  parent reply	other threads:[~2004-11-25 23:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-24 13:06 Damien Doligez
2004-11-25 14:47 ` [Caml-list] " Frédéric Gava
2004-11-25 15:53   ` skaller
2004-11-25 18:05     ` Frédéric Gava
2004-11-25 18:32       ` Christophe TROESTLER
2004-11-26 23:10         ` Frédéric Gava
2004-11-25 21:47       ` Jon Harrop
2004-11-25 23:34       ` skaller [this message]
2004-11-26  8:45         ` Frédéric Gava
2004-11-26  1:20 ` Aleksey Nogin

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=1101425691.9291.69.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=frederic.gava@wanadoo.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