Re: [eigen] On a flexible API for submatrices, slicing, indexing, maskin

On Sat, Dec 24, 2016 at 1:01 AM, Yuanchen Zhu <yuanchen.zhu@xxxxxxxxx> wrote:

Dear Peter,

On Fri, Dec 23, 2016 at 3:04 AM, Peter <list@xxxxxxxxxxxxxxxxx> wrote:
Dear Yuanchen Zhu,

Am 22.12.2016 um 17:29 schrieb Yuanchen Zhu:

Regarding API naming and convention, I also much prefer a matlab/STL like syntax of normalized(v) instead of v.normalized(), as well as writing cwise_max instead of cwiseMax, so I also have those aliases in my plugin. But I guess
those are for another thread.

The syntax like v.normalized() allows to chain expressions, and speaking for myself,
I find it very convenient to write long one-liner and I rather prefer

W.row(x).segment(0, M-1).normalize()

compared to

normalize(segment( row( W, x)), 0, M-1))

I think this example reflects how ugly and noisy the current subblock API is. With a new API, it can look like

normalized(W(x, span(0, M-1))

which is pretty clean and self explanatory.

Also, using free-standing function is the standard notation from math and engineering. a.cross(b) just feels unnatural and noisy compared to cross(a, b).

Finally realistically speaking, I don't think you will be able to meaningfully chain a lot of regular Eigen function calls, EXCEPT when you're using the subblock API, as the those return basically the same type (blocks).

A one liner containing many chained function, while easier to write, can be very confusing for the reader as well.

Just want to add that I realized your original example uses

the mutating

normalize()

, not the pure function

normalized(). My preference towards free-standing notation mostly to applies to pure function only. For mutating methods, I am a little ambivalent. But like Gael said, some times the necessity of allowing generic algorithms calls for a free-standing version.

where one would always mess with the number of brackets.

Best regards,
Peter