[Numpy-discussion] in the NA discussion, what can we agree on?
Laurent Gautier
lgautier at gmail.com
Thu Nov 3 04:03:29 EDT 2011
On 2011-11-03 04:22, numpy-discussion-request at scipy.org wrote:
>
> Message: 1
> Date: Wed, 2 Nov 2011 22:20:15 -0500
> From: Benjamin Root<ben.root at ou.edu>
> Subject: Re: [Numpy-discussion] in the NA discussion, what can we
> agree on?
> To: Discussion of Numerical Python<numpy-discussion at scipy.org>
> Message-ID:
> <CANNq6FnLkweuXugoEy0kTO7Yi-V+tnV3nZJ6uPUKkva+D0Dz6A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday, November 2, 2011, Nathaniel Smith<njs at pobox.com> wrote:
>> Hi Benjamin,
>>
>> On Wed, Nov 2, 2011 at 5:25 PM, Benjamin Root<ben.root at ou.edu> wrote:
>>> I want to pare this down even more. I think the above lists makes too
> many
>>> unneeded extrapolations.
>> Okay. I found your formatting a little confusing, so I want to make
>> sure I understood the changes you're suggesting:
>>
>> For the description of what MISSING means, you removed the lines:
>> - Compatibility with R is valuable
>> - To avoid user confusion, ideally it should *not* be possible to
>> 'unmask' a missing value, since this is inconsistent with the "missing
>> value" metaphor (e.g., see Wes's comment about "leaky abstractions")
>>
>> And you added the line:
>> + Assigning MISSING is destructive
>>
>> And for the description of what IGNORED means, you removed the lines:
>> - Some memory overhead is inevitable and acceptable
>> - Compatibility with R neither possible nor valuable
>> - Ability to toggle the IGNORED state of a location is critical, and
>> should be as convenient as possible
>>
>> And you added the lines:
>> + IGNORE is non-destructive
>> + Must be competitive with np.ma for speed and memory (or else users
>> would just use np.ma)
>>
>> Is that right?
> Correct.
>
>> Assuming it is, my thoughts are:
>>
>> By R compatibility, I specifically had in mind in-memory
>> compatibility. rpy2 provides a more-or-less seamless within-process
>> interface between R and Python (and specifically lets you get numpy
>> views on arrays returned by R functions), so if we can make this work
>> for R arrays containing NA too then that'd be handy. (The rpy2 author
>> requested this in the last discussion here:
>> http://mail.scipy.org/pipermail/numpy-discussion/2011-June/057084.html)
>> When it comes to disk formats, then this doesn't matter so much, since
>> IO routines have to translate between different representations all
>> the time anyway.
>>
> Interesting, but I still have to wonder if that should be on the wishlist
> for MISSING. I guess it would matter by knowing whether people would be
> fully converting from R or gradually transitioning from it? That is
> something that I can't answer.
I probably do not have all possible use-cases but what I'd think of as
the most common is: use R stuff just straight out of R from Python. Say
that you are doing your work in Python and read about some statistical
method for which an implementation in R exists (but not in
Python/numpy). You can just pass your numpy arrays or vectors to the
relevant R function(s) and retrieve the results in a form directly
usable by numpy (without having the data copied around). Should
performances become an issue, and that method be of crucial importance,
you will probably want to reimplement it (C, or Cython, for example).
Otherwise you could pick R's phenomenal toolbox without much effort and
keep those calls to R as part of your code.
In my experience, the later would be the most frequent.
Get some compatibility for the NA "magic" values and that possible
coupling between R and numpy becomes even better by preventing one side
or the other to understand them as non-NA values.
>
>> I take the replacement of my line about MISSING disallowing unmasking
>> and your line about MISSING assignment being destructive as basically
>> expressing the same idea. Is that fair, or did you mean something
>> else?
> I am someone who wants to get to the absolute core of ideas. Also, this
> expression cleanly delineates the differences as binary.
>
> By expressing it this way, we also shy away from implementation details.
> For example, Unmasking can be programmatically prevented for MISSING while
> it could be implemented by other indirect means for IGNORE. Not that those
> are the preferred ways, only that the phrasing is more flexible and
> exacting.
>
>> Finally, do you think that people who want IGNORED support care about
>> having a convenient API for masking/unmasking values? You removed that
>> line, but I don't know if that was because you disagreed with it, or
>> were just trying to simplify.
> See previous.
>
>>> Then, as a third-party module developer, I can tell you that having
> separate
>>> and independent ways to detect "MISSING"/"IGNORED" would likely make
> support
>>> more difficult and would greatly benefit from a common (or easily
>>> combinable) method of identification.
>> Right, sorry... I didn't forget, and that's part of what I was
>> thinking when I described the second approach as keeping them as
>> *mostly*-separate interfaces... but I should have made it more
>> explicit! Anyway, yes:
>>
>> 4) There is consensus that whatever approach is taken, there should be
>> a quick and convenient way to identify values that are MISSING,
>> IGNORED, or both. (E.g., functions is_MISSING, is_IGNORED,
>> is_MISSING_or_IGNORED, or some equivalent.)
>>
> Good.
>
> Cheers!
> Ben Root
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20111102/e4be49be/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Thu, 3 Nov 2011 08:53:26 +0530
> From: akshar bhosale<akshar.bhosale at gmail.com>
> Subject: Re: [Numpy-discussion] Fwd: numpy error with mkl 10.1
> To: Discussion of Numerical Python<numpy-discussion at scipy.org>
> Message-ID:
> <CANaMn16k=La+4t+QasbeeUVS3d20-a8JgN5RkoqPO0+zFu3wXg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> thanks once again. how can i use ur distutils directly (ur supplied files
> etc)
>
> On Thu, Nov 3, 2011 at 8:15 AM, Olivier Delalleau<shish at keba.be> wrote:
>
>> Yes they pass:
>>
>> Ran 2030 tests in 6.672s
>>
>> OK (KNOWNFAIL=1)
>> <nose.result.TextTestResult run=2030 errors=0 failures=0>
>>
>> Google "einsum hang".... I know you're not the first one with this bug
>> (but I'm not sure exactly how to fix it).
>>
>> -=- Olivier
>>
>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>
>>> my numpy.test hangs here
>>>
>>> Test whether equivalent subarray dtypes hash the same. ... ok
>>> Test whether different subarray dtypes hash differently. ... ok
>>> Test some data types that are equal ... ok
>>> Test some more complicated cases that shouldn't be equal ... ok
>>> Test some simple cases that shouldn't be equal ... ok
>>> test_single_subarray (test_dtype.TestSubarray) ... ok
>>> test_einsum_errors (test_einsum.TestEinSum) ... ok
>>> test_einsum_sums_cfloat128 (test_einsum.TestEinSum) ...
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: akshar bhosale<akshar.bhosale at gmail.com>
>>> Date: Thu, Nov 3, 2011 at 8:00 AM
>>> Subject: Re: [Numpy-discussion] numpy error with mkl 10.1
>>> To: Discussion of Numerical Python<numpy-discussion at scipy.org>
>>>
>>>
>>> hi,
>>> on your machine, is numpy.test passed?
>>>
>>>
>>> On Thu, Nov 3, 2011 at 6:54 AM, Olivier Delalleau<shish at keba.be> wrote:
>>>
>>>> I believe they are optional, but I'm not sure.
>>>>
>>>> Note that this system I copied the distutils from is not one I setup
>>>> myself so I'm not sure how numpy was installed exactly. I just know it
>>>> works and it's using MKL :) It's an 8 core Intel(R) Xeon(R) CPU E5462 @
>>>> 2.80GHz (x86_64 as well).
>>>>
>>>> -=- Olivier
>>>>
>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>
>>>>> hi,
>>>>> are amd,fftw and umfpack required? my architecture is : intel xeon
>>>>> x_86_64.
>>>>>
>>>>> On Thu, Nov 3, 2011 at 6:30 AM, Olivier Delalleau<shish at keba.be>wrote:
>>>>>
>>>>>> It's inside the distutils folder.
>>>>>>
>>>>>> -=- Olivier
>>>>>>
>>>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>>>
>>>>>>> thanks..what about site.cfg?
>>>>>>>
>>>>>>> On Thu, Nov 3, 2011 at 1:27 AM, Olivier Delalleau<shish at keba.be>wrote:
>>>>>>>
>>>>>>>> Sorry, no clue :/
>>>>>>>>
>>>>>>>> I made a tarball with my distutils folder here:
>>>>>>>> http://www.iro.umontreal.ca/~delallea/tmp/distutils.tar.bz2
>>>>>>>> Hope this helps...
>>>>>>>>
>>>>>>>> -=- Olivier
>>>>>>>>
>>>>>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>>>>>
>>>>>>>>> hi,
>>>>>>>>> thanks for the reply
>>>>>>>>> none of them is linked with libmkl_lapack.so.
>>>>>>>>> what can be the problem?
>>>>>>>>> libmkl_lapack.so is present in its location.
>>>>>>>>>
>>>>>>>>> if possible, can you send your site.cfg and other related files
>>>>>>>>> like intelccompilers.py / system_config.py etc...and configure/build
>>>>>>>>> options, i will try the same?
>>>>>>>>>
>>>>>>>>> On Wed, Nov 2, 2011 at 11:51 PM, Olivier Delalleau<shish at keba.be>wrote:
>>>>>>>>>
>>>>>>>>>> Hmm that's interesting, it's not linked against libmkl_lapack. On
>>>>>>>>>> my system with MKL it says:
>>>>>>>>>>
>>>>>>>>>> ldd linalg/lapack_lite.so
>>>>>>>>>> libmkl_lapack.so => /opt/intel/mkl/*MailScanner soup?onne
>>>>>>>>>> le lien suivant d'?tre une tentative de fraude de la part de "10.1.3.027"
>>>>>>>>>> * *MailScanner soup?onne le lien suivant d'?tre une tentative de
>>>>>>>>>> fraude de la part de "10.1.3.027" MailScanner soup?onne le lien
>>>>>>>>>> suivant d'?tre une tentative de fraude de la part de "10.1.3.027" MailScanner
>>>>>>>>>> warning: numerical links are often malicious:
>>>>>>>>>> 10.1.3.027/lib/em64t/libmkl_lapack.so*<http://10.1.3.027/lib/em64t/libmkl_lapack.so>(0x00002acf0e25a000)
>>>>>>>>>> libmkl_intel_lp64.so => /opt/intel/mkl/*MailScanner
>>>>>>>>>> soup?onne le lien suivant d'?tre une tentative de fraude de la part de
>>>>>>>>>> "10.1.3.027" * *MailScanner soup?onne le lien suivant d'?tre une
>>>>>>>>>> tentative de fraude de la part de "10.1.3.027" MailScanner
>>>>>>>>>> soup?onne le lien suivant d'?tre une tentative de fraude de la part de
>>>>>>>>>> "10.1.3.027" MailScanner warning: numerical links are often
>>>>>>>>>> malicious: 10.1.3.027/lib/em64t/libmkl_intel_lp64.so*<http://10.1.3.027/lib/em64t/libmkl_intel_lp64.so>(0x00002acf0ebb8000)
>>>>>>>>>> libmkl_intel_thread.so => /opt/intel/mkl/*MailScanner
>>>>>>>>>> soup?onne le lien suivant d'?tre une tentative de fraude de la part de
>>>>>>>>>> "10.1.3.027" * *MailScanner soup?onne le lien suivant d'?tre une
>>>>>>>>>> tentative de fraude de la part de "10.1.3.027" MailScanner
>>>>>>>>>> soup?onne le lien suivant d'?tre une tentative de fraude de la part de
>>>>>>>>>> "10.1.3.027" MailScanner warning: numerical links are often
>>>>>>>>>> malicious: 10.1.3.027/lib/em64t/libmkl_intel_thread.so*<http://10.1.3.027/lib/em64t/libmkl_intel_thread.so>(0x00002acf0ef2e000)
>>>>>>>>>> libmkl_def.so => /opt/intel/mkl/*MailScanner soup?onne le
>>>>>>>>>> lien suivant d'?tre une tentative de fraude de la part de "10.1.3.027"
>>>>>>>>>> * *MailScanner soup?onne le lien suivant d'?tre une tentative de
>>>>>>>>>> fraude de la part de "10.1.3.027" MailScanner soup?onne le lien
>>>>>>>>>> suivant d'?tre une tentative de fraude de la part de "10.1.3.027" MailScanner
>>>>>>>>>> warning: numerical links are often malicious:
>>>>>>>>>> 10.1.3.027/lib/em64t/libmkl_def.so*<http://10.1.3.027/lib/em64t/libmkl_def.so>(0x00002acf0fc93000)
>>>>>>>>>> libmkl_core.so => /opt/intel/mkl/*MailScanner soup?onne
>>>>>>>>>> le lien suivant d'?tre une tentative de fraude de la part de "10.1.3.027"
>>>>>>>>>> * *MailScanner soup?onne le lien suivant d'?tre une tentative de
>>>>>>>>>> fraude de la part de "10.1.3.027" MailScanner soup?onne le lien
>>>>>>>>>> suivant d'?tre une tentative de fraude de la part de "10.1.3.027" MailScanner
>>>>>>>>>> warning: numerical links are often malicious:
>>>>>>>>>> 10.1.3.027/lib/em64t/libmkl_core.so*<http://10.1.3.027/lib/em64t/libmkl_core.so>(0x00002acf1080e000)
>>>>>>>>>>
>>>>>>>>>> libguide.so => /opt/intel/cce/10.1.026/lib/libguide.so
>>>>>>>>>> (0x00002acf10a03000)
>>>>>>>>>> libpthread.so.0 => /lib64/libpthread.so.0
>>>>>>>>>> (0x00002acf10ba6000)
>>>>>>>>>> libm.so.6 => /lib64/libm.so.6 (0x00002acf10dc1000)
>>>>>>>>>> libpython2.6.so.1.0 =>
>>>>>>>>>> /opt/python64/2.6.4/lib/libpython2.6.so.1.0 (0x00002acf11044000)
>>>>>>>>>> libc.so.6 => /lib64/libc.so.6 (0x00002acf113f3000)
>>>>>>>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00002acf1174b000)
>>>>>>>>>> /lib64/ld-linux-x86-64.so.2 (0x0000003d90400000)
>>>>>>>>>> libutil.so.1 => /lib64/libutil.so.1 (0x00002acf1194f000)
>>>>>>>>>>
>>>>>>>>>> So to clarify, what I was trying to achieve is find which of
>>>>>>>>>> numpy's shared libraries was trying to load libmkl_lapack.so, and if it
>>>>>>>>>> could be found properly with ldd. Just to make sure it's not another .so,
>>>>>>>>>> can you run from within your numpy directory:
>>>>>>>>>> find -name "*.so" -exec ldd \{} \; | grep lapack
>>>>>>>>>>
>>>>>>>>>> If the output is not empty, try to run ldd on all .so within numpy
>>>>>>>>>> to see which one is linked against libmkl_lapack.so. Then hopefully
>>>>>>>>>> something will stand out (I admit that's not guaranteed though ;).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -=- Olivier
>>>>>>>>>>
>>>>>>>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> ldd
>>>>>>>>>>> Python-2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so
>>>>>>>>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6
>>>>>>>>>>> (0x00002b1199349000)
>>>>>>>>>>> libmkl_def.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_def.so
>>>>>>>>>>> (0x00002b1199653000)
>>>>>>>>>>> libmkl_intel_lp64.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_intel_lp64.so
>>>>>>>>>>> (0x00002b119a1a8000)
>>>>>>>>>>> libmkl_intel_thread.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_intel_thread.so
>>>>>>>>>>> (0x00002b119a503000)
>>>>>>>>>>> libmkl_core.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_core.so
>>>>>>>>>>> (0x00002b119b22c000)
>>>>>>>>>>> libmkl_mc.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_mc.so (0x00002b119b420000)
>>>>>>>>>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b119c176000)
>>>>>>>>>>> libimf.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libimf.so (0x00002b119c392000)
>>>>>>>>>>> libsvml.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libsvml.so (0x00002b119c6e9000)
>>>>>>>>>>> libm.so.6 => /lib64/libm.so.6 (0x00002b119c8a6000)
>>>>>>>>>>> libiomp5.so =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libiomp5.so (0x00002b119cb2b000)
>>>>>>>>>>> libintlc.so.5 =>
>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libintlc.so.5 (0x00002b119ccbc000)
>>>>>>>>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b119cdf9000)
>>>>>>>>>>> libc.so.6 => /lib64/libc.so.6 (0x00002b119d007000)
>>>>>>>>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00002b119d37e000)
>>>>>>>>>>> /lib64/ld-linux-x86-64.so.2 (0x0000003fb8000000)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 2, 2011 at 11:26 PM, Olivier Delalleau<shish at keba.be
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> Doh I'm sorry, I forgot the problem was with lapack, what about
>>>>>>>>>>>> ldd numpy/linalg/lapack_lite.so?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> ldd _dotblas.so
>>>>>>>>>>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b12f0692000)
>>>>>>>>>>>>> libmkl_def.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_def.so
>>>>>>>>>>>>> (0x00002b12f099c000)
>>>>>>>>>>>>> libmkl_intel_lp64.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_intel_lp64.so
>>>>>>>>>>>>> (0x00002b12f14f1000)
>>>>>>>>>>>>> libmkl_intel_thread.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_intel_thread.so
>>>>>>>>>>>>> (0x00002b12f184c000)
>>>>>>>>>>>>> libmkl_core.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_core.so
>>>>>>>>>>>>> (0x00002b12f2575000)
>>>>>>>>>>>>> libmkl_mc.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_mc.so (0x00002b12f2769000)
>>>>>>>>>>>>> libpthread.so.0 => /lib64/libpthread.so.0
>>>>>>>>>>>>> (0x00002b12f34bf000)
>>>>>>>>>>>>> libimf.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libimf.so (0x00002b12f36db000)
>>>>>>>>>>>>> libsvml.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libsvml.so (0x00002b12f3a32000)
>>>>>>>>>>>>> libm.so.6 => /lib64/libm.so.6 (0x00002b12f3bef000)
>>>>>>>>>>>>> libiomp5.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libiomp5.so (0x00002b12f3e74000)
>>>>>>>>>>>>> libintlc.so.5 =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/lib/intel64/libintlc.so.5 (0x00002b12f4005000)
>>>>>>>>>>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b12f4142000)
>>>>>>>>>>>>> libc.so.6 => /lib64/libc.so.6 (0x00002b12f4350000)
>>>>>>>>>>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00002b12f46c7000)
>>>>>>>>>>>>> /lib64/ld-linux-x86-64.so.2 (0x0000003fb8000000)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Nov 2, 2011 at 10:14 PM, Olivier Delalleau<
>>>>>>>>>>>>> shish at keba.be> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, can you print the output of ldd numpy/core/_dotblas.so?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -=- Olivier
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HI,
>>>>>>>>>>>>>>> It is already added in the LD_LIBRARY_PATH, thenalso it is
>>>>>>>>>>>>>>> generating the same error.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Nov 2, 2011 at 10:01 PM, Olivier Delalleau<
>>>>>>>>>>>>>>> shish at keba.be> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Locate your libmkl_lapack.so and try to add the directory
>>>>>>>>>>>>>>>> that contains it to your LD_LIBRARY_PATH environment variable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -=- Olivier
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2011/11/2 akshar bhosale<akshar.bhosale at gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> i am getting following error.
>>>>>>>>>>>>>>>>> python -c 'import numpy;numpy.matrix([[1, 5, 10], [1.0,
>>>>>>>>>>>>>>>>> 3j, 4]],
>>>>>>>>>>>>>>>>> numpy.complex128).T.I.H'
>>>>>>>>>>>>>>>>> MKL FATAL ERROR: Cannot load libmkl_lapack.so
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> have installed numpy 1.6.0 with python 2.6.
>>>>>>>>>>>>>>>>> i have intel cluster toolkit installed on my system.
>>>>>>>>>>>>>>>>> (11/069 version and mlk=10.1). i have machine having intel xeon processor
>>>>>>>>>>>>>>>>> and rhel 5.2 x86_64
>>>>>>>>>>>>>>>>> platform.
>>>>>>>>>>>>>>>>> Kindly help
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> NumPy-Discussion mailing list
>>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> NumPy-Discussion mailing list
>>>>>>>> NumPy-Discussion at scipy.org
>>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> NumPy-Discussion mailing list
>>>>>>> NumPy-Discussion at scipy.org
>>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> NumPy-Discussion mailing list
>>>>>> NumPy-Discussion at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> NumPy-Discussion mailing list
>>>>> NumPy-Discussion at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>
>>>>>
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> NumPy-Discussion at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>
>>>>
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20111103/8b0cffc0/attachment.html
>
> ------------------------------
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> End of NumPy-Discussion Digest, Vol 62, Issue 15
> ************************************************
More information about the NumPy-Discussion
mailing list