Re: [eigen] On a flexible API for submatrices, slicing, indexing, masking, etc.

[ Thread Index | Date Index | More Archives ]

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
​, 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,

Mail converted by MHonArc 2.6.19+