From: Pierre Weis <Pierre.Weis@inria.fr>
To: Jocelyn.Serot@lasmea.univ-bpclermont.fr (Jocelyn Serot)
Cc: caml-list@margaux.inria.fr
Subject: Re: native code compiler and exceptions
Date: Fri, 27 Sep 1996 17:58:17 +0200 (MET DST) [thread overview]
Message-ID: <199609271558.RAA28565@pauillac.inria.fr> (raw)
In-Reply-To: <199609271244.OAA07980@concorde.inria.fr> from "Jocelyn Serot" at Sep 27, 96 02:46:35 pm
Hi,
> I will try yo explain my pb on a small example.
> Suppose that images are represented as pixel 2d-arrays (in fact, images
> are implemented as ADTs, with their internal representation hidden).
>
> # type image = int array array
> # let get_pixel i y x = i.(y).(x)
> # let set_pixel i y x p = i.(y).(x) <- p
> # let create nr nc = Array.new_matrix nr nc 0
>
> What i want to do is to compute, for example is a simple 2d-convolution,
> turning pixel(x,y) into (p(x-1,y)+p(x,y-1)+p(x+1,y)+p(x,y+1))/4.
Well, the set and get functions are well suited for the image
abstraction, but if efficiency is a problem, you should not use these
functions to implement low level functions on images:
get_pixel i y x is much more time consuming than its inlined counterpart
i.(y).(x). For efficiency reasons, the last version should be prefered
when available, for instance from within the abstraction...
> A possible manner to handle the clipping effect at image boundaries is to
> set that p(x,y) = 0 whenever x<0 ot y<0.
> So it does not seem to me so "ugly" to write my convolution fn like that:
>
> # 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 = try_get_pixel im (x-1) y 0 in
> # let p2 = try_get_pixel im x (y-1) 0 in
> # let p3 = try_get_pixel im (x+1) y 0 in
> # let p4 = try_get_pixel im x (y+1) 0 in
> # set_pixel im' (y,x) ((p1+p2+p3+p4)/4) done done;
> # m'
>
> making use of the given access fn:
>
> # let try_get_pixel im y x clip =
> # try get_pixel im y x with Invalid_argument _ -> clip
The introduction of try_get_pixel adds another indirection level: 2
function calls and an exception handler to access one pixel! That may
10 or 100 times slowlier than the direct access.
> (btw, note that is this case clip might be a _fn_ of the "faulty" coordinates,
> like:
>
> # let try_get_pixel im y x clip =
> # try get_pixel im y x with Invalid_argument _ -> clip y x
> )
>
> Is this not "good" fnal programming style ?..
Well this is functional, since you call functions, but once more there is no
need to call a function with 2 arguments to return a constant (0 in
your case).
> Or does the "ugliness" lies only in the [... with Invalid_argument _ ->...]
> construct ? In this case, i guess i should test _explicitely_ whether (y,x) are
> in bounds instead of relying of the exception [Invalid_argument "Array.get"].Ie:
>
> # let try_get_pixel im y x clip =
> # if (y<0 || y>=(nb_rows im) || x<0 || x>=(nb_cols im)) then clip
> # else get_pixel im y x
>
> Is it what you mean ?
Yes, you're right. There is no good reasons for explicitely trapping the
Invalid_argument exception from within regular parts of your programs:
if you know that you may call a primitive with an invalid argument,
you should avoid this call, instead of trapping the error afterwards.
By the way, you may observe that the function try_get_pixel
may be simplified when called from within ``conv'': many of the tests
are statically known and may be discarded. The resulting code exhibits
the remaining tests but is still readable, while much more efficient:
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'
If you need an even more efficient routine, you should consider
removing the tests if x = 0, if y = 0, and so on, from inside the
loop, decomposing the loop into a straightforward loop
for y = 1 to nr - 2 do for x = 1 to nc - 2 do
with no tests at all, and complete im' with the remaining cases
afterwards ...
In any case, when efficiency is concerned, you should avoid calling 2
or 3 functions to perform an atomic task. I should say that, even if
there is no efficiency consideration, calling a function that just
calls a function that calls a function that performs an atomic task,
does not help reading the program ...
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis
next prev parent reply other threads:[~1996-09-27 16:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-09-27 12:46 Jocelyn Serot
1996-09-27 15:58 ` Pierre Weis [this message]
[not found] <199609271524.RAA27638@pauillac.inria.fr>
1996-09-27 16:01 ` Jocelyn Serot
-- strict thread matches above, loose matches on Subject: below --
1996-09-27 13:04 Harrison R. Ulrich (contractor)
1996-09-27 16:03 ` Christophe Raffalli
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=199609271558.RAA28565@pauillac.inria.fr \
--to=pierre.weis@inria.fr \
--cc=Jocelyn.Serot@lasmea.univ-bpclermont.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;
as well as URLs for NNTP newsgroup(s).