From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA24151; Thu, 8 Nov 2001 18:56:21 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA24108 for ; Thu, 8 Nov 2001 18:56:20 +0100 (MET) Received: from heplix4.ikp.physik.tu-darmstadt.de (heplix4.ikp.physik.tu-darmstadt.de [130.83.210.158]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA8HuJv18830 for ; Thu, 8 Nov 2001 18:56:19 +0100 (MET) Received: (from ohl@localhost) by heplix4.ikp.physik.tu-darmstadt.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id fA8Hu9d18119; Thu, 8 Nov 2001 18:56:09 +0100 From: Thorsten Ohl MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15338.51001.121416.677202@heplix4.ikp.physik.tu-darmstadt.de> Date: Thu, 8 Nov 2001 18:56:09 +0100 To: caml-list@inria.fr, shiv@mac.com Subject: Re: [Caml-list] Re: complex bigarrays In-Reply-To: <81DA66D2-D46E-11D5-82F9-003065BDAA76@mac.com> References: <15338.42584.498751.200158@heplix4.ikp.physik.tu-darmstadt.de> <81DA66D2-D46E-11D5-82F9-003065BDAA76@mac.com> X-Mailer: VM 6.84 under Emacs 20.7.1 Reply-To: ohl@hep.tu-darmstadt.de Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk shiv@mac.com writes: > But most of the LAPACK complex routines do expect to see regular > FORTRAN COMPLEX arrays You're right. I was incorrectly generalizing from DGEEV etc. that take real arrays as input return (among others) complex vectors. The latter are represented as two real array. Routines that take complex inputs represent them as COMPLEX arrays. > So I would vote to represent complex bigarrays using a single array > with real and imaginary parts of each element adjacent to each other in > that order. I fully agree. Even if my generalization had been correct, I would still have voted for this, because it conforms to the Fortran language definition. > I have read (some where) that this might cause problems with some C > compilers on some machines. That is, if we define struct {float re; > float im} A[10]; Then the entries in A may not be packed together as > we might expect. AFAIK, the C compiler is free to pad structures for better alignment, resulting in better performance. Isn't it even free to reorder elements? -- Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here] ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr