On Sat, Jul 19, 2008 at 21:51, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Robert,
>
> Is there any reason I shouldn't backport your build fixes?
Go ahead.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt
Robert,
Is there any reason I shouldn't backport your build fixes?
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Saturday 19 July 2008 18:41:22 Ryan May wrote:
> > There was a thread about this a couple months ago, and Pierre GM
> > explained it. I think the point was that indexing is giving you a new
> > masked scalar, which is therefore taking the default mask value of the
> > type. I don't see it as a
Eric Firing wrote:
> Ryan May wrote:
>> Hi,
>>
>> I just noticed this and found it surprising:
>>
>> In [8]: from numpy import ma
>>
>> In [9]: a = ma.array([1,2,3,4],mask=[False,False,True,False],fill_value=0)
>>
>> In [10]: a
>> Out[10]:
>> masked_array(data = [1 2 -- 4],
>>mask = [False
Ryan May wrote:
> Hi,
>
> I just noticed this and found it surprising:
>
> In [8]: from numpy import ma
>
> In [9]: a = ma.array([1,2,3,4],mask=[False,False,True,False],fill_value=0)
>
> In [10]: a
> Out[10]:
> masked_array(data = [1 2 -- 4],
>mask = [False False True False],
>
Hi,
I just noticed this and found it surprising:
In [8]: from numpy import ma
In [9]: a = ma.array([1,2,3,4],mask=[False,False,True,False],fill_value=0)
In [10]: a
Out[10]:
masked_array(data = [1 2 -- 4],
mask = [False False True False],
fill_value=0)
In [11]: a[2]
Out[11]:
mas
Memmap problems.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Pauli Virtanen wrote:
> Hi all,
>
> Re: Ticket 854.
>
> I wrote tests for the branch cuts for all complex arc* functions
> in umathmodule. It turns out that all except arccosh were OK.
> The formula for arcsinh was written in a non-standard form with
> an unnecessary nc_neg, but this didn't affect
Michael Abbott wrote:
>
> I'm not actually convinced by the comment that's there now, which says
> /* typecode will be NULL */
> but in truth it doesn't matter -- because of the correcly placed DECREF
> after the PyArray_Scalar calls the routine no longer owns typecode.
>
I'm pretty sure
Stéfan van der Walt wrote:
> 2008/7/19 Charles R Harris <[EMAIL PROTECTED]>:
>
>> In [2]: type(conjugate(array(8+7j)))
>> Out[2]:
>>
>> In [3]: type((array(8+7j)))
>> Out[3]:
>>
>> So I think all that needs to be done is fix the return type conjugate if we
>> agree that it should be an array.
On Sat, Jul 19, 2008 at 8:57 AM, Michael Abbott <[EMAIL PROTECTED]>
wrote:
> On Fri, 18 Jul 2008, Travis E. Oliphant wrote:
> > It looks like with that added DECREF, the reference count leak is gone.
>
> I've looked at the latest head, and I agree that the problem is now
> solved.
>
> There is an
On Sat, Jul 19, 2008 at 7:13 AM, Pauli Virtanen <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Re: Ticket 854.
>
I've backported the fixes to 1.1.x, so you had better commit these ;)
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://p
On Sat, Jul 19, 2008 at 7:13 AM, Pauli Virtanen <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Re: Ticket 854.
>
> I wrote tests for the branch cuts for all complex arc* functions
> in umathmodule. It turns out that all except arccosh were OK.
> The formula for arcsinh was written in a non-standard form
Accidental (virus?) post. Humblest apologies for the noise. Please ignore.
Gary
On Sat, 19 Jul 2008, Gary Strangman wrote:
> day pot-luck invite was a SHAM! The real party is on Saturday, and is not
> a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real
> party is on Saturday,
day pot-luck invite was a SHAM! The real party is on Saturday, and is not
a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real
party is on Saturday, and is not a pot-luck.Remember -- the Sunday
pot-luck invite was a SHAM! The real party is on Saturday, and is not a
pot-luck.Re
On Fri, Jul 18, 2008 at 3:37 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Since 1.1.1rc1 is coming out this Sunday, I'd like to know who is
> responsible for the OS X install improvements, if that is what they are. I
> don't know squat about them myself and don't run OS X.
Chris Burns has be
On Fri, 18 Jul 2008, Travis E. Oliphant wrote:
> It looks like with that added DECREF, the reference count leak is gone.
I've looked at the latest head, and I agree that the problem is now
solved.
There is an important difference from my original solution: typecode is no
longer reused after th
On Fri, Jul 18, 2008 at 8:32 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> That looks like a bug to me. I would have expected at least one of
> the following to work:
>
> A % [[1, 2], [3, 4]]
> A % 1
> A % (1, 2, 3, 4)
>
> and none of them do.
I wouldn't expect the last one to work, since
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex arc* functions
in umathmodule. It turns out that all except arccosh were OK.
The formula for arcsinh was written in a non-standard form with
an unnecessary nc_neg, but this didn't affect the results.
I also wrote tests for
2008/7/19 Charles R Harris <[EMAIL PROTECTED]>:
> In [2]: type(conjugate(array(8+7j)))
> Out[2]:
>
> In [3]: type((array(8+7j)))
> Out[3]:
>
> So I think all that needs to be done is fix the return type conjugate if we
> agree that it should be an array.
I think it should be an array.
Stéfan
__
20 matches
Mail list logo
