caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Jon Harrop" <jon@ffconsultancy.com>
To: <fa.caml@googlegroups.com>
Cc: <caml-list@inria.fr>
Subject: RE: RE: [Caml-list] Priority queues, reloaded
Date: Wed, 13 Jul 2011 19:58:33 +0100	[thread overview]
Message-ID: <005301cc418e$dde4c2a0$99ae47e0$@ffconsultancy.com> (raw)
In-Reply-To: <c169b0d8-b925-40df-8756-6283ea9362f9@glegroupsg2000goo.googlegroups.com>

Radu Grigore wrote:
> Another comparison appears in SGB, file miles_span.w, in the context of
> computing minimum spanning trees. It turns out that Fibonacci heaps are
not
> only a theoretical curiosity!

That's interesting. I was under the impression Fibonacci heaps had a really
bad constant prefactor.

If this is the right file:

  http://ftp.sunet.se/pub/text-processing/TeX/support/graphbase/miles_span.w

Then they say:

  "We will try out four basic algorithms that have received prominent
attention in the literature. Graham and Hell's Algorithm~1 is represented
by the |krusk| procedure, which uses Kruskal's algorithm after the
edges have been sorted by length with a radix sort. Their Algorithm~2
is represented by the |jar_pr| procedure, which incorporates a 
priority queue structure that we implement in two ways, either as
a simple binary heap or as a Fibonacci heap. And their Algorithm~3
is represented by the |cher_tar_kar| procedure, which implements a
method similar to Bor{\accent23u}vka's that was independently
discovered by Cheriton and Tarjan and later simplified by Karp and Tarjan. "

So they're only comparing binary and Fibonacci heaps (not skew, leftist,
pairing, binomial etc). Moreover, do you actually need a heap in the MST
algorithm? You cannot add the shortest edge first without traversing all
edges so you must consider all edges. I suppose a heap could win out over a
sort if the MST only requires a small proportion of all the edges, i.e.
finding the 1..k shortest edges, but I'm not sure how valuable that is in
practice.

Regardless, I'm sure the first step in optimizing such algorithms is to
sacrifice purity. :-)

Cheers,
Jon.



      reply	other threads:[~2011-07-13 18:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.jLuU8MHj1XgV3rmt34EbGLgv1ps@ifi.uio.no>
2011-07-11 12:55 ` Radu Grigore
2011-07-13 18:58   ` Jon Harrop [this message]

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='005301cc418e$dde4c2a0$99ae47e0$@ffconsultancy.com' \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@inria.fr \
    --cc=fa.caml@googlegroups.com \
    /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).