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

On Thu, Jan 5, 2017 at 9:10 PM, Yuanchen Zhu <yuanchen.zhu@xxxxxxxxx> wrote:

On Thu, Jan 5, 2017 at 11:07 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

Is this iota comparison syntax standard in APL or elsewhere?

I don't know much about APL, I've been inspired by this post:

http://ericniebler.com/2014/12/07/a-slice-of-python-in-c/#comment-130118

for the size-based version first+iota(size)*step, and then came up with the use of comparison operators to cover the aseq(first,last) version. Last Massimilliano's post seems to imply that APL also uses this strategy to define bounds...

Just from googling around, I couldn't confirm APL allows this.

We already established that iota is basically aseqn. I think the notational advantage is that you can omit the "first", "incr" parameter when they're not needed. Also you have a natural notation for the common case where incr is fixed<-1>, just put "-" in front of iota.

aseqn(0, n) = iota(n)
aseqn(0, n, fix<-1>) = -iota(n)
aseqn(0, n, s) = iota(n) * s
aseqn(a, ...) = a + ...

We now just need a syntax to cover aseq. But I really don't think "<" is a good choice.

If we view the result of iota and iota(n) as a pseudo vector, then the meaning of iota < C should not be different from v < C where v is a regular vector. Assume we still want to allow boolean mask indexing of the form v[v >= 3 && v < 5] to work, then v < C is a boolean vector.

so far I tried to unify the two uses of this _expression_-based syntax but since I cannot see real examples that would mix the size-based iota(n) with "<" bounds, we could rephrase the two use cases more distinctly:

1 - b+s*iota(n)

2 - Let "any_nat" be a placeholder for any natural number (on a paper you would write forall i in N),

then we define "lower <= any_nat*s+b <= upper" as shortcut for the set { x=i*s+b s.t., i in N and lower<= x <= upper }

So that's pretty close to what you would write on a paper, and this cannot be confused with boolean masking anymore. Then, thanks to implicit bounds we have:

A(any_mat) <--> A(all)

and thus we could (perhaps) just use "all" as a shortcut for "all natural numbers", leading to:

"lower <= all*s+b <= upper"

On true drawback is that when you combined it with fix<X>, it gets a bit messy with all these "<",">":

A(3<=(fix<2>*all)<10) // [3,5,7,9] <--> A(aseq(3,9,fix<2>))

but with extra parenthesis it's not that bad.

gael