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 autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id CEFC8BC6C; Mon, 28 Jan 2008 13:48:39 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABtenUfAXQImh2dsb2JhbACQKAEBAQgKKZoI X-IronPort-AV: E=Sophos;i="4.25,259,1199660400"; d="scan'208";a="8446427" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Jan 2008 13:48:39 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0SCmYnQ020703 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK); Mon, 28 Jan 2008 13:48:39 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIJenUfU436zh2dsb2JhbACQKAEBAQgKKZoI X-IronPort-AV: E=Sophos;i="4.25,259,1199660400"; d="scan'208";a="7325640" Received: from moutng.kundenserver.de ([212.227.126.179]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Jan 2008 13:48:34 +0100 Received: from [152.78.96.56] (babylon.cip.physik.uni-muenchen.de [141.84.136.30]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1JJTPd3Lv9-0006JX; Mon, 28 Jan 2008 13:48:34 +0100 Message-ID: <479DD14B.2030209@functionality.de> Date: Mon, 28 Jan 2008 12:57:47 +0000 From: Thomas Fischbacher User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060607 Debian/1.7.12-1.2 X-Accept-Language: en MIME-Version: 1.0 To: Xavier Leroy Cc: Caml-list List Subject: Re: [Caml-list] Bigarray question References: <476806F9.4030100@functionality.de> <47695924.8090202@inria.fr> In-Reply-To: <47695924.8090202@inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX180u+Lhj9Tu+0eLnVFpPXyZpjGBB65sPQLTDw3 OaLd8Go20hCxsR4Mys0YyRxkPAZd04MTak7yvg5U2wEg+PSxkS W2bh0hrkAKAUWAj90FKfQ== X-Miltered: at discorde with ID 479DCF23.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bigarray:01 pointers:01 bigarray:01 pointer:01 pointer:01 hash:01 camlprim:01 camlparam:01 const:01 const:01 vals:01 vals:01 val:01 val:01 ocaml:01 Xavier Leroy wrote: (on whether it is permissible to dynamically change the dim and data pointers in a ML bigarray): >>as far as I can tell, it is easy (but not explicitly allowed in the >>documentation) to allocate a Caml bigarray and change the data >>pointer inside that bigarray afterwards. >>There is no problem in implementing this, technically speaking. >>But this would require a change to the ML documentation stating >>that it is explicitly considered as permissible to change the >>data pointer in a bigarray. Can I get that, please? > > > I see no reason why this would cause problems, as long as the data > pointer points to C data of the right shape and dimensions. (Of > course, you could update the dimensions of the bigarray as > appropriate, if needed.) I don't think I would document this, as I > wouldn't quite know how to word it in the docs, but you have my > encouragements to try and report problems if any. As a matter of fact, considering the two C functions below which I use in our "nsim" abstract field theory/multiphysics simulation engine to speed up some internal computation, the first variant would be desirable but crashes. The second works. What this actually is about is to systematically go through the rows of a sparse matrix, handled by the PETSc library. (So, basically, I am using a sparse matrix as sort-of a hash of row index to entries here.) CAMLprim value caml_petsc_matrix_call_on_rows_raw(value ml_mx, value ml_fun, value ml_start_row, value ml_end_row ) { CAMLparam4(ml_mx,ml_fun,ml_start_row,ml_end_row); Mat mx; int start_row,end_row,start_own,end_own; int i,ncols=0; const int *cols=0; const PetscScalar *vals=0; CAMLlocal2(ba_indices,ba_vals); petsc_checkinit(); petsc_check_mat(ml_mx); mx=(Mat)Field(ml_mx,1); MatGetOwnershipRange(mx,&start_own,&end_own); start_row=Int_val(ml_start_row); end_row=Int_val(ml_end_row); if(start_row == -1)start_row=start_own; if(end_row == -1)end_row=end_own; /* We would like to do things this way, but while one may guess that it should work, this (1) is not covered by what is permitted according to the OCaml documentation, and (2) indeed produces crashes. */ ba_indices=alloc_bigarray_dims(BIGARRAY_NATIVE_INT | BIGARRAY_C_LAYOUT, 1, cols, ncols); ba_vals=alloc_bigarray_dims(BIGARRAY_FLOAT64 | BIGARRAY_C_LAYOUT, 1, vals, ncols); for(i=start_row;idim[0]=ncols; Bigarray_val(ba_vals)->dim[0]=ncols; Bigarray_val(ba_indices)->data=(void*)cols; Bigarray_val(ba_vals)->data=(void*)vals; callback3(ml_fun,Val_int(i),ba_indices,ba_vals); MatRestoreRow(mx,i,&ncols,&cols,&vals); } CAMLreturn(Val_unit); } CAMLprim value caml_petsc_matrix_call_on_rows_raw_defensive(value ml_mx, value ml_fun, value ml_start_row, value ml_end_row ) { CAMLparam4(ml_mx,ml_fun,ml_start_row,ml_end_row); Mat mx; int start_row,end_row,start_own,end_own; int i,ncols=0; const int *cols=0; const PetscScalar *vals=0; CAMLlocal2(ba_indices,ba_vals); petsc_checkinit(); petsc_check_mat(ml_mx); mx=(Mat)Field(ml_mx,1); MatGetOwnershipRange(mx,&start_own,&end_own); start_row=Int_val(ml_start_row); end_row=Int_val(ml_end_row); if(start_row == -1)start_row=start_own; if(end_row == -1)end_row=end_own; for(i=start_row;i