This kind of issue is not a technical problem. It is a problem not already raised and exhibit by your use case this is why no error are raised for now.
Error is raised in the PR 301. It will be a workaround until we support transfer from Python to Pythran for sliced array.
If you really need it now, there is an easy solution to make it works but it will required an extra deep copy of sliced array..
I have to finish some others thinks before I can focus on this issue. Sorry about all these issues. We just need time to fix it. Thanks you for all your bugs reports. It will make Pythran better!! On 30/08/2014 00:32, Neal Becker wrote:
Silently producing wrong results is a bad thingwith ndarray, the c++ code can specify the minimum # contiguous dimensions it will accept. If it expects a dense array, for example,Array<int,2,2> and is passed an array that is not contiguous, x[:,::2],then boost::python will complain about being unable to convert. Not a very good error message, but at least you get a message.You could even put 2 versions of your routine (or for that matter, M versions) - such as one that accepts only dense arrays and another that works for general strides.At a minimum, an error message should be produced at runtime.The best behavior would be for pythran to handle both strided and non-strided arrays correctly, and as efficiently as possible. But I have no idea how difficult that would be.On Fri, Aug 29, 2014 at 4:50 PM, serge Guelton <sguelton@xxxxxxxxxxxxx <mailto:sguelton@xxxxxxxxxxxxx>> wrote:> Just for information. On your example: > > #export sum(int) > def sum (x): > > We will *assum* that x is contiguous. > > If you use : sum(a[::2]), you will have an incorrect output. > It can be fix if you need this kind of use. Correct. We should open a ticket on this one... -- /Those who don't understand recursion are doomed to repeat it/