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
next prev 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