From: Pierre Weis <Pierre.Weis@inria.fr>
To: skaller@ozemail.com.au (John Max Skaller)
Cc: caml-list@inria.fr
Subject: Re: WWW Page of Team PLClub (Re: ICFP programming contest: results)
Date: Tue, 10 Oct 2000 12:23:00 +0200 (MET DST) [thread overview]
Message-ID: <200010101023.MAA04317@pauillac.inria.fr> (raw)
In-Reply-To: <39E0E68F.B2786DE7@ozemail.com.au> from John Max Skaller at "Oct 9, 100 08:26:39 am"
> Pierre Weis wrote:
>
> > the body of f. This operation is trivial if you use a conventional
> > beta reducer, but it is surprisingly difficult if you use De Bruijn
> > indices.
>
> Just out of curiousity, what do you mean
> by a 'difficult' algorithm?
I did not mention the word algorithm. I meant here that implementing
the parallel beta-reduction is not a trivial kind of iteration (map or
fold) on the basic one step beta-reducer (if you do want to obtain a
one pass reduction).
BTW (joking):
Definition: an algorithm is said to be difficult iff it it not
trivial to implement in Caml !
> To explain my question in slightly more depth: given
> some fixed problems with known algorithms, all these algorithms,
> in the first instance, have equal 'difficulty', namely, 'trivial':
> if the algorithm is known, it can be implemented. (In general,
> coding a known algorithm is so easy compared with other programming
> tasks that I would classify coding by how laborious it is: the only
> 'difficulty' involved is staying awake long enough to finish the job :-)
So, let's me tell a story about this ``difficult'' problem: having
problems to implement the parallel beta-reduction using the De Bruijn
indices, I looked in the litterature and found a thesis that claimed
to specify this transformation and used it in the rest of the
thesis. So, I turned the specification into a piece of Caml program;
it gave wrong answers. Fortunately, I had the thesis's author at hand;
hence, we sat together at the terminal and double-checked the
implementation wrt the specification; we were not able to find any
discrepancy in the program; then we changed the specification; then we
changed the program accordingly; it was still giving wrong answers on
some examples!
I gave up, and revert to multiple calls to the beta-reducer (and
accordingly to inefficient multiple rewritings of the function body).
I do not claim this problem is impossible to solve; I just claimed it
is ``surprisingly difficult'' compared to the trivial solution you
give to the same problem when you use a conventional beta-reducer. It
is at least so difficult that a carefully written thesis may give a
wrong specification of the solution, even if it has been reviewed by
experts of the domain.
I think the De Bruijn indices solution to this problem may not be
worth the efforts it needs.
> It is sometimes difficult to _find_ an algorithm for a problem,
> and one may say that some algorithms are 'inflexible' in the sense
> that small variations in the problem make finding a solution
> by considering the 'original' algorithm difficult.
That's exactly what I observed for parallel beta-reduction in one pass.
> It may also be hard to tranform a correct algorithm into
> a more efficient version.
That's exactly the intention in using parallel beta-reduction in one pass.
> Also, it is clear that some algorithms are difficult to
> understand. And, some algorithms, coded incorrectly, may be difficult
> to debug.
Also true with De Bruijn indices transformations.
So, this problem meets all your criteria: that's why I think we can
say ``it is a surprisingly difficult problem''.
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/
next prev parent reply other threads:[~2000-10-10 10:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-05 10:33 David McClain
2000-10-05 20:20 ` Stefan Monnier
2000-10-06 19:26 ` eijiro_sumii
2000-10-07 8:19 ` automatic translation in Team PLClub ICFP'2000 entry Julian Assange
2000-10-07 16:30 ` eijiro_sumii
2000-10-06 8:07 ` WWW Page of Team PLClub (Re: ICFP programming contest: results) Xavier Leroy
2000-10-07 8:35 ` Pierre Weis
2000-10-07 9:55 ` Markus Mottl
2000-10-07 10:24 ` Pierre Weis
2000-10-08 21:26 ` John Max Skaller
2000-10-10 10:23 ` Pierre Weis [this message]
2000-10-09 5:51 ` Benjamin Pierce
2000-10-09 7:19 ` de Bruijn indices (Re: WWW Page of Team PLClub) Eijiro Sumii
2000-10-10 10:36 ` Pierre Weis
2000-10-10 14:04 ` de Bruijn indices Gerard Huet
2000-10-10 17:29 ` Chet Murthy
2000-10-11 22:35 ` John Max Skaller
-- strict thread matches above, loose matches on Subject: below --
2000-10-05 22:46 WWW Page of Team PLClub (Re: ICFP programming contest: results) David McClain
2000-09-21 7:12 ICFP programming contest: results Xavier Leroy
2000-09-24 3:36 ` Eijiro Sumii
2000-10-04 18:40 ` WWW Page of Team PLClub (Re: ICFP programming contest: results) eijiro_sumii
2000-10-05 21:19 ` malc
2000-10-06 9:46 ` Julian Assange
2000-10-06 19:10 ` eijiro_sumii
2000-10-06 20:13 ` eijiro_sumii
2000-10-06 20:05 ` eijiro_sumii
[not found] ` <200010070759.JAA00538@pauillac.inria.fr>
2000-10-07 16:21 ` eijiro_sumii
2000-10-08 21:06 ` Pierre Weis
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=200010101023.MAA04317@pauillac.inria.fr \
--to=pierre.weis@inria.fr \
--cc=caml-list@inria.fr \
--cc=skaller@ozemail.com.au \
/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