Re: Vector approach to row margin frequencies

[Judd Storrs]

On Thu, Jun 25, 2009 at 5:20 AM, John W. Eaton <address@hidden> wrote:

On 25-Jun-2009, Jaroslav Hajek wrote:

| On Thu, Jun 25, 2009 at 9:46 AM, Judd Storrs<address@hidden> wrote:
|

| > Is there any reason why bsxfun style singleton dimension expansion shouldn't
| > be the *default* behavior for the builtin element-wise operators (.*, .+,
| > .-) in octave? bsxfun also seems like the logical extension of the scalar
| > with matrix cases.
| >
| > Matlab compatibility could be a reason, but I don't think it would break any
| > working Matlab code (unless perhaps some strange code is relying on the
| > error handling).  I think the gain in expressivity and simplicity for octave
| > code could very well be worth it?
| >
| > Getting back to the original problem about scaling the matrix by row or by
| > column sums if "./" behaved like bsxfun but avoided the repeated function
| > evaluations then the blatently obvious _expression_ of the algorithm would
| > both work and be at least as fast as using diag,
|
| Probably almost exactly as fast as diag, at least without repmat.
|
| > while also scaling to
| > higher dimensions sanely:
| >
| > X ./ sum(X,1)
| > X ./ sum(X,2)
| > X ./ sum(X,3)
| > etc
| >
|
| I think the idea has been brought up multiple times in the past. A
| major problem is implementation: somebody has to do it. Other minor
| problems may include incorrect code that suddenly does some "magic"
| rather than fail, and incompatibility with Matlab - some Octave users
| limit themselves to Matlab-compatible subset. Scaling using diag, for
| instance, has the advantage that it does work in Matlab.
| But on general, I have no objections to that idea. However, in my
| working, scaling/unscaling matrices is by far the most common
| operation of this kind, and that is now solved elegantly using
| diagonal matrices (which also work with sparse matrices efficiently),
| so I have little motivation to actually do it.

I'd be careful about making the .-ops do row/column scaling.  I think
it would be far too easy to shoot yourself in the foot if they behaved
this way, so I'd be opposed to making this change.

What about a new type instead? In this form it seems like a small project I can work on by following diag as an example (I have limited time for this, but Robert Short's example is inspiring). I'm having trouble thinking of *the* awesome name for this and the name isn't really important for now, but what about something like adapt(), expand(), grow(), match(), merge() or join()? The synyax would look like this:

X / adapt(sum(X,1))
adapt(sum(X,2)) \ X

Would something like this be acceptable or useful to anyone except me? 

--judd