> [...]
>
> > P.S. I would also be interested if people think Vector should be made into
> > a special case of a Matrix.
>
>
> That's an interesting idea.
It's something I've been wondering about for a long time too.
CM's "RealVector" is a mix of
* list of "double"s
* Cartesian vector
* sing
Hi.
> [...]
> The virtue here is that we didn't have to discuss these matters much. We
> could just say "Sounds like a great idea, can you build a prototype to
> demonstrate your point?" to any bright spark who came along.
Special thanks for also mentioning this point.
People who think that they
My apologies, but I have totally lost track of who said what because too
many comments have enormous lines immediately adjacent to responses.
On Tue, Jan 1, 2013 at 11:39 AM, Somebody wrote:
> I thought that maybe it was due to the underlying
> (dynamic) data structure for sparse vectors/matrice
On Tue, Jan 1, 2013 at 11:17 AM, Sébastien Brisard <
sebastien.bris...@m4x.org> wrote:
> > 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
Hi Konstantin,
2013/1/1 Konstantin Berlin
> Here are my 2 cents:
>
> The rationale for redesign of the RealMatrix hierarchy is because a large
> amount of numerical packages depend (or should depend) on a linear algebra
> package for efficient implementation. However, as it currently stands, it
Hi Gilles,
2013/1/1 Gilles Sadowski
> 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 I
Hello,
2012/12/31 Phil Steitz
> If we stick to
>
> 0) algebraic objects are immutable
> 1) algorithms defined using algebraic concepts should be implemented
> using algebraic objects
>
> we end up having to create lots of algebraic objects and copy lots
> of data, which creates memory and perfor
On Tue, Jan 1, 2013 at 10:25 AM, Phil Steitz wrote:
> Agreed we should keep the discussion concrete. Sebastien and Luc
> have both mentioned specific examples where the overhead of matrix
> data copy and storage creates practical problems. Konstantin
> mentioned another (Gaussian elimination) w
On 12/31/12 5:07 PM, Gilles Sadowski wrote:
> 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
>>> m
Here are my 2 cents:
The rationale for redesign of the RealMatrix hierarchy is because a large
amount of numerical packages depend (or should depend) on a linear algebra
package for efficient implementation. However, as it currently stands, it is
not possible (or unnecessarily burdensome) to cr
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 Maho
On Mon, Dec 31, 2012 at 9:30 AM, Phil Steitz wrote:
> 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 i
If we stick to
0) algebraic objects are immutable
1) algorithms defined using algebraic concepts should be implemented
using algebraic objects
we end up having to create lots of algebraic objects and copy lots
of data, which creates memory and performance problems. Adding
support for sparse obje
13 matches
Mail list logo
