On Friday, November 4, 2011, Nathaniel Smith wrote:
> On Thu, Nov 3, 2011 at 7:54 PM, Gary Strangman
> wrote:
>> For the non-destructive+propagating case, do I understand correctly that
>> this would mean I (as a user) could temporarily decide to IGNORE certain
>> portions of my data, perform a s
On Thu, Nov 3, 2011 at 7:54 PM, Gary Strangman
wrote:
> For the non-destructive+propagating case, do I understand correctly that
> this would mean I (as a user) could temporarily decide to IGNORE certain
> portions of my data, perform a series of computation on that data, and the
> IGNORED flag (o
On Thursday, November 3, 2011, Gary Strangman
wrote:
>
> For the non-destructive+propagating case, do I understand correctly that
> this would mean I (as a user) could temporarily decide to IGNORE certain
> portions of my data, perform a series of computation on that data, and the
> IGNORED flag (
For the non-destructive+propagating case, do I understand correctly that
this would mean I (as a user) could temporarily decide to IGNORE certain
portions of my data, perform a series of computation on that data, and the
IGNORED flag (or however it is implemented) would be propagated from
comp
Forgive me if this is already a well-know oddity of masked arrays. I hadn't
seen it before, though.
I'm not sure if this is exactly a bug, per se, but it's a very confusing
consequence of the current design of masked arrays...
Consider the following example:
import numpy as np
x = np.ma.masked_
Hi Lluís,
On Thu, Nov 3, 2011 at 7:28 AM, Lluís wrote:
> Well, maybe it's too low level, but I'd rather decouple the two concepts into
> two orthogonal properties that can be composed:
>
> * Destructiveness: whether the previous data value is lost whenever you
> assign a
> "special" value.
>
>
Hi Chris,
On Thu, Nov 3, 2011 at 9:45 AM, Chris.Barker wrote:
> On 11/2/11 7:16 PM, Nathaniel Smith wrote:
>> By R compatibility, I specifically had in mind in-memory
>> compatibility.
>
> The R crowd has had a big voice in this discussion, and I understand
> that there are some nice lessons to b
hi Olivier,
i will check that too. thanks for bearing me.
On Thu, Nov 3, 2011 at 7:48 PM, Olivier Delalleau wrote:
> Have you tried to use -O2 instead of -O3 in compilation? (been mentioned
> by someone else having the same issue).
>
> -=- Olivier
>
> 2011/11/3 akshar bhosale
>
>> Hi,
>> i am
On Thu, Nov 3, 2011 at 11:54 PM, akshar bhosale wrote:
> hi,
> extremely sorry for inconvenience caused. i will check with my system as
> directed. thank you for help.
>
> On Thu, Nov 3, 2011 at 7:12 PM, Bruce Southey wrote:
>
>> On 11/03/2011 04:27 AM, akshar bhosale wrote:
>> > Hi,
>> > i am us
hi,
extremely sorry for inconvenience caused. i will check with my system.
On Thu, Nov 3, 2011 at 7:12 PM, Bruce Southey wrote:
> On 11/03/2011 04:27 AM, akshar bhosale wrote:
> > Hi,
> > i am using mkl 10.1, intel cluster toolkit 11/069, os rhel 5.2 x86_64,
> > python 2.6, processor is intel xe
On 11/2/11 7:16 PM, Nathaniel Smith wrote:
> By R compatibility, I specifically had in mind in-memory
> compatibility.
The R crowd has had a big voice in this discussion, and I understand
that there are some nice lessons to be learned from it with regard to
the NA issues.
However, I think makin
On Thu, Nov 3, 2011 at 9:28 AM, Lluís wrote:
> Nathaniel Smith writes:
>
> > 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_
Nathaniel Smith writes:
> 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.)
Well, maybe it's too low le
Have you tried to use -O2 instead of -O3 in compilation? (been mentioned by
someone else having the same issue).
-=- Olivier
2011/11/3 akshar bhosale
> Hi,
> i am using mkl 10.1, intel cluster toolkit 11/069, os rhel 5.2 x86_64,
> python 2.6, processor is intel xeon
>
> numpy version is 1.6.0
>
On 11/03/2011 04:27 AM, akshar bhosale wrote:
> Hi,
> i am using mkl 10.1, intel cluster toolkit 11/069, os rhel 5.2 x86_64,
> python 2.6, processor is intel xeon
>
> numpy version is 1.6.0
>
> my numpy.test hanging at below point :
> Test whether equivalent subarray dtypes hash the same. ... ok
>
Hi,
i am using mkl 10.1, intel cluster toolkit 11/069, os rhel 5.2 x86_64,
python 2.6, processor is intel xeon
numpy version is 1.6.0
my numpy.test hanging at below point :
Test whether equivalent subarray dtypes hash the same. ... ok
Test whether different subarray dtypes hash differently. ... o
On Wed, Nov 2, 2011 at 10:33 PM, akshar bhosale
wrote:
> any other means of getting it fixed?
>
> -- Forwarded message --
> From: Olivier Delalleau
> Date: Thu, Nov 3, 2011 at 8:58 AM
> Subject: Re: [Numpy-discussion] Fwd: numpy error with mkl 10.1
> To: Discussion of Numerical Py
On 11/3/2011 5:36 AM, Pierre Raybaut wrote:
> * PySide support
Congratulations! I hope this means that Spyder
will be included in the Enthought Python Distribution
(so that I can have my students use it).
Alan Isaac
___
NumPy-Discussion mailing list
Hi all,
On the behalf of Spyder's development team
(http://code.google.com/p/spyderlib/people/list), I'm pleased to
announce that Spyder v2.1 has been released and is available for
Windows XP/Vista/7, GNU/Linux and MacOS X:
http://code.google.com/p/spyderlib/
Spyder is a free, open-source (MIT li
gt;>>>>>> libmkl_intel_lp64.so =>
>>>>>>>>>>>>> /opt/intel/Compiler/11.0/069/mkl/lib/em64t/libmkl_intel_lp64.so
>>>>>>>>>>>>> (0x2b12f14f1000)
>>>>>>>>>>>>> libmkl_i
20 matches
Mail list logo
