In Mahout, all of this works pretty well without needing the information
that you are suggesting.
Inversion is not supported, of course, but a solve method on Diagonal can
definitely know what to do. See CholeskyDecomposition for an example.
Addition of a diagonal matrix to a normal matrix works
Okay, here we go!
Yes, every matrix can be written or considered sparse. My point is that
knowing the sparsity obeys a pattern (say diagonal) makes your life easier.
Maybe my muddled discussion has added more confusion, an example is in order
(to maximize the entropy, of course). If I was going t
On Fri, Aug 26, 2011 at 7:38 AM, Greg Sterijevski wrote:
> Ted,
>
> When you say
>
> "Functions are good, but giving a tiny bit
> more information to the function is also a great idea"
>
> do you mean information on indexing and shape of the data?
>
I meant the location of the element. For inst
On Fri, Aug 26, 2011 at 2:50 AM, Luc Maisonobe wrote:
> Thanks, Ted. That does look very flexible and approachable too. ...
>>
>
> I like the view approach, but wonder how it scales ... down for small data.
>
I doubt that it does scale all the way down. But then again, I doubt that
it matters
Ted,
When you say
"Functions are good, but giving a tiny bit
more information to the function is also a great idea"
do you mean information on indexing and shape of the data?
One thought I had, I am not sure if this is 100% applicable is the
following:
1. You have two types of data (in matrix
Le 26/08/2011 07:45, Phil Steitz a écrit :
On 8/25/11 8:11 AM, Ted Dunning wrote:
> 2011/8/25 Sébastien Brisard
>
>> Hi Ted,
>>
>>> You missed my suggestion.
>>>
>> are you referring to the thread named "New method: "addToEntry" in
>> "RealVector""?
>> If yes, I initially thought that what you su
Well, in turn, I have flipped a bit on the visitor. I just think that the
name of the method that accepts the visitor should be the same so that users
think of it as the same thing. Functions are good, but giving a tiny bit
more information to the function is also a great idea. It will still
ef
On 8/25/11 8:11 AM, Ted Dunning wrote:
> 2011/8/25 Sébastien Brisard
>
>> Hi Ted,
>>
>>> You missed my suggestion.
>>>
>> are you referring to the thread named "New method: "addToEntry" in
>> "RealVector""?
>> If yes, I initially thought that what you suggested was pretty similar
>> to the Visitor
2011/8/25 Sébastien Brisard
> Hi Ted,
>
> >
> > You missed my suggestion.
> >
> are you referring to the thread named "New method: "addToEntry" in
> "RealVector""?
> If yes, I initially thought that what you suggested was pretty similar
> to the Visitor approach.
> Thanks to the above message, I
Hi Ted,
>
> You missed my suggestion.
>
are you referring to the thread named "New method: "addToEntry" in
"RealVector""?
If yes, I initially thought that what you suggested was pretty similar
to the Visitor approach.
Thanks to the above message, I now understand that your suggestion is
the Visito
You missed my suggestion.
That is I think that there are about 10x too many methods here.
What is needed is a a copy, a couple of view operations and an assign (or
mapToSelf if you need obtuse names). The assign operation should be
over-loaded in a few convenient forms, but from the users point
Hi,
following Greg's suggestion, here is a first attempt at summarizing
what I understood from the previous discussions regarding
RealVector/RealMatrix interfaces. If we finally drop the matter, as
suggested by Phil, this will be just that: a summary. Otherwise, maybe
this list could be moved to a
There is a lot to like in the WalkInOrder* set of methods. However, it is
also very constricting. What if I want to set a whole row with a
Arrays.copyTo() call? Also, the interface is a push interface. Data is
pushed to the delegate. This is very troublesome to me. I might need random
access to the
On 8/24/11 7:27 PM, Greg Sterijevski wrote:
> Before we fill JIRA with a bunch of point-counterpoint comments. Perhaps we
> can organize our ideas on the list first?
>
> Using Gille's organization:
>
> * Consistency in naming and make explicit the rationale for choosing one or
> another naming s
Before we fill JIRA with a bunch of point-counterpoint comments. Perhaps we
can organize our ideas on the list first?
Using Gille's organization:
* Consistency in naming and make explicit the rationale for choosing one or
another naming scheme
What methods are inconsistently named? Name the m
Hi.
On Wed, Aug 24, 2011 at 02:12:33AM +0200, Sébastien Brisard wrote:
> I think this is already implemented as
> walkInXXXOrder(RealMatrixChangingVisitor). I thought it would be handy
> (and consistent with RealVector) to have this very method, but it's
> true a RealMatrixChangingVisitorFactory w
I think this is already implemented as
walkInXXXOrder(RealMatrixChangingVisitor). I thought it would be handy
(and consistent with RealVector) to have this very method, but it's
true a RealMatrixChangingVisitorFactory would do very nicely.
Sébastien
2011/8/24 Greg Sterijevski :
> Why not use Ted's
Why not use Ted's insight? Instead of a bunch of these "setDiagonal",
"setAll", "setFirstN", ... why not just have a set( MatrixFunction mf ). The
MatrixFunction delegate could handle whatever we want. It would keep the
objects very clean. You could even have a class factory of commonly used
Matrix
Maybe setAllEntries? That would be consistent with setEntry?
What about RealVector? The method set(double) should be renamed also?
Sébastien
2011/8/22 Ted Dunning :
> On Mon, Aug 22, 2011 at 1:27 PM, Phil Steitz wrote:
>
>> I think it would be good to add this, but it would probably be
>> better
On Mon, Aug 22, 2011 at 1:27 PM, Phil Steitz wrote:
> I think it would be good to add this, but it would probably be
> better to give it a different name. What name, I am not sure.
> Maybe setAll or fill. Might also be useful to have versions that
> fill submatrics.
>
Mahout allows this via ov
I think it would be good to add this, but it would probably be
better to give it a different name. What name, I am not sure.
Maybe setAll or fill. Might also be useful to have versions that
fill submatrics.
Here is a little joke to lighten things up a bit. What if we just
allow people to spe
Hi,
I believe that in o.a.c.m.linear.RealMatrix, there is no method
set(double) which would set *all* entries to the same value. Such a
method exists (and is useful) in o.a.c.m.linear.RealVector. I propose
(if you think that could be useful) to open a JIRA issue.
Thanks for your comments!
Sébastien
22 matches
Mail list logo
