David Cournapeau writes:

On Tue, Dec 9, 2008 at 12:50 AM, George Goussard wrote:

...

Hello.

I have been battling with the following error for the past week. The output from the terminal is:

What does numpy.test() says ? Did you use an external blas/lapack when you built numpy for AMD64

David

Hi David. I accidentally created a new posting previously. I have spent the last month trying to track down this bug. I am trying to compile Numpy and Matplotlib on Windows XP 64-bit. I am using the Visual Studio 2005 compiler. Everything compiles without a problem. However running matplotlib etc. gave me a lot of problems: 1. The interaction was terrible. It didn't draw anything and the console had a lot trace output with regard to singular matrices etc. Like you said, I am using an external library called Intel MKL and I decided to swap this with AMD ACML. Then the interaction was a lot better and no trace on the console of singular matrices etc. 2. Using both libraries there are problems with the plotting. In both cases the graphs are broken. It starts plotting the curve and then it stops with a section of white space and then some more of the curve etc. The same with the grid lines etc. In other words there is just something broken. I have decided to pursue this bug. I would really like to get Numpy working on AMD64. I ran the test you advised and the tests passed. However I have traced the problem to the file lines.py of matplotlib. There in a function set_xdata and set_ydata(also set_data) there is a line like x = np.asarray or y = np.asarray. My data before that line is fine, but straight after the line is executed the data is broken and garbage. I have debugged some more but I am in deep (murky) waters, but I have also ran out of ideas. If anybody has some more suggestions, please post them.

Hi Micheal. I am going on vacation tomorrow. An example will have to wait until I am back, but I can give some version information now: Numpy is version 1.2.1, Matplotlib is version 0.98.5 and I am using stock-standard(not the Enthought version or other distribution) Python 2.5. My Python 2.5 I also compiled with MSVC 2005(AMD/em64t setting) because I can't have dependecies on older crt libraries/dll's. The Intel MKL version is 10.1.0.018 and the AMD ACML version is 4.2.0. I am not using both at the same time. I have first tried the Intel one and now I am using AMD's ACML as explained in previous email. Everything is compiled using the AMD64/em64t "settings". I am not compiling on IA32 and IA64 etc. All the other necessary version information(MSVC), I'll have to check when I am back at the office. I also use other libraries like PyQt(3.17.??) and SIP(version 4.7.7). Both of them are the commercial versions and I also have commercial version of Qt 4.3.3. Needless to say that my backend agg is Qt4Agg. I have tested on Linux 64 bit (SuSe 10.?? commercial version not openSuSe) and it worked. I also tested on Windows XP 32-bit and Linux 32-bit(SuSe 10.??) and everything worked. Constructing and example won't be trivial but I'll try. The reason being thatI embedded Python in an application and then I display graphs using SIP and PyQt. The application was done using Qt4. Anyway, but I'll get back to you on that as soon as I am finished with it. Another interesting aspect is that in my application where I initially construct the array using PyArray_SimpleNew, if I change this to, for example PyArray_SimpleNewFromData then I get a completely different graph which is a solid line(not the effect I described in the previous email) but it is completely the wrong graph, with very small numbers(E-16 numbers). One thing that also bothers me is that on Windows 32-bit. The default was not FORTRAN arrays, but on Windows XP 64 bit the order and everything is FORTRAN default. I ain't even using anything remotely to FORTRAN. I think the AMD ACML is compiled using the Intel FORTRAN compiler, but will that effect it?? Anyway, I'll put an effort into constructing an example, but it will have to be when I am back at the office from my vacation. Cheers. Thanks. George.

Hello. I am terribly sorry. I was mistaken last night. I had the latest Matplotlib version 0.98.5.2 and I thought the bug was fixed but it hasn't. Let me explain. In the file MPL_isnan.h line 26 there is a declaration: typedef long int MPL_Int64 This is fine for Linux 64-bit, but NOT for Windows XP 64-bit! For Windows the declaration should be: typedef long long MPL_Int64 This bug has caused me a LOT of late nights and last night was one of them. The declaration is correct for Linux 64-bit and I guess Matplotlib was developed on Linux because of this declaration. That is also why I thought the bug was fixed but this morning I realised that I was looking at the wrong console. So, in summary. For Matplotlib 0.98.5.2 and Numpy 1.2.1 to work without any problems. This means compiling and using Numpy and Matplotlib on Windows XP 64-bit using AMD 64-bit compile environment, change line 26 in the file MPL_isnan.h from long int to long long.\ I also previously suggested switching MKL and ACML etc. but with this change everything is fine. One can choose any math library and it works. Writing a small test application using sizeof on different platforms highlights the problem. Thanks. George.

John Hunter wrote:

Andrew, since you are the original author of the isnan port, could you patch the branch and the trunk to take care of this?

Done in r6791 and r6792. Sorry for the trouble. Now I just hope we don't get a problem with "long long", although now if _ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of , so I should think this is more portable on sane platforms. This one of many reasons why I stick to Python... -Andrew

JDH

On Fri, Jan 16, 2009 at 8:07 AM, George wrote:

...

Hello.

I am terribly sorry. I was mistaken last night. I had the latest Matplotlib version 0.98.5.2 and I thought the bug was fixed but it hasn't. Let me explain.

In the file MPL_isnan.h line 26 there is a declaration:

typedef long int MPL_Int64

This is fine for Linux 64-bit, but NOT for Windows XP 64-bit! For Windows the declaration should be:

typedef long long MPL_Int64

This bug has caused me a LOT of late nights and last night was one of them. The declaration is correct for Linux 64-bit and I guess Matplotlib was developed on Linux because of this declaration. That is also why I thought the bug was fixed but this morning I realised that I was looking at the wrong console.

So, in summary. For Matplotlib 0.98.5.2 and Numpy 1.2.1 to work without any problems. This means compiling and using Numpy and Matplotlib on Windows XP 64-bit using AMD 64-bit compile environment, change line 26 in the file MPL_isnan.h from long int to long long.\

I also previously suggested switching MKL and ACML etc. but with this change everything is fine. One can choose any math library and it works.

Writing a small test application using sizeof on different platforms highlights the problem.

Thanks.

George.

_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion