Illegal instruction in ndimage test
Hi folks- My thanks to John Ollinger for the global context change to address SELinux issues. But it turns out that wasn't the cause of the "Illegal instruction" crash I was getting, as far as I can tell. The SELinux warning appears before scipy.test(1,1) crashes, and the crash continues to happen at the same place even after the context change (and even if I turn off text relocation protection in SELinux). Running scipy.test(1,10) helps pin down what's crashing: [snip] gaussian filter 6 ... ok gaussian gradient magnitude filter 1 ... ok gaussian gradient magnitude filter 2 ... ok gaussian laplace filter 1 ... ok gaussian laplace filter 2 ... ok generation of a binary structure 1 ... ok generation of a binary structure 2 ... ok generation of a binary structure 3 ... ok generation of a binary structure 4 ... ok generic filter 1Illegal instruction Hunting around, I found the offending test in ndimage/tests. If I rename this directory (so the tests are skipped), the tests proceed without crashing. I'd appreciate any advice on how to diagnose this problem (I don't use ndimage), or how to provide sufficient info on Trac to guide a bug fix if this is a bug. -Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
On Wed, Sep 26, 2007 at 04:06:49PM -0400, Tom Loredo wrote:
Hi folks-
My thanks to John Ollinger for the global context change to address SELinux issues. But it turns out that wasn't the cause of the "Illegal instruction" crash I was getting, as far as I can tell. The SELinux warning appears before scipy.test(1,1) crashes, and the crash continues to happen at the same place even after the context change (and even if I turn off text relocation protection in SELinux).
Running scipy.test(1,10) helps pin down what's crashing:
[snip] gaussian filter 6 ... ok gaussian gradient magnitude filter 1 ... ok gaussian gradient magnitude filter 2 ... ok gaussian laplace filter 1 ... ok gaussian laplace filter 2 ... ok generation of a binary structure 1 ... ok generation of a binary structure 2 ... ok generation of a binary structure 3 ... ok generation of a binary structure 4 ... ok generic filter 1Illegal instruction
Hunting around, I found the offending test in ndimage/tests. If I rename this directory (so the tests are skipped), the tests proceed without crashing.
This looks like http://projects.scipy.org/scipy/scipy/ticket/404 I'd be grateful if you can help me narrow it down. Cheers Stéfan
On Thursday 27 September 2007 00:11:07 Stefan van der Walt wrote:
generation of a binary structure 4 ... ok generic filter 1Illegal instruction
Hunting around, I found the offending test in ndimage/tests. If I rename this directory (so the tests are skipped), the tests proceed without crashing.
This looks like
http://projects.scipy.org/scipy/scipy/ticket/404
I'd be grateful if you can help me narrow it down.
Hi Stefan I've just run into this again with the new Mandriva (32bit) that uses: gcc version 4.2.2 20070909 (prerelease) (4.2.2-0.RC.1mdv2008.0) GCC 4.2 dumped some build errors that may be useful: (Python 2.5.1, ATLAS 3.8.0, NumPy 1.0.3.1, SciPy 0.6.0) ++++ creating build/temp.linux-i686-2.5/scipy/ndimage creating build/temp.linux-i686-2.5/scipy/ndimage/src compile options: '-Iscipy/ndimage/src -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' gcc: scipy/ndimage/src/ni_filters.c gcc: scipy/ndimage/src/nd_image.c scipy/ndimage/src/nd_image.c: In function ‘Py_Filter1DFunc’: scipy/ndimage/src/nd_image.c:273: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:273: note: if this code is reached, the program will abort scipy/ndimage/src/nd_image.c:274: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:274: note: if this code is reached, the program will abort scipy/ndimage/src/nd_image.c: In function ‘Py_FilterFunc’: scipy/ndimage/src/nd_image.c:351: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:351: note: if this code is reached, the program will abort scipy/ndimage/src/nd_image.c: In function ‘Py_Histogram’: scipy/ndimage/src/nd_image.c:1100: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:1100: note: if this code is reached, the program will abort ++++ Cheers Brett -- Brett G. Olivier PhD http://www.jjj.sun.ac.za/members#brett Stellenbosch University, South African National Bioinformatics Network
Excellent - thanks for sending this. I will have a look. Matthew On 10/18/07, Brett Olivier <bgoli@sun.ac.za> wrote:
On Thursday 27 September 2007 00:11:07 Stefan van der Walt wrote:
generation of a binary structure 4 ... ok generic filter 1Illegal instruction
Hunting around, I found the offending test in ndimage/tests. If I rename this directory (so the tests are skipped), the tests proceed without crashing.
This looks like
http://projects.scipy.org/scipy/scipy/ticket/404
I'd be grateful if you can help me narrow it down.
Hi Stefan I've just run into this again with the new Mandriva (32bit) that uses: gcc version 4.2.2 20070909 (prerelease) (4.2.2-0.RC.1mdv2008.0)
GCC 4.2 dumped some build errors that may be useful: (Python 2.5.1, ATLAS 3.8.0, NumPy 1.0.3.1, SciPy 0.6.0)
++++ creating build/temp.linux-i686-2.5/scipy/ndimage creating build/temp.linux-i686-2.5/scipy/ndimage/src compile options: '-Iscipy/ndimage/src -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' gcc: scipy/ndimage/src/ni_filters.c gcc: scipy/ndimage/src/nd_image.c scipy/ndimage/src/nd_image.c: In function 'Py_Filter1DFunc': scipy/ndimage/src/nd_image.c:273: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:273: note: if this code is reached, the program will abort scipy/ndimage/src/nd_image.c:274: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:274: note: if this code is reached, the program will abort scipy/ndimage/src/nd_image.c: In function 'Py_FilterFunc': scipy/ndimage/src/nd_image.c:351: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:351: note: if this code is reached, the program will abort scipy/ndimage/src/nd_image.c: In function 'Py_Histogram': scipy/ndimage/src/nd_image.c:1100: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:1100: note: if this code is reached, the program will abort ++++
Cheers Brett
-- Brett G. Olivier PhD http://www.jjj.sun.ac.za/members#brett Stellenbosch University, South African National Bioinformatics Network _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Hi,
gcc: scipy/ndimage/src/ni_filters.c gcc: scipy/ndimage/src/nd_image.c scipy/ndimage/src/nd_image.c: In function 'Py_Filter1DFunc': scipy/ndimage/src/nd_image.c:273: warning: function called through a non-compatible type scipy/ndimage/src/nd_image.c:273: note: if this code is reached, the program will abort
Hmm - well - this is beyond my rudimentary C, and I'd be very grateful for any help from a C person here, but: The problem seems to be this set of lines in nd_image.h (starting line 276): #define NA_OutputArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_OutputArray) #define NA_IoArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_IoArray) #define NA_NewArray (*(PyArrayObject* (*) (void* buffer, NumarrayType, int, ...) ) (void *) NA_NewArray ) #define NA_elements (*(unsigned long (*) (PyArrayObject*) ) (void *) NA_elements) #define NA_InputArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_InputArray) Commenting out these lines allows the code to compile and the ndimage tests to pass. For the offending lines in nd_image.c, (line 273 for example above), the C preprocessor generates this kind of thing: py_ibuffer = (*(PyArrayObject* (*) (void* buffer, NumarrayType, int, ...) ) (void *) NA_NewArray )(iline, NPY_DOUBLE, 1, &ilen); Now, I've no idea what the #define lines are for (it is late, but that's not the reason). Can anyone enlighten me? Matthew.
Matthew Brett wrote:
The problem seems to be this set of lines in nd_image.h (starting line 276):
#define NA_OutputArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_OutputArray) #define NA_IoArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_IoArray) #define NA_NewArray (*(PyArrayObject* (*) (void* buffer, NumarrayType, int, ...) ) (void *) NA_NewArray ) #define NA_elements (*(unsigned long (*) (PyArrayObject*) ) (void *) NA_elements) #define NA_InputArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_InputArray)
Wow, nice function pointers. I did not even know this syntax was valid. Redefines the functions with the define is a good obsfucation, too. As far as I understand, the line #define NA_NewArray (*(PyArrayObject* (*) (void* buffer, NumarrayType, int, ...) ) (void *) NA_NewArray ) Means that the previously defined NA_NewArray functions has its output casted, output which is a function pointer. So basically, this is equivalent to #define NA_NewArray (*(func_ptr) (void *) NA_NewArray ) with func_ptr a function pointer, function taking (void* buffer, NumarrayType, int, ...) as arguments, and returning PyArrayObject*. The first * is strange, though, I don't understand what than means (you cannot dereference a function pointer, normally ?). But anyway, the fact that the compiler says that it emits non supported opcodes may suggest that this is relying on undefined behaviour ? cheers, David
This is not very different from the Numpy API interface. You have an array of void* that contains your functions, and then you define macros that use this array with a cast to get the real function. Here, it seems that there is no array, but the result is identical (but it shouldn't redefine an already defined function :|) Matthieu 2007/10/19, David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
Matthew Brett wrote:
The problem seems to be this set of lines in nd_image.h (starting line 276):
#define NA_OutputArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_OutputArray) #define NA_IoArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_IoArray) #define NA_NewArray (*(PyArrayObject* (*) (void* buffer, NumarrayType, int, ...) ) (void *) NA_NewArray ) #define NA_elements (*(unsigned long (*) (PyArrayObject*) ) (void *) NA_elements) #define NA_InputArray (*(PyArrayObject* (*) (PyObject*,NumarrayType,int) ) (void *) NA_InputArray)
Wow, nice function pointers. I did not even know this syntax was valid. Redefines the functions with the define is a good obsfucation, too. As far as I understand, the line
#define NA_NewArray (*(PyArrayObject* (*) (void* buffer, NumarrayType, int, ...) ) (void *) NA_NewArray )
Means that the previously defined NA_NewArray functions has its output casted, output which is a function pointer. So basically, this is equivalent to
#define NA_NewArray (*(func_ptr) (void *) NA_NewArray )
with func_ptr a function pointer, function taking (void* buffer, NumarrayType, int, ...) as arguments, and returning PyArrayObject*. The first * is strange, though, I don't understand what than means (you cannot dereference a function pointer, normally ?).
But anyway, the fact that the compiler says that it emits non supported opcodes may suggest that this is relying on undefined behaviour ?
cheers,
David
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Matthieu Brucher wrote:
This is not very different from the Numpy API interface. You have an array of void* that contains your functions, and then you define macros that use this array with a cast to get the real function. Here, it seems that there is no array, but the result is identical (but it shouldn't redefine an already defined function :|) Yes, sure, arrays of function pointers are nothing unusual. But for some time, I was really wondering how could a preprocessor symbol refer to itself (it did not, it was just a function). I still do not understand how a function pointer can generate invalid opcode (the error message seems to appear only with gcc 4.2, not with 4.1, which is still really common), though.
cheers, David
Hi,
Yes, sure, arrays of function pointers are nothing unusual. But for some time, I was really wondering how could a preprocessor symbol refer to itself (it did not, it was just a function). I still do not understand how a function pointer can generate invalid opcode (the error message seems to appear only with gcc 4.2, not with 4.1, which is still really common), though.
Well, simply deleting those #define lines allow the code to compile without warnings and all the tests pass. Can anyone who understands this better than me have a guess as to whether deleting these lines will have some adverse effect I am not anticipating? Matthew
Hi, On 10/19/07, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
Yes, sure, arrays of function pointers are nothing unusual. But for some time, I was really wondering how could a preprocessor symbol refer to itself (it did not, it was just a function). I still do not understand how a function pointer can generate invalid opcode (the error message seems to appear only with gcc 4.2, not with 4.1, which is still really common), though.
Well, simply deleting those #define lines allow the code to compile without warnings and all the tests pass. Can anyone who understands this better than me have a guess as to whether deleting these lines will have some adverse effect I am not anticipating?
Well - I will assume that the lines were trying to solve some obscure compiler incompatibility, and delete them in SVN this evening, in the hope that either a) no-one has any problems or b) we find the previous problem and fix it in a better way. Please someone let me know if they think that's a bad idea. Matthew
Matthew
On 10/20/07, Matthew Brett <matthew.brett@gmail.com> wrote:
Well - I will assume that the lines were trying to solve some obscure compiler incompatibility, and delete them in SVN this evening, in the hope that either a) no-one has any problems or b) we find the previous problem and fix it in a better way. Please someone let me know if they think that's a bad idea.
The most recent build, which I assume includes this change (I saw the header file was updated) also seems to fixed the crashes I was getting on Windows in the test suite on generic 1d filter. Thanks, Robin
Well - I will assume that the lines were trying to solve some obscure compiler incompatibility, and delete them in SVN this evening, in the hope that either a) no-one has any problems or b) we find the previous problem and fix it in a better way. Please someone let me know if they think that's a bad idea.
Matthew
Hi, I now have one of the ndimage unittest failing. ====================================================================== FAIL: zoom 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/chanley/dev/site-packages/lib/python/scipy/ndimage/tests/test_ndi mage.py", line 2128, in test_zoom1 assert numpy.all(arr <= 24) AssertionError ---------------------------------------------------------------------- This was done I may Intel Mac running OS X 10.4.10. I will see if I can reproduce this error in other locations. -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338
Christopher Hanley wrote:
Well - I will assume that the lines were trying to solve some obscure compiler incompatibility, and delete them in SVN this evening, in the hope that either a) no-one has any problems or b) we find the previous problem and fix it in a better way. Please someone let me know if they think that's a bad idea.
Matthew
Hi,
I now have one of the ndimage unittest failing.
====================================================================== FAIL: zoom 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/chanley/dev/site-packages/lib/python/scipy/ndimage/tests/test_ndi mage.py", line 2128, in test_zoom1 assert numpy.all(arr <= 24) AssertionError
----------------------------------------------------------------------
This was done I may Intel Mac running OS X 10.4.10.
I will see if I can reproduce this error in other locations.
This is also an issue on my RHE 3 Linux box. ====================================================================== FAIL: zoom 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/sparty1/dev/site-packages/lib/python/scipy/ndimage/tests/test_ndimage.py", line 2125, in test_zoom1 assert numpy.all(arr[-1,:] >= 20) AssertionError ---------------------------------------------------------------------- I build both scipy and numpy nightly from svn so I have the bleeding edge of both versions. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338
Hi Chris, Would you please send me the output of from scipy import ndimage import numpy arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n' This isn't due to Matthew's change, but to mine. Thanks, Stéfan On Mon, Oct 22, 2007 at 09:50:57AM -0400, Christopher Hanley wrote:
Well - I will assume that the lines were trying to solve some obscure compiler incompatibility, and delete them in SVN this evening, in the hope that either a) no-one has any problems or b) we find the previous problem and fix it in a better way. Please someone let me know if they think that's a bad idea.
Matthew
Stefan van der Walt wrote:
Hi Chris,
Would you please send me the output of
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n'
This isn't due to Matthew's change, but to mine.
Thanks, Stéfan
Hi Stefan, This is what I get on my RHE 3 machine:
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n' [[ -1.04083409e-16 2.78867102e-01 8.66376180e-01 1.36601307e+00 1.79084967e+00 2.20915033e+00 2.63398693e+00 3.13362382e+00 3.72113290e+00 4.00000000e+00] [ 1.39433551e+00 1.67320261e+00 2.26071169e+00 2.76034858e+00 3.18518519e+00 3.60348584e+00 4.02832244e+00 4.52795933e+00 5.11546841e+00 5.39433551e+00] [ 4.33188090e+00 4.61074800e+00 5.19825708e+00 5.69789397e+00 6.12273057e+00 6.54103123e+00 6.96586783e+00 7.46550472e+00 8.05301380e+00 8.33188090e+00] [ 6.83006536e+00 7.10893246e+00 7.69644154e+00 8.19607843e+00 8.62091503e+00 9.03921569e+00 9.46405229e+00 9.96368918e+00 1.05511983e+01 1.08300654e+01] [ 8.95424837e+00 9.23311547e+00 9.82062455e+00 1.03202614e+01 1.07450980e+01 1.11633987e+01 1.15882353e+01 1.20878722e+01 1.26753813e+01 1.29542484e+01] [ 1.10457516e+01 1.13246187e+01 1.19121278e+01 1.24117647e+01 1.28366013e+01 1.32549020e+01 1.36797386e+01 1.41793755e+01 1.47668845e+01 1.50457516e+01] [ 1.31699346e+01 1.34488017e+01 1.40363108e+01 1.45359477e+01 1.49607843e+01 1.53790850e+01 1.58039216e+01 1.63035585e+01 1.68910675e+01 1.71699346e+01] [ 1.56681191e+01 1.59469862e+01 1.65344953e+01 1.70341322e+01 1.74589688e+01 1.78772694e+01 1.83021060e+01 1.88017429e+01 1.93892520e+01 1.96681191e+01] [ 1.86056645e+01 1.88845316e+01 1.94720407e+01 1.99716776e+01 2.03965142e+01 2.08148148e+01 2.12396514e+01 2.17392883e+01 2.23267974e+01 2.26056645e+01] [ 2.00000000e+01 2.02788671e+01 2.08663762e+01 2.13660131e+01 2.17908497e+01 2.22091503e+01 2.26339869e+01 2.31336238e+01 2.37211329e+01 2.40000000e+01]]
Thanks, Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338
Thanks, Chris. Does the test pass now? Regards Stéfan On Mon, Oct 22, 2007 at 12:27:56PM -0400, Christopher Hanley wrote:
Stefan van der Walt wrote:
Hi Chris,
Would you please send me the output of
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n'
This isn't due to Matthew's change, but to mine.
Thanks, Stéfan
Hi Stefan,
This is what I get on my RHE 3 machine:
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n' [[ -1.04083409e-16 2.78867102e-01 8.66376180e-01 1.36601307e+00 1.79084967e+00 2.20915033e+00 2.63398693e+00 3.13362382e+00 3.72113290e+00 4.00000000e+00] [ 1.39433551e+00 1.67320261e+00 2.26071169e+00 2.76034858e+00 3.18518519e+00 3.60348584e+00 4.02832244e+00 4.52795933e+00 5.11546841e+00 5.39433551e+00] [ 4.33188090e+00 4.61074800e+00 5.19825708e+00 5.69789397e+00 6.12273057e+00 6.54103123e+00 6.96586783e+00 7.46550472e+00 8.05301380e+00 8.33188090e+00] [ 6.83006536e+00 7.10893246e+00 7.69644154e+00 8.19607843e+00 8.62091503e+00 9.03921569e+00 9.46405229e+00 9.96368918e+00 1.05511983e+01 1.08300654e+01] [ 8.95424837e+00 9.23311547e+00 9.82062455e+00 1.03202614e+01 1.07450980e+01 1.11633987e+01 1.15882353e+01 1.20878722e+01 1.26753813e+01 1.29542484e+01] [ 1.10457516e+01 1.13246187e+01 1.19121278e+01 1.24117647e+01 1.28366013e+01 1.32549020e+01 1.36797386e+01 1.41793755e+01 1.47668845e+01 1.50457516e+01] [ 1.31699346e+01 1.34488017e+01 1.40363108e+01 1.45359477e+01 1.49607843e+01 1.53790850e+01 1.58039216e+01 1.63035585e+01 1.68910675e+01 1.71699346e+01] [ 1.56681191e+01 1.59469862e+01 1.65344953e+01 1.70341322e+01 1.74589688e+01 1.78772694e+01 1.83021060e+01 1.88017429e+01 1.93892520e+01 1.96681191e+01] [ 1.86056645e+01 1.88845316e+01 1.94720407e+01 1.99716776e+01 2.03965142e+01 2.08148148e+01 2.12396514e+01 2.17392883e+01 2.23267974e+01 2.26056645e+01] [ 2.00000000e+01 2.02788671e+01 2.08663762e+01 2.13660131e+01 2.17908497e+01 2.22091503e+01 2.26339869e+01 2.31336238e+01 2.37211329e+01 2.40000000e+01]]
Thanks, Chris
Yes. Thanks. Cheers, Chris On Oct 22, 2007, at 4:34 PM, Stefan van der Walt <stefan@sun.ac.za> wrote:
Thanks, Chris. Does the test pass now?
Regards Stéfan
On Mon, Oct 22, 2007 at 12:27:56PM -0400, Christopher Hanley wrote:
Stefan van der Walt wrote:
Hi Chris,
Would you please send me the output of
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n'
This isn't due to Matthew's change, but to mine.
Thanks, Stéfan
Hi Stefan,
This is what I get on my RHE 3 machine:
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n' [[ -1.04083409e-16 2.78867102e-01 8.66376180e-01 1.36601307e+00 1.79084967e+00 2.20915033e+00 2.63398693e+00 3.13362382e+00 3.72113290e+00 4.00000000e+00] [ 1.39433551e+00 1.67320261e+00 2.26071169e+00 2.76034858e+00 3.18518519e+00 3.60348584e+00 4.02832244e+00 4.52795933e+00 5.11546841e+00 5.39433551e+00] [ 4.33188090e+00 4.61074800e+00 5.19825708e+00 5.69789397e+00 6.12273057e+00 6.54103123e+00 6.96586783e+00 7.46550472e+00 8.05301380e+00 8.33188090e+00] [ 6.83006536e+00 7.10893246e+00 7.69644154e+00 8.19607843e+00 8.62091503e+00 9.03921569e+00 9.46405229e+00 9.96368918e+00 1.05511983e+01 1.08300654e+01] [ 8.95424837e+00 9.23311547e+00 9.82062455e+00 1.03202614e+01 1.07450980e+01 1.11633987e+01 1.15882353e+01 1.20878722e+01 1.26753813e+01 1.29542484e+01] [ 1.10457516e+01 1.13246187e+01 1.19121278e+01 1.24117647e+01 1.28366013e+01 1.32549020e+01 1.36797386e+01 1.41793755e+01 1.47668845e+01 1.50457516e+01] [ 1.31699346e+01 1.34488017e+01 1.40363108e+01 1.45359477e+01 1.49607843e+01 1.53790850e+01 1.58039216e+01 1.63035585e+01 1.68910675e+01 1.71699346e+01] [ 1.56681191e+01 1.59469862e+01 1.65344953e+01 1.70341322e+01 1.74589688e+01 1.78772694e+01 1.83021060e+01 1.88017429e+01 1.93892520e+01 1.96681191e+01] [ 1.86056645e+01 1.88845316e+01 1.94720407e+01 1.99716776e+01 2.03965142e+01 2.08148148e+01 2.12396514e+01 2.17392883e+01 2.23267974e+01 2.26056645e+01] [ 2.00000000e+01 2.02788671e+01 2.08663762e+01 2.13660131e+01 2.17908497e+01 2.22091503e+01 2.26339869e+01 2.31336238e+01 2.37211329e+01 2.40000000e+01]]
Thanks, Chris
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Stefan van der Walt wrote:
Hi Chris,
Would you please send me the output of
from scipy import ndimage import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr, 2, order=2) print arr, '\n'
This isn't due to Matthew's change, but to mine.
Thanks, Stéfan
Below is what I get from my Intel Mac:
from scipy import ndimage import numpy>>> import numpy
arr = numpy.array(range(25)).reshape((5,5)).astype(float) arr = ndimage.zoom(arr,2,order=2) print arr, '\n' [[ 1.55431223e-15 2.78867102e-01 8.66376180e-01 1.36601307e+00 1.79084967e+00 2.20915033e+00 2.63398693e+00 3.13362382e+00 3.72113290e+00 4.00000000e+00] [ 1.39433551e+00 1.67320261e+00 2.26071169e+00 2.76034858e+00 3.18518519e+00 3.60348584e+00 4.02832244e+00 4.52795933e+00 5.11546841e+00 5.39433551e+00] [ 4.33188090e+00 4.61074800e+00 5.19825708e+00 5.69789397e+00 6.12273057e+00 6.54103123e+00 6.96586783e+00 7.46550472e+00 8.05301380e+00 8.33188090e+00] [ 6.83006536e+00 7.10893246e+00 7.69644154e+00 8.19607843e+00 8.62091503e+00 9.03921569e+00 9.46405229e+00 9.96368918e+00 1.05511983e+01 1.08300654e+01] [ 8.95424837e+00 9.23311547e+00 9.82062455e+00 1.03202614e+01 1.07450980e+01 1.11633987e+01 1.15882353e+01 1.20878722e+01 1.26753813e+01 1.29542484e+01] [ 1.10457516e+01 1.13246187e+01 1.19121278e+01 1.24117647e+01 1.28366013e+01 1.32549020e+01 1.36797386e+01 1.41793755e+01 1.47668845e+01 1.50457516e+01] [ 1.31699346e+01 1.34488017e+01 1.40363108e+01 1.45359477e+01 1.49607843e+01 1.53790850e+01 1.58039216e+01 1.63035585e+01 1.68910675e+01 1.71699346e+01] [ 1.56681191e+01 1.59469862e+01 1.65344953e+01 1.70341322e+01 1.74589688e+01 1.78772694e+01 1.83021060e+01 1.88017429e+01 1.93892520e+01 1.96681191e+01] [ 1.86056645e+01 1.88845316e+01 1.94720407e+01 1.99716776e+01 2.03965142e+01 2.08148148e+01 2.12396514e+01 2.17392883e+01 2.23267974e+01 2.26056645e+01] [ 2.00000000e+01 2.02788671e+01 2.08663762e+01 2.13660131e+01 2.17908497e+01 2.22091503e+01 2.26339869e+01 2.31336238e+01 2.37211329e+01 2.40000000e+01]]
Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338
participants (8)
-
Brett Olivier -
Christopher Hanley -
David Cournapeau -
Matthew Brett -
Matthieu Brucher -
Robin -
Stefan van der Walt -
Tom Loredo