I've changed that in the patch (removed the constructor).
Le 15/07/11 00:39, Gilles Sadowski a écrit :
On Thu, Jul 14, 2011 at 11:17:50AM -0700, Ted Dunning wrote:
This sort of need is actually common in my experience.
On Thu, Jul 14, 2011 at 9:37 AM, Phil Steitz wrote:
Currently, none of
On Thu, Jul 14, 2011 at 11:17:50AM -0700, Ted Dunning wrote:
> This sort of need is actually common in my experience.
>
> On Thu, Jul 14, 2011 at 9:37 AM, Phil Steitz wrote:
>
> > Currently, none of the implementations support this,
> > but nothing in the currently defined RealMatrix / Abstract
This sort of need is actually common in my experience.
On Thu, Jul 14, 2011 at 9:37 AM, Phil Steitz wrote:
> Currently, none of the implementations support this,
> but nothing in the currently defined RealMatrix / AbstractRealMatrix
> API prevents subclasses from adding an addRows method, or su
On 7/14/11 8:39 AM, Phil Steitz wrote:
> On 7/14/11 3:49 AM, Gilles Sadowski wrote:
>> On Wed, Jul 13, 2011 at 03:01:09PM -0700, Ted Dunning wrote:
>>> Actually, this is a major issue.
>> Indeed, it is an important design issue.
>>
>>> Take, for instance, the example of considering a Lucene index a
On 7/14/11 3:49 AM, Gilles Sadowski wrote:
> On Wed, Jul 13, 2011 at 03:01:09PM -0700, Ted Dunning wrote:
>> Actually, this is a major issue.
> Indeed, it is an important design issue.
>
>> Take, for instance, the example of considering a Lucene index as a linear
>> operator. The number of rows is
Having immutable objects was what I initially had in mind, but I can
live with the other approach. Only, as rightly pointed out by others,
what I had implemented initially was not compatible with
AbstractRealMatrix. The new patch no longer implements getRowDimension()
and getColumnDimension().
Hi Sébastien.
> Happy 14th of July to all!
> OK, from what I understand, the patch I submitted yesterday does not
> comply with your requirements, as I provided a constructor for
> RealLinearOperator, with dimensions of the domain and codomain as
> parameters. Implicitely, I intended these to be f
On Wed, Jul 13, 2011 at 03:01:09PM -0700, Ted Dunning wrote:
> Actually, this is a major issue.
Indeed, it is an important design issue.
> Take, for instance, the example of considering a Lucene index as a linear
> operator. The number of rows is the number of documents (which is changing
> as d
Thanks Luc and Ted,
that's clear enough.
I'm looking forward to keep on working on linear operators and iterative
solvers when I'm back.
Sebastien
Le 14/07/11 10:24, Luc Maisonobe a écrit :
Hi Sébastien,
Le 14/07/2011 09:44, Ted Dunning a écrit :
Because when the interface changes, an abstra
Hi Sébastien,
Le 14/07/2011 09:44, Ted Dunning a écrit :
Because when the interface changes, an abstract class can add default
implementations (even if the implementations only throw unimplemented
operation exceptions).
That means that code that has used the abstract class won't have to break.
Because when the interface changes, an abstract class can add default
implementations (even if the implementations only throw unimplemented
operation exceptions).
That means that code that has used the abstract class won't have to break.
If you change an interface, the implementing code inevitabl
Happy 14th of July to all!
OK, from what I understand, the patch I submitted yesterday does not
comply with your requirements, as I provided a constructor for
RealLinearOperator, with dimensions of the domain and codomain as
parameters. Implicitely, I intended these to be fixed for the whole li
Actually, this is a major issue.
Take, for instance, the example of considering a Lucene index as a linear
operator. The number of rows is the number of documents (which is changing
as documents are added) and the number of columns is the number of unique
terms (which is also changing as document
On 7/13/11 2:08 PM, Gilles Sadowski wrote:
> On Wed, Jul 13, 2011 at 09:04:36AM -0700, Phil Steitz wrote:
>> On 7/13/11 8:19 AM, Gilles Sadowski wrote:
>>> Hi.
>>>
[...]
Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a
new
JIRA ticket for having Abstra
On Wed, Jul 13, 2011 at 09:04:36AM -0700, Phil Steitz wrote:
> On 7/13/11 8:19 AM, Gilles Sadowski wrote:
> > Hi.
> >
> >> [...]
> >> Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a
> >> new
> >> JIRA ticket for having AbstractRealMatrix inherit from RealLinearOperator,
> My guess is that the final declarations came out of an attempt to avoid
> warnings by over zealous code inspectors that allowing getters and setters
> of private fields to be over-ridden is dangerous. The warning is correct.
> The response was not. The correct response is to not have the privat
Absolutely.
And frankly, this makes huge since. A linear operator is a generalization
of a matrix which should have *fewer* details than a matrix. Having
implementation details of the linear operator dictate function of the matrix
is perverse. Likewise, having any operation in the linear operat
On 7/13/11 8:19 AM, Gilles Sadowski wrote:
> Hi.
>
>> [...]
>> Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a
>> new
>> JIRA ticket for having AbstractRealMatrix inherit from RealLinearOperator, if
>> that's OK with everyone.
> Currently this is not possible because the
Hi.
> [...]
> Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a new
> JIRA ticket for having AbstractRealMatrix inherit from RealLinearOperator, if
> that's OK with everyone.
Currently this is not possible because the
getRowDimension
getColumnDimension
are declared "f
I'm sorry. Did you forget to commit {{InvertibleRealLinearOperator}}?
Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a new
JIRA ticket for having AbstractRealMatrix inherit from RealLinearOperator, if
that's OK with everyone.
Because MATH-581 got a bit messy, I'll also ope
Hi.
> [...]
> Hope this new proposition will be agreeable to all.
Committed in revision 1145559.
Best,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apach
I'll do that next time. Sorry for the mess for the time being. When we
get to the "real" stuff (iterative solvers per se), maybe a new ticket
could be started?
Sebastien
Le 12/07/11 06:44, Ted Dunning a écrit :
Just attach files with the same name. Old versions will be visible but
greyed out
Just attach files with the same name. Old versions will be visible but
greyed out.
2011/7/11 Sébastien Brisard
> I've attached a new file (#04) to JIRA MATH-581. Unfortunately, I don't
> know how to remove the previous files, so this ticket is getting messy, I'm
> sorry about that.
>
Hi all,
I've been thinking again about the support for linear operators
(MATH-581). If RealLinearOperator is ever included into CM, then I think
AbstractRealMatrix should extend RealLinearOperator. Then, the
interfaces should be as consistent as possible. That's why I renamed
some methods
get
24 matches
Mail list logo
