From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 523FEBC6B for ; Wed, 2 Jan 2008 18:36:30 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEVae0dCm3xrnWdsb2JhbACCOjUpjHkBAQEBmBQ X-IronPort-AV: E=Sophos;i="4.24,235,1196636400"; d="scan'208,217";a="20850173" Received: from www.janestcapital.com (HELO smtp.janestcapital.com) ([66.155.124.107]) by mail4-smtp-sop.national.inria.fr with ESMTP; 02 Jan 2008 18:36:29 +0100 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id AB980180; Wed, 02 Jan 2008 12:36:24 -0500 Message-ID: <477BCB94.8060208@janestcapital.com> Date: Wed, 02 Jan 2008 12:36:20 -0500 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edgar Friendly Cc: Kuba Ober , caml-list@yquem.inria.fr Subject: Re: [Caml-list] [NEWBIE] is there an in-place map? References: <200801021152.30105.ober.14@osu.edu> <477BC929.4030109@gmail.com> In-Reply-To: <477BC929.4030109@gmail.com> Content-Type: multipart/alternative; boundary="------------080103090806000601030404" X-Spam: no; 0.00; blit:01 arrays:01 iteri:01 iteri:01 arrays:01 cheers:01 blit:01 recursion:01 recursive:01 for-loop:01 recursion:01 recursive:01 cheers:01 for-loop:01 edgar:98 This is a multi-part message in MIME format. --------------080103090806000601030404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Edgar Friendly wrote: >Kuba Ober wrote: > > >>I need functionality of map, but done in such a way that the output array >>is given as the argument, not as a return value. The closest I could get was >> >>let inplace_map f a b = Array.blit (map f a) 0 b 0 (Array.length a) >> >>Arrays a and b are of the same size. >>This seems very inelegant. >> >>One could use an adapter function and iteri, but that adds very noticeable >>overhead, and doesn't seem too elegant either. >> >>let inplace_map f a b = Array.iteri (fun i src -> b.(i) <- f src; ()) a >> >>There must be a better way of doing it, right? The given here is that the >>arrays a and b are there to stay, so we have to use them in-place. >> >>Cheers, Kuba >> >> >> > >let blit_map f a b = > for i = 0 to (min (Array.length b) (Array.length a)) - 1 do > b.(i) <- f a.(i); > done > > I was thinking more like: let modify f a = for i = 0 to (Array.length a) - 1 do a.(i) <- f a.(i) done; a ;; The OP did say "in place modification. >But as I've been finding out in trying to performance tune for the >Shootout, 'for' loops seem faster than even tail-recursion. I'd say >something about function call overhead, but tail recursion shouldn't >have such. Maybe the work of updating the loop counter in the recursive >case makes the difference... > > > It depends. If you have to use multiple references to make the for-loop work, then I've seen tail recursion be faster (and clearer). Also, if you recalculate the ending requirement every recursive call, recursion can be slower (in the above for loop above, for example, Array.length is gaurenteed to be called only once). Brian --------------080103090806000601030404 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Edgar Friendly wrote:

Kuba Ober wrote:

I need functionality of map, but done in such a way that the output array
is given as the argument, not as a return value. The closest I could get was

let inplace_map f a b = Array.blit (map f a) 0 b 0 (Array.length a)

Arrays a and b are of the same size.
This seems very inelegant.

One could use an adapter function and iteri, but that adds very noticeable 
overhead, and doesn't seem too elegant either.

let inplace_map f a b = Array.iteri (fun i src -> b.(i) <- f src; ()) a

There must be a better way of doing it, right? The given here is that the 
arrays a and b are there to stay, so we have to use them in-place.

Cheers, Kuba


let blit_map f a b =
	for i = 0 to (min (Array.length b) (Array.length a)) - 1 do
		b.(i) <- f a.(i);
	done

I was thinking more like:

let modify f a =
    for i = 0 to (Array.length a) - 1 do
       a.(i) <- f a.(i)
    done;
    a
;;

The OP did say "in place modification.

But as I've been finding out in trying to performance tune for the
Shootout, 'for' loops seem faster than even tail-recursion.  I'd say
something about function call overhead, but tail recursion shouldn't
have such.  Maybe the work of updating the loop counter in the recursive
case makes the difference...

It depends. If you have to use multiple references to make the for-loop work, then I've seen tail recursion be faster (and clearer). Also, if you recalculate the ending requirement every recursive call, recursion can be slower (in the above for loop above, for example, Array.length is gaurenteed to be called only once).

Brian

--------------080103090806000601030404--