commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <>
Subject Re: [math] [linear] immutability
Date Tue, 01 Jan 2013 19:11:08 GMT

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 performance problems.  Adding
> support for sparse objects helps here; but the problem does not go
> away.  To get high performance and efficient memory utilization, you
> need to relax one or both of these constraints.  Within the linear
> package itself, some of our implementations basically throw out 1),
> grabbing data and operating on double arrays rather than using
> algebraic operations.  I think we need to seriously consider ways to
> relax 0) such as Konstantin's idea of the InPlace interface,
> Sebastien's suggestion to use visitors or Mahout's visitors / view
> approaches.  Do others agree?  Please weigh in on the options below:
> 0)  Start, with Konstantin's help, by fleshing out the InPlace
> matrix / vector interface

I have already said that I totally disagree with this solution. This would
indeed be very unsafe. We would even run the risk to faslify our own
algorithms. Indeed, such simple statements as x.add(y) would no longer
garantee that x is unchanged (depending on which implementation of
RealVector --InPlace or not-- would be passed to the algorithm.

1)  Integrate Mahout code as part of a wholesale refactoring of the
> linear package
> 2)  Extend use of the visitor pattern to perform mutations
> "in-place" (similar to 0) in effect)
> Or provide other / better options.

I don't like the mess it would generate in the matrix/vector interfaces,
but I'd much (much, much) rather we implement separate in-place operation,
such as addToSelf and the likes.

Best regards,


> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message