> It should be possible to remove a mask when copying an array.
>
This was a concession on the part of those pushing for masks. Eventually, I
ended up realizing that it resulted in a stronger design.
Consider the following:
foo(a[4:10])
Should function foo be able to access the rest of array "
There is a way to assign whole masks in the current implementation:
>>> a = np.arange(9, maskna=True).reshape((3,3))
>>> a
array([[0, 1, 2],
[3, 4, 5],
[6, 7, 8]])
>>> mask = np.array([[False, False, True],
[False, True, False],
On Thursday, October 27, 2011, Charles R Harris
wrote:
>
>
> On Thu, Oct 27, 2011 at 7:16 PM, Travis Oliphant
wrote:
>>
>> That is a pretty good explanation. I find myself convinced by Matthew's
arguments.I think that being able to separate ABSENT from IGNORED is a
good idea. I also like
As I mentioned. I find the ability to separate an ABSENT idea from an IGNORED
idea convincing.In other words, I think distinguishing between masks and
bit-patterns is not just an implementation detail, but provides a useful
concept for multiple use-cases.
I understand exactly what it woul
On Thu, Oct 27, 2011 at 7:16 PM, Travis Oliphant wrote:
> That is a pretty good explanation. I find myself convinced by Matthew's
> arguments.I think that being able to separate ABSENT from IGNORED is a
> good idea. I also like being able to control SKIP and PROPAGATE (but I
> think the cu
That is a pretty good explanation. I find myself convinced by Matthew's
arguments.I think that being able to separate ABSENT from IGNORED is a good
idea. I also like being able to control SKIP and PROPAGATE (but I think the
current implementation allows this already).
What is the count
Hi,
On Tue, Oct 25, 2011 at 7:56 PM, Travis Oliphant wrote:
> So, I am very interested in making sure I remember the details of the
> counterproposal. What I recall is that you wanted to be able to
> differentiate between a "bit-pattern" mask and a boolean-array mask in the
> API. I belie
On Thu, Oct 27, 2011 at 5:18 PM, wrote:
> On Thu, Oct 27, 2011 at 9:02 AM, David Cournapeau wrote:
>> Hi,
>>
>> I was wondering if we could finally move to a more recent version of
>> compilers for official win32 installers. This would of course concern
>> the next release cycle, not the ones wh
Hi David,
On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau wrote:
> Hi,
>
> I was wondering if we could finally move to a more recent version of
> compilers for official win32 installers. This would of course concern
> the next release cycle, not the ones where beta/rc are already in
> progress.
On Thu, Oct 27, 2011 at 9:02 AM, David Cournapeau wrote:
> Hi,
>
> I was wondering if we could finally move to a more recent version of
> compilers for official win32 installers. This would of course concern
> the next release cycle, not the ones where beta/rc are already in
> progress.
>
> Basica
On Thu, Oct 27, 2011 at 3:15 PM, Jim Vickroy wrote:
>
> Hi David,
>
> What is the "msvcr90 vodoo" you are referring to?
gcc 3.* versions don't have stubs to link against recent versions of
MS C runtime, so we have to build them by ourselves. 4.x series don't
have this issue,
cheers,
David
On 10/27/2011 7:02 AM, David Cournapeau wrote:
> Hi,
>
> I was wondering if we could finally move to a more recent version of
> compilers for official win32 installers. This would of course concern
> the next release cycle, not the ones where beta/rc are already in
> progress.
>
> Basically, the pr
On Thu, Oct 27, 2011 at 2:16 PM, Peter
wrote:
> On Thu, Oct 27, 2011 at 2:02 PM, David Cournapeau wrote:
>>
>> Hi,
>>
>> I was wondering if we could finally move to a more recent version of
>> compilers for official win32 installers. This would of course concern
>> the next release cycle, not the
On Thu, Oct 27, 2011 at 2:02 PM, David Cournapeau wrote:
>
> Hi,
>
> I was wondering if we could finally move to a more recent version of
> compilers for official win32 installers. This would of course concern
> the next release cycle, not the ones where beta/rc are already in
> progress.
>
> Basi
Hi,
I was wondering if we could finally move to a more recent version of
compilers for official win32 installers. This would of course concern
the next release cycle, not the ones where beta/rc are already in
progress.
Basically, the pros:
- we will have to move at some point
- gcc 4.* seem l
15 matches
Mail list logo