It seems a viable option to me, as long as the Javadoc is explicit enough.
Sebastien
+1 from me.
On Tue, Jul 5, 2011 at 7:09 PM, Greg Sterijevski wrote:
> Is the consensus, then, that we leave the interface alone and handle all
> possible cases inside the body of the method?
>
Is the consensus, then, that we leave the interface alone and handle all
possible cases inside the body of the method?
It really is hard to avoid runtime checks in this kind of code. You can do
some things in types but it is really hard to get the structure right.
Requiring a symmetric or positive definite matrix is a lot like requiring a
positive real value as a parameter. We *could* define a special type fo
Yes, I believe you would have a new tagging interface called
BandedSymmetric. Implementing both interfaces would probably open things to
many errors...
2011/7/2 Sébastien Brisard
> But if you have a method taking as an input a matrix which MUST be both
> symmetric and banded, you are bound to de
But if you have a method taking as an input a matrix which MUST be both
symmetric and banded, you are bound to define a new interface.
Am I wrong?
Maybe the alternative you are thinking of is testing "instanceof
SymmetricMatrix" and "instanceof BandedMatrix" in the implementation of
the method,
Not a stupid concern in my book. However there is a synchronization
mechanism in place. We are taking part in it right now. Whether the new
matrix implements both SymmetricMatrix and BandedMatrix or is a new tagging
interface (SymmetricBanded) would determined in the list, after a bit of
back and f
Marker interface seems to be a very elegant solution. I am just
wondering about a potential issue. Let us assume we defined two
interfaces, say
SymmetricMatrix, and BandedMatrix. User A writes a matrix class which
implements both interfaces. Meanwhile, user B implements an algorithm
which requi
The marker interface is definitely the best way to make this a runtime
affair. Attempting to do this with methods will be very messy. One can
imagine testing a string of calls like isSymmetric(), isDiagonal(),
isBanded()... Furthermore, making use of overloading would not be possible.
Marker methods is what we did in Mahout. Marker interfaces is what I think
we perhaps should have done.
My rationale is that you can always introduce new marker interfaces without
changing the API but if you introduce a new marker method and aren't
hard-core about never using interfaces where abs
Hi all,
Le 02/07/2011 18:20, Ted Dunning a écrit :
That won't work.
That only works for statically declared matrix types, not run-time matrix
types. To be usable, the suggested mechanism must work against runtime
data-types.
I agree with this need to work with runtime data-types.
In one of y
That won't work.
That only works for statically declared matrix types, not run-time matrix
types. To be usable, the suggested mechanism must work against runtime
data-types.
On Sat, Jul 2, 2011 at 1:38 AM, Matthew Pocock wrote:
> You may get more mileage by having a matrix operation interface
You may get more mileage by having a matrix operation interface that has is
parameterised over the two matrix types. It would have things like multiply
once and you would have different concrete implementations for different
pairs of matrix types. The implementations can even be provided via one of
On 7/1/11 4:26 PM, Gilles Sadowski wrote:
> Hi.
>
>> Luc suggested that I move this discussion to the list. Luc posed the
>> question:
>>
>> "I don't understand how you intend to separate the API.
>> Would that mean users would always have to know beforehand the shape of the
>> matrix they use and
On 7/1/11 5:31 PM, Ted Dunning wrote:
> On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski
> wrote:
>
>> This may be a problem. Type erasure might necessitate some tricky use of
>> generics.
>>
> That won't help. Good coding practice is to declare a variable with as weak
> a type as possible so tha
On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski wrote:
> This may be a problem. Type erasure might necessitate some tricky use of
> generics.
>
That won't help. Good coding practice is to declare a variable with as weak
a type as possible so that libraries have maximum freedom to act. That
mea
This may be a problem. Type erasure might necessitate some tricky use of
generics.
On the SVD, if that's a bug, then the method which yields a reference to the
data array in realmatrix is also a bug.
On Fri, Jul 1, 2011 at 6:53 PM, Ted Dunning wrote:
> Actually, the compiler can't do the dispat
Actually, the compiler can't do the dispatch correctly.
For instance, given the following approximately real code:
Matrix a = new SparseMatrix(...);
Matrix b = new DiagonalMatrix(...);
This line will not dispatch to a special case method for either SparseMatrix
or DiagonalMatrix:
I count that as a bug in the SVD class.
On Fri, Jul 1, 2011 at 4:45 PM, Greg Sterijevski wrote:
> You are correct that moving these operations to an external class would
> expose details of data storage and break encapsulation. However, this is
> done consistently throughout math commons-look at
No sure if this went through originally, sorry if this causes a duplicate to
occur.
-Greg
-- Forwarded message --
From: Greg Sterijevski
Date: Fri, Jul 1, 2011 at 6:45 PM
Subject: Re: (MATH-608) Remove methods from RealMatrix Interface
To: Commons Developers List , d
Hi Gilles,
There is no magic which will remove the elemental complexity of these
things. However, the complexity would be concentrated in the operator
classes, where it probably should be. Furthermore, the type matching would
be handled by compiler. Finally, the multiplication routines would grow
One concrete example where second argument runtime type dispatching is
helpful is the case of multiplying a dense matrix (of any kind) by a sparse
vector. It is preferable to put the smarts for how to do this on in the
sparse vector rather than in the dense matrix, but object oriented dispatch
giv
Hi.
> Luc suggested that I move this discussion to the list. Luc posed the
> question:
>
> "I don't understand how you intend to separate the API.
> Would that mean users would always have to know beforehand the shape of the
> matrix they use and manage both the matrix, the data store and the ope
On Fri, Jul 1, 2011 at 2:35 PM, Greg Sterijevski wrote:
> My request stems from attempting to build a SymmetricRealMatrix which
> stores
> its contents in a packed format. I began implementing multiply and so forth
> and did not relish having a bunch of case statements. This lead me to the
> idea
Double dispatch was the wrong term. I should have said double argument
polymorphism. Double dispatch is a sub-optimal answer to the problem of
double polymorphism.
Apologies for polluting the discussion with a silly error.
On Fri, Jul 1, 2011 at 2:35 PM, Greg Sterijevski wrote:
> Ted,
>
> I am
Ted,
I am not sure why you think there will be double dispatch. If we remove the
multiplication method from the interface then there can only be one call to
multiply. If we want to keep the interface as is and also have a MatrixOps
class, then perhaps that is where we might have such a case. I am
Getting double dispatch this way leads to a pretty ugly API interface.
There is no reason why Matrix.times can't delegate to MatrixOp.times(this,
other), though. That gives you your double dispatch.
The real problem with this design is that adding a new matrix type is no
longer something that a
Hello All,
Luc suggested that I move this discussion to the list. Luc posed the
question:
"I don't understand how you intend to separate the API.
Would that mean users would always have to know beforehand the shape of the
matrix they use and manage both the matrix, the data store and the operator
28 matches
Mail list logo
