pyccel: Using multi dimensional arrays with different orders to create another array, causes a semantics error

To Reproduce

if __name__ == "__main__":
    import numpy as np
    a = np.array([[1], [2], [4]], order="F")
    b = np.array([[4], [5], [6]], order="C")
    c = np.array([a, b], order="C")

a and b must be multi dimensional and of different orders to reproduce this bug.

Generates a semantics error

pyccel:
 |fatal [semantic]: testbug.py [5,17]| Inhomogeneous lists are not supported by Pyccel. Please use a tuple ((a, b))

Expected behavior Should pass the semantics check.

Additional context As long as it passes the semantics check, Pyccel will be able to copy Python’s behaviour.

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 23 (23 by maintainers)

Most upvoted comments

I understand, thanks!

If you have understood how it works then it would be great if you could add the docs about the “order”. That would also allow me to reread it and make sure you have understood correctly.

In Fortran the strides are not multiplied by the other dimensions. The ordering just tells us whether the indexing should be treated as column major or row major. (Someone needs to write a section in the developer docs about this)

Have a look at the Fortran translation of:

def f():
    a = np.ones((4,6), order='F')
    for ai in a:
        print(ai)

def g():
    a = np.ones((4,6), order='C')
    for ai in a:
        print(ai)

And see if you can see how it works

I think I understand now, could we add language specific attributes (attributes that are intended only for a specific language printing ) to these objects that would specify different writing functions for both C and Fortran. I don’t know if that would work.

We talked about adding a language-specific semantic stage at some point. At the moment we try to keep the implementations as similar as possible and add any language-specific minor changes in the code printing stage.

In any case, just because you can do:

ndarray a;
ndarray b;
ndarray* c[2];
c[0] = &a;
c[1] = &b;

it doesn’t mean it will be efficient or a good idea. Sometimes pyccel restrictions are just a way of encouraging users to follow best practices which can also accelerate their code