Just as a sidenote, SystemML [1] offers a similar language and also choose the R Syntax.
[1] http://people.cs.uchicago.edu/~vikass/*SystemML*.pdf 2013/7/26 Dmitriy Lyubimov <[email protected]> > On Fri, Jul 26, 2013 at 5:12 AM, Jake Mannix <[email protected]> > wrote: > > > On Fri, Jul 26, 2013 at 5:07 AM, Ted Dunning <[email protected]> > > wrote: > > > > > This sounds great in principle. I haven't seen any details yet > (haven't > > > had time to look). > > > > > > Is there a strong reason to go with the R syntax for multiplication > > instead > > > of the matlab convention that a*b means a.times(b)? > > > > > > > +1 > > > > a * b being pointwise products will confuse any mathematician in the > > audience. > > > > I think consensus is that it is really a matter of religion and highly > depends on whether you come from R side or Matlab side. %*% ascends to R/S3 > mythology and people coming from there actually find it very familiar. So > it is really a matter of an individual opinion whether you believe Matlab > or R are more "popular". > > I personally consider %*% quite quirky myself, but having spent a lot of > time with R, i know how powerful a habit is. > > Another consideration here is that if we think of all element-wise *,/,+,- > as same class of "primitive operators" and matrix multiplication as an > "advanced" operator, and noting that there's no such thing as "advanced +, > -, /" then it seems intuitive to reserve *,/,+,- exclusively for > "primitive" operations and having "advanced *" as a special case. In that > sense, my personal opinion is that Matlab approach with .* and ./ and * is > a bit counter-intuitive and I like R approach a little better. Besides, I > am not sure if scala would support ".*" operator, and even if it did, it > would screw its precedence. > > However, i did have a thought that maybe there's a point for simplification > of %*%, which incidentally gives us correct intuitive precedence of > multiplication, but perhaps one might want to take this opportunity and > make it a little simple, such as '*%" for example. or "**" even. However, > just like your point said, i kept it in R-familiar form, just to keep it > familiar for R users. > > BTW "a times b" is valid too since Mahout already implements it that way. > All Mahout's Matrix's methods are obviously inherited, this is no more than > a syntactic sugar. > > > > > > > > > > > > > On Fri, Jul 26, 2013 at 12:07 AM, Dmitriy Lyubimov <[email protected] > > > >wrote: > > > > > > > Hello, > > > > > > > > i would like to put for discussion a proposal of adding a module > > > > mathout-math-scala to Mahout containing various scala DSLs for Mahout > > > > project. > > > > > > > > Here is what i have got so far : > > > > > > > > > > > > > > http://weatheringthrutechdays.blogspot.com/2013/07/scala-dsl-for-mahout-in-core-linear.html > > > > > > > > for now it is in-core stuff only, but it can also be used to script > out > > > > driver pipelines for Mahout DRM and solvers. (Some code, in > particular, > > > > tests may look ugly at the moment). > > > > > > > > By proposing it as a part of Mahout, I of course pursue some selfish > > > goals: > > > > since the stuff covers a lot of Mahout matrix APIs, if I have it away > > > from > > > > Mahout, i would be having hard time maintaining it in sync with > Mahout > > as > > > > the project morphs its apis. So I want to make sure that committers > run > > > my > > > > tests too before committing new changes. > > > > > > > > (I am actually using this for spark-based solvers bsed on Mahout DRMs > > and > > > > to make it more accessible to our data scientists to work with -- at > > some > > > > point I hope to contribute spark ports of some Mahout work too). > > > > > > > > Respectfully, > > > > -Dmitriy > > > > > > > > > > > > > > > -- > > > > -jake > > >
