You're right that my post's algo does not handle this case (it's more of a toy to explain the basic cases).
> When I read Allan and Kennedy my impression was that vectorising arbitrary imperative code is a much harder problem than designing a language that only allows for vectorisable constructs to be expressed in the first place.
Yeah, I buy this.
> In my example that would produce different code, requiring a multiplication:
lambda i: table[(phase0 + i*inc) % TABLE_LEN]
I think some compilers may lower this without the multiplication.. (e.g. turning it back into an induction variable) but with floats they may not be allowed to, since repeated addition and "phase0 + i*inc" are not strictly equal.
> When I read Allan and Kennedy my impression was that vectorising arbitrary imperative code is a much harder problem than designing a language that only allows for vectorisable constructs to be expressed in the first place.
Yeah, I buy this.
> In my example that would produce different code, requiring a multiplication:
I think some compilers may lower this without the multiplication.. (e.g. turning it back into an induction variable) but with floats they may not be allowed to, since repeated addition and "phase0 + i*inc" are not strictly equal.