There is an ongoing discussion about whether the function should accept an
index as well. The argument for not passing in the index is that it seems
silly for functions like plus, sin and max to get an index. You just gave
the argument for passing the index.
My preferred solution to this is to h
On Thu, Aug 18, 2011 at 08:42:53AM -0700, Ted Dunning wrote:
> I think that an anonymous inner class will do exactly this.
>
> I use this all the time to add random numbers to matrix (in Mahout-ish
> dialect)
>
> m.assign(new DoubleFunction() {
> double eval(double x) { return x + rand.next
I think that an anonymous inner class will do exactly this.
I use this all the time to add random numbers to matrix (in Mahout-ish
dialect)
m.assign(new DoubleFunction() {
double eval(double x) { return x + rand.nextGaussian(); }
})
Very handy.
On Thu, Aug 18, 2011 at 4:13 AM, Gilles Sado
On Wed, Aug 17, 2011 at 04:44:22PM -0700, Ted Dunning wrote:
> Are you going to add addAndScale and all the other gazillion common mutators
> as well?
I'd prefer not. ;-)
> Or should there just be a functional style interface where you say [...]
Cf. "AbstractRealVector.java", line 508 (as alrea
Hi,
isn't this already implemented as
map(UnivariateRealFunction function)
and
mapToSelf(UnivariateRealFunction function)
?
Also, you might want to check the discussion on JIRA MATH-613, and this thread
http://mail-archives.apache.org/mod_mbox/commons-dev/201107.mbox/%3c20110707083102.714aa14000...
Credit where it is due: this style of API was a major characteristic of Colt
and Mahout inherited this style (to our benefit).
On Wed, Aug 17, 2011 at 6:41 PM, Greg Sterijevski wrote:
> Shocking as this may seem! ;-) I like Ted's suggestion. Very clean, an
> appropriate use of OO and something fo
Shocking as this may seem! ;-) I like Ted's suggestion. Very clean, an
appropriate use of OO and something for which the penalty is not great, but
the benefit humongous! +1 for functional/functor approach.
On Wed, Aug 17, 2011 at 6:44 PM, Ted Dunning wrote:
> Are you going to add addAndScale a
Are you going to add addAndScale and all the other gazillion common mutators
as well?
Or should there just be a functional style interface where you say
A.assign(Functions.plus(3.0))
to add 3 to all elements of a matrix or vector?
That would then allow
A.assign(Functions.ABS)
or
A.a
On 8/17/11 3:14 PM, Gilles Sadowski wrote:
> Hi.
>
> 1. Is it OK to add an "addToEntry" method to "RealVector"? [There is one in
>"AbstractRealMatrix".] Do I need to open a JIRA issue for this?
> 2. Are we going to remove the "RealVector" interface in favour of keeping
>only an abstract con
Hi.
1. Is it OK to add an "addToEntry" method to "RealVector"? [There is one in
"AbstractRealMatrix".] Do I need to open a JIRA issue for this?
2. Are we going to remove the "RealVector" interface in favour of keeping
only an abstract concrete class ("AbstractRealVector") at the top of the
10 matches
Mail list logo
