Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of
 SRS0=jvx4=K2=m4x.org=sebastien.brisard@bounces.m4x.org designates
 129.104.30.34 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20130101010754.GH20126@dusk.harfang.homelinux.org>
References: <50E1CB9D.4090001@gmail.com>
	<CAJwFCa1Gm4te_z--NYJHeQ1ojhF+6NohmCmrgoE=69saeYH9dw@mail.gmail.com>
	<20130101010754.GH20126@dusk.harfang.homelinux.org>
Date: Tue, 1 Jan 2013 20:17:30 +0100
Message-ID: 
 <CAGRH7Hpm3+p80qsoRY6p_rgeA7UTUnzqiOdvaw_qtURku_6JqQ@mail.gmail.com>
Subject: Re: [math] [linear] immutability
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=047d7b6dcbd62666b304d23efbef

--047d7b6dcbd62666b304d23efbef
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Gilles,


2013/1/1 Gilles Sadowski <gilles@harfang.homelinux.org>

> Hi.
>
> > > If we stick to
> > >
> > > 0) algebraic objects are immutable
> > > 1) algorithms defined using algebraic concepts should be implemented
> > > using algebraic objects
> > >
> > > ...
> > > 0)  Start, with Konstantin's help, by fleshing out the InPlace
> > > matrix / vector interface
> > > 1)  Integrate Mahout code as part of a wholesale refactoring of the
> > > linear package
>
> What do you mean by this?
> Copy/paste or create a dependency? Something else?
>
> > > 2)  Extend use of the visitor pattern to perform mutations
> > > "in-place" (similar to 0) in effect)
> > >
>
> As suggested in a previous post:
>
> 3) a) Define a new "minimal matrix" interface, and create immutable
>       implementations.
>    b) Benchmark critical methods (entry access, iteration, add, multiply,
>       etc.)
>    c) Quantify the efficiency gain of in-place operations and only when
> this
>       information is available decide whether the gain is worth the price=
.
>       [Even if in-place operations are faster in a single thread context,
> it
>       is not sure that immutability would not change that in a multi-thre=
ad
>       implementation. Trying to outperform multi-threaded code with
> in-place
>       operations is a dead end.]
>
> Please mention that when I first mentioned in-place operations, I didn't
have speed in mind, but really memory.
I think we would not gain much speedwise, as Java has become very good at
allocating objects (this would be true of large problems, where typically a
few big objects would be allocated at each iteration. The conclusion would
probably be different with many small objects to be allocated at each
iteration).


> Before embarking on any of this, please identify the rationale: Is there
> _one_ identified problem that would require urgent action? This discussio=
n
> about clean-up/improvement/simplification of the CM matrix implementation=
s
> has been going on for months, and we should not start a "new" discussion
> without referring to what has been recorded by S=E9bastien on JIRA.
>
> I agree with you, of course ;-)
As for use cases: I'm simulating mechanical experiments on microstructures
which are represented as 3D images. The images I'm dealing with are
typically 128x128x128, with 6 dofs per voxel, but my aim is 1024x1024x1024,
even 2048x2048x2048. For these kind of problems, the main issue is memory
(_followed_ by speed).

>
> Regards,
> Gilles
>
> Best regards,
S=E9bastien


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--047d7b6dcbd62666b304d23efbef--