A few improvement ideas

[Antony Lee]

1) Add fused types corresponding to numpy's "abstract" fused types (http://docs.scipy.org/doc/numpy/reference/arrays.scalars.html#scalars): np.generic, np.number, np.{,unsigned,signed}integer, np.inexact, np.{,complex}floating, np.flexible, np.character

2) Correctly handle *literal* negative indices in a wraparound(False) context: if I write "t[-1]" while c what I mean is perfectly clear and can be compiled without any additional overhead -- in fact cython even prints a warning in such a case.

3) As far as I can tell, when X is typed as a 1-d memoryview and x as a variable of that type, "for x in X" does not generate a tight C-loop but instead goes through the Python iteration machinery.  I believe it should be possible to directly generate a C-loop instead?

Best,

Antony

[Darsh Ranjan]

On 07/25/2016 12:51 AM, Antony Lee wrote:
> 2) Correctly handle *literal* negative indices in a wraparound(False)
> context: if I write "t[-1]" while c what I mean is perfectly clear and
> can be compiled without any additional overhead -- in fact cython even
> prints a warning in such a case.
>

I'm not sure if this is what you meant, but I think it's a bad idea to
have different semantics for literals vs. general expressions.
Predictability and consistency are more important than convenience.

(That's just for semantics; optimization is a different game.)

-Darsh

[Stefan Behnel]

Agreed. It would be surprising if this code worked:

t[-1]

but refactoring it to this made it fail:

x = -1
t[x]

Stefan

[Stefan Behnel]

Antony Lee schrieb am 25.07.2016 um 09:51:
> 1) Add fused types corresponding to numpy's "abstract" fused types (
> http://docs.scipy.org/doc/numpy/reference/arrays.scalars.html#scalars):
> np.generic, np.number, np.{,unsigned,signed}integer, np.inexact,
> np.{,complex}floating, np.flexible, np.character

Sounds reasonable. Look for "floating" in Shadow.py (cython.* namespace in
pure Python mode), PyrexTypes.py and CythonScope.py (cython.* during
compilation).

> 3) As far as I can tell, when X is typed as a 1-d memoryview and x as a
> variable of that type, "for x in X" does not generate a tight C-loop but
> instead goes through the Python iteration machinery. I believe it should
> be possible to directly generate a C-loop instead?

Certainly. See the class IterationTransform in Optimize.py.

Pull requests welcome.

Stefan