On 18/06/15 20:28, Karl Napf wrote: > My uname -n gives > Linux ProtonBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC > 2014 i686 i686 i686 GNU/Linux > > Upon comparing np.intp and np.int32 I get the following: > > Python 3.4.3 |Anaconda 2.2.0 (32-bit)| (default, Jun 4 2015, 15:28:02) > [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux > Type "help", "copyright", "credits" or "license" for more information. >>>> import numpy as np >>>> np > <module 'numpy' from > '/home/tim/python/anaconda3/lib/python3.4/site-packages/numpy/__init__.py'> >>>> np.intp > <class 'numpy.int32'> >>>> np.intp==np.int32 > False > > I also tested this with my 64 bit machine at work today and on this > architecture, np.intp is indeed equal to np.int64. > If I find some time next week I will try out Arvinds fix.
This is a problem that will afflict all 32-bit systems due to a bug in numpy. You can reproduce with import pickle import numpy pickle.dumps([np.intp, np.int32]) At least on x86 systems 32-bit should be avoided on account of it having half the number of vector registers compared to 64-bit. This affects the performance of both PyFR and the underlying BLAS library. Regards, Freddie. -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at http://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
