From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id SAA29111 for caml-redistribution; Fri, 27 Sep 1996 18:09:26 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id RAA28669 for ; Fri, 27 Sep 1996 17:59:27 +0200 Received: from lasmea.univ-bpclermont.fr (lasmea.univ-bpclermont.fr [193.54.50.15]) by nez-perce.inria.fr (8.7.6/8.7.1) with ESMTP id RAA18699 for ; Fri, 27 Sep 1996 17:59:24 +0200 (MET DST) Message-Id: <199609271559.RAA18699@nez-perce.inria.fr> Received: by lasmea.univ-bpclermont.fr (1.37.109.16/16.2) id AA243490094; Fri, 27 Sep 1996 18:01:34 +0200 From: Jocelyn Serot Subject: Re: native code compiler and exceptions To: Pierre.Weis@inria.fr (Pierre Weis) Date: Fri, 27 Sep 1996 18:01:33 METDST Cc: caml-list@margaux.inria.fr In-Reply-To: <199609271524.RAA27638@pauillac.inria.fr>; from "Pierre Weis" at Sep 27, 96 5:24 pm X-Mailer: Elm [revision: 109.17] Sender: weis 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