Re: [Math] New method: "addToEntry" in "RealVector"
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 have an IndexedFunction type. Functions.ABS is just a DoubleFunction. It is assumed that pretty much all indexed functions would be defined in-line. For the case where you are referring to another vector element by a corresponding index, there are versions of assign which take a vector and a binary function. This usually handles the case that you describe, but there are still corner cases especially where you want to do something to a vector based on corresponding rows (or columns) of a matrix. On Thu, Aug 18, 2011 at 10:47 AM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > Not even saying that the code will become unreadable. One instance where > I'd perform "addToEntry", the "value" below is computed from a matrix entry > whose column index is "i". How do you retrieve that from the prototype > above? >
Re: [Math] New method: "addToEntry" in "RealVector"
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.nextGaussian(); } > }) > > Very handy. Not really if I have to create several such functions that take parameters of various type, and certainly not if I'd have to define them inline everywhere there is an "addToEntry". Not even saying that the code will become unreadable. One instance where I'd perform "addToEntry", the "value" below is computed from a matrix entry whose column index is "i". How do you retrieve that from the prototype above? Gilles > On Thu, Aug 18, 2011 at 4:13 AM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > > > > > However this is not what I need. The purpose is to have a shortcut for > > ---CUT--- > > for (int i = 0; i < n; i++) { > > final double value = <...>; // Not a constant. > > v.setEntry(i, v.getEntry(i) + value); > > } > > ---CUT--- > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] New method: "addToEntry" in "RealVector"
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 Sadowski < gil...@harfang.homelinux.org> wrote: > > However this is not what I need. The purpose is to have a shortcut for > ---CUT--- > for (int i = 0; i < n; i++) { > final double value = <...>; // Not a constant. > v.setEntry(i, v.getEntry(i) + value); > } > ---CUT--- >
Re: [Math] New method: "addToEntry" in "RealVector"
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 already pointed out by Sébastien). However this is not what I need. The purpose is to have a shortcut for ---CUT--- for (int i = 0; i < n; i++) { final double value = <...>; // Not a constant. v.setEntry(i, v.getEntry(i) + value); } ---CUT--- Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] New method: "addToEntry" in "RealVector"
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...@svoboda.polytechnique.org%3E Best, Sébastien 2011/8/18 Ted Dunning : > 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 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 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.assign(Functions.times(0.3)) >> > >> > This allows one method to serve many, many purposes, including those that >> > are not yet known. >> > >> > Similar logic leads to a family of assign methods and also some aggregate >> > methods. The resulting flexibility and parsimony is very nice. >> > >> > On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski < >> > gil...@harfang.homelinux.org> wrote: >> > >> > > 1. Is it OK to add an "addToEntry" method to "RealVector"? [There is >> one >> > in >> > > >> > >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] New method: "addToEntry" in "RealVector"
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 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 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.assign(Functions.times(0.3)) > > > > This allows one method to serve many, many purposes, including those that > > are not yet known. > > > > Similar logic leads to a family of assign methods and also some aggregate > > methods. The resulting flexibility and parsimony is very nice. > > > > On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski < > > gil...@harfang.homelinux.org> wrote: > > > > > 1. Is it OK to add an "addToEntry" method to "RealVector"? [There is > one > > in > > > > > >
Re: [Math] New method: "addToEntry" in "RealVector"
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 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.assign(Functions.times(0.3)) > > This allows one method to serve many, many purposes, including those that > are not yet known. > > Similar logic leads to a family of assign methods and also some aggregate > methods. The resulting flexibility and parsimony is very nice. > > On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > > > 1. Is it OK to add an "addToEntry" method to "RealVector"? [There is one > in > > >
Re: [Math] New method: "addToEntry" in "RealVector"
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.assign(Functions.times(0.3)) This allows one method to serve many, many purposes, including those that are not yet known. Similar logic leads to a family of assign methods and also some aggregate methods. The resulting flexibility and parsimony is very nice. On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > 1. Is it OK to add an "addToEntry" method to "RealVector"? [There is one in >
Re: [Math] New method: "addToEntry" in "RealVector"
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 concrete class ("AbstractRealVector") at the top of the >hierarchy? [The class could be renamed "RealVector".] +1 to go ahead and remove the interface and reclaim the name. This is a little scary, but now is the time to do these things. I am thinking about doing the same thing in lots of interface/impl splits where we have only one impl. If anyone is opposed to this, please speak up now. I think each such change should be tracked in a JIRA and changes.xml so we have a record of the decision and the associated commits. Phil > > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] New method: "addToEntry" in "RealVector"
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 hierarchy? [The class could be renamed "RealVector".] Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org