From: Jocelyn Serot <Jocelyn.Serot@lasmea.univ-bpclermont.fr>
To: Pierre.Weis@inria.fr (Pierre Weis)
Cc: caml-list@margaux.inria.fr
Subject: Re: native code compiler and exceptions
Date: Fri, 27 Sep 1996 18:01:33 METDST [thread overview]
Message-ID: <199609271559.RAA18699@nez-perce.inria.fr> (raw)
In-Reply-To: <199609271524.RAA27638@pauillac.inria.fr>; from "Pierre Weis" at Sep 27, 96 5:24 pm
Thanks for your enlightments about efficiency concerns in Caml.
Seems like i have re-discovered an evidence: efficiency AND abstraction
do not live well together in the world of programs :-)
For example, i do agree with your optimisation of the conv fn:
> let conv im =
> let nr = nb_rows im and nc = nb_cols im in
> let im' = create nr nc in
> for y = 0 to pred nr do for x = 0 to pred nc do
> let p1 = if x = 0 then 0 else im.(x - 1).(y) in
> let p2 = if y = 0 then 0 else im.(x).(y - 1) in
> let p3 = if x = nc - 1 then 0 else im.(x + 1).(y) in
> let p4 = if y = nr - 1 then 0 else im.(x).(y + 1) in
> im'.(y).(x) <- ((p1 + p2 + p3 + p4) / 4) done done;
> m'
>
But in my code, conv is in fact a generalized "map" fn implemented as a higher
order fn, sth with a signature like:
# val conv : (coord -> coord array) ->
# (pixel array -> pixel) -> (coord -> pixel) -> t -> t
# (* [conv g f clp im] is [im']
# where im'@@(y,x) = f [|p1;..;pk|]
# where pi = im@@(yi,xi) ,if in_bounds m (yi,xi),
# clp (yi,xi) ,otherwise
# where [|(y1,x1);...;(yk,xk)|] = g (y,x) *)
# (*
# * [g] is the "neighboorhing fn"
# * [f] is the "combining fn"
# * [clp] is the "clipping fn" *)
This level of abstraction - that may be useful if you dont want to spend to
time writing "for" loops on image representations - clearly precludes the sort
of optimisation you suggest ...
So i am on my own now, speed or abstraction: this is the question ;-)
Thanks for your help,
Jocelyn
--
E-mail: Jocelyn.Serot@lasmea.univ-bpclermont.fr .............................
S-mail: LASMEA - URA 1793 CNRS, Universite Blaise Pascal, 63177 Aubiere cedex
Tel: (33) 73.40.73.30 - Fax: (33) 73.40.72.62 ...............................
.... http://wwwlasmea.univ-bpclermont.fr/Personnel/Jocelyn.Serot/Welcome.html
next parent reply other threads:[~1996-09-27 16:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199609271524.RAA27638@pauillac.inria.fr>
1996-09-27 16:01 ` Jocelyn Serot [this message]
1996-09-27 13:04 Harrison R. Ulrich (contractor)
1996-09-27 16:03 ` Christophe Raffalli
-- strict thread matches above, loose matches on Subject: below --
1996-09-27 12:46 Jocelyn Serot
1996-09-27 15:58 ` Pierre Weis
1996-09-27 11:21 Jocelyn Serot
1996-09-27 11:41 ` 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=199609271559.RAA18699@nez-perce.inria.fr \
--to=jocelyn.serot@lasmea.univ-bpclermont.fr \
--cc=Pierre.Weis@inria.fr \
--cc=caml-list@margaux.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