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
Hi all guys,
after a failing RC1, thanks to Luc's suggestions I've quickly prepared a RC2.
Please cast your votes and many thanks in advance for your effort on
reviewing!!!
All the best, have a nice weekend,
Simo
Release Notes:
http://people.apache.org/builds/commons/digester/3.0/RC2/RELEASE-NOTE
Hi Dennis,
thanks for your interest on Commons Graph!!! If you don't find enough
material about it, it's because it is still at the early development
on Sandbox.
It doesn't mean that it doesn't work - you can have a look at the
testcases[1] - they are simple enough to understand how
functionalities
Hi
I have an idea that requires a library that can construct graphs and
turn them into images. A quick look at the source tree for Commons Graph
shows no sign of examples or documentation. Are there any? Would Commons
Graph fit into my requirements above?
--
Dennis Lundberg
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,
Salut Luc,
just to let you know I finally figured out how to fix that error, take
a look at r1142280[1].
Thanks for your support, I'm now ready to push a new RC!
All the best, have a nice WE!
Simo
[1]http://svn.apache.org/viewvc?view=revision&revision=1142280
http://people.apache.org/~simonetripo
Thanks for your help Luc!
I'm currently investigating, the CallMethodRule worked in that way for
ages - at least since before I joined the commons - the check you are
proposing makes a lot of sense.
I'll keep you updated, thanks!!!
Have a nice day, all the best,
Simo
http://people.apache.org/~simo
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
Le 02/07/2011 20:05, Simone Tripodi a écrit :
Hi all guys,
it could be a silly questions, but I need help on fixing a
NP_NULL_ON_SOME_PATH findbugs error, I don't see where the violation
is.
The problem is
Possible null pointer dereference of CallMethodRule.paramTypes in
org.apache.commons.
Hi all guys,
it could be a silly questions, but I need help on fixing a
NP_NULL_ON_SOME_PATH findbugs error, I don't see where the violation
is.
The problem is
Possible null pointer dereference of CallMethodRule.paramTypes in
org.apache.commons.digester3.CallMethodRule.end(String, String) line
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
Hi,
Henri Yandell wrote:
> These are the current blocking items in play afaik:
>
> * Email thread - what else should implement Formattable?
> * LANG-696/Email thread - getShortName. What to do with the (String)
> variant. Remove others.
> * Email thread - Validate method naming
Can somebody els
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
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
19 matches
Mail list logo
