ok, thank you, Ted.

It looks like it makes sense to provide options here and i will do that.

i am still not clear what is wanted for elementwise products though on
matlab side though. If it is a method then it can be just made part of
Matrix interface.

Note that there are three types of element-wise problems though that are
handled by operators:

1)  simple elementwise e.g a * b that produces a new product object;
2) in-place element wise e.g. a /= b (currently handled by a.assign(b,...)
3) right-associative in-place elementwise such as 1 /=: x (assign 1/x to x
and return x)

suppose we take a different elementwise signature, say, *@ to keep correct
scala precedence, then it will look like
1) a *@ b
2) a *@= b
3) a *@=: b (or 1 /@=: x)

even if 1..3 replaced by methods, I'd need 3 method names, not one. More
than that, we already have assigns() to handle that, albeit in a long form.

so i guess my action item would be to separate support for syntaxes but i
will leave out support for elementwise * and / until this is settled...



On Sun, Jul 28, 2013 at 6:17 PM, Ted Dunning <[email protected]> wrote:

> After letting this soak for a bit, I would tend to prefer either full-on R
> (less preferred) or Matlab with defects (more preferred).  Matlab with
> defects would use * for matrix multiplication and have a method name for
> element by element product.
>
> It is fine to have special syntax modules, but I think that this isn't all
> that big a deal.
>
>
> On Sun, Jul 28, 2013 at 11:17 AM, Dmitriy Lyubimov <[email protected]
> >wrote:
>
> > yeah. we are out of luck with matlab syntax.
> >
> > *&, *|, *^, *%, *#, *@, *~, *?, *!, *>, *<, *\ all work . '*.' or '*,'
> will
> > not work. "*:" or ":*" have special meaning.
> >
> >
> > On Sun, Jul 28, 2013 at 10:58 AM, Dmitriy Lyubimov <[email protected]
> > >wrote:
> >
> > > FWIW,
> > >
> > > one approach might be to separate DSL into several. E.g. RLikeOps and
> > > MatlabLikeOps or WhateverOps, none of which is imported by default. and
> > > then the code would have to say "import RLikeOps._" to enalbe R-like
> DSL,
> > > and vice versa.
> > >
> > > But matlab style '*.' symbol unfortunately doesn't seem to work in
> scala
> > > without backquotes. apparently scala treats '.' 'as a keyword and can't
> > > reduce it as a part of anything else.
> > >
> > >
> > > On Sat, Jul 27, 2013 at 6:43 PM, Dmitriy Lyubimov <[email protected]
> > >wrote:
> > >
> > >>
> > >>
> > >>
> > >> On Sat, Jul 27, 2013 at 6:31 PM, Dmitriy Lyubimov <[email protected]
> > >wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>> >
> > >>>> > diagv(1 /: s)
> > >>>> >
> > >>>>
> > >>>> But since this is just the inverse of the matrix, and I imagine it's
> > >>>> actually
> > >>>> clearer to do just diagv(s).inverse instead of diagv(1 /: s)
> > >>>>
> > >>>>
> > >>> Well. DSL is just the icing. Nobody's taking the cake away.
> > >>>
> > >>> in a sense that, once/if/when Mahout supports inverse(), it would be
> > >>> exactly how one might use it. DSL is not about implementation, it is
> > about
> > >>> semantic sugar only. It only maps to what exists.
> > >>>
> > >>> On a side note, it never actually occurred to me to call pinv() or
> > >>> solve() on a diagonal matrix. Or orthonormal for that matter. Their
> > >>> identities are so appealing it kind of becomes second nature after
> some
> > >>> time. the only use for solve() i had is actually for solving linear
> > >>> equations. In my R prototype for SSVD [1] one will find exactly the
> > same
> > >>> style code, i.e.  diag(1/e$values) .
> > >>>
> > >>> pardon, this should read "non-signular" of course, an honest typo.
> > >>
> > >>
> > >>> Even then you probably actually want leftInverse() and
> rightInverse(),
> > >>> not just inverse, which is only defined for *non *singular square
> > >>> matrices and would be equal right and left inverses in that case.
> Which
> > >>> oddly enough brings us back to left-associative and right-associative
> > >>> operations.
> > >>>
> > >>> [1]
> > >>>
> >
> https://cwiki.apache.org/confluence/download/attachments/27832158/ssvd.R?version=1&modificationDate=1323358453000
> > >>>
> > >>>
> > >>
> > >
> >
>

Reply via email to