On 07/01/2011 06:40 PM, Nathaniel Smith wrote:
> On Fri, Jul 1, 2011 at 9:29 AM, Christopher Jordan-Squire
> BTW, you can't access the memory of a masked value by taking a view,
> at least if I'm reading this version of the NEP correctly, and it
> seems to be the latest:
>
> https://github.com
On Fri, Jul 1, 2011 at 9:29 AM, Christopher Jordan-Squire
wrote:
> This is kind of late to be jumping into the 'long thread of doom', but I've
> been following most of the posts, so I'd figured I'd throw in my 2 cents.
> I'm Mark's officemate over the summer, and we've been talking daily about
> h
On Fri, Jul 1, 2011 at 9:29 AM, Benjamin Root wrote:
> On Fri, Jul 1, 2011 at 11:20 AM, Matthew Brett
> wrote:
>> On Fri, Jul 1, 2011 at 5:17 PM, Benjamin Root wrote:
>> > For more complicated functions like pcolor() and contour(), the arrays
>> > needs
>> > to know what the status of the neighb
On Fri, Jul 1, 2011 at 9:18 AM, Bruce Southey wrote:
> I am sorry that that is NOT true - DON'T just lump every one into this
> when they have clearly stated the opposite! Missing values are nothing
> special to me, just reality. There are many statistical applications
> where masking is extremely
On Fri, Jul 1, 2011 at 6:38 PM, Thomas K Gamble wrote:
> > On Thu, Jun 30, 2011 at 11:32 AM, Thomas K Gamble
> >
> > wrote:
> > > I'm trying to convert some IDL code to python/numpy and i'm having some
> > > trouble understanding the rules for boradcasting during some
> operations.
> > > example:
> On Thu, Jun 30, 2011 at 11:32 AM, Thomas K Gamble
>
> wrote:
> > I'm trying to convert some IDL code to python/numpy and i'm having some
> > trouble understanding the rules for boradcasting during some operations.
> > example:
> >
> > given the following arrays:
> > a = array((2048,3577), dtype
On Fri, Jul 1, 2011 at 2:04 PM, Pierre GM wrote:
> Mask an array with NAs? You should be able to, as IGNORE<>NA. Mask an array
> with a view? That's sharing the data with a different mask, you should be
> able to, too (np.ma works like that).
I think you might be getting the proposals mixed up...
Hi,
I am pleased to announce the availability (only a little later than planned)
of the second release candidate of NumPy 1.6.1. This is a bugfix release,
list of fixed bugs:
#1834 einsum fails for specific shapes
#1837 einsum throws nan or freezes python for specific array shapes
#1838 obje
On Fri, Jul 1, 2011 at 2:29 PM, Joe Harrington wrote:
> Mark Wiebe :
>
> > With a non-boolean alpha mask, there's an implication of a
> > multiplication operator in there somewhere, but with a boolean mask,
> > the data can be any data whatsoever that doesn't necessarily support
> > any kind of b
On Fri, Jul 1, 2011 at 3:07 PM, Eric Firing wrote:
> On 07/01/2011 10:27 AM, Charles R Harris wrote:
> >
> >
> > On Fri, Jul 1, 2011 at 1:39 PM, Christopher Barker
> > mailto:chris.bar...@noaa.gov>> wrote:
> >
> > Joe Harrington wrote:
> > > All
> > > that has to happen is to allow
On Fri, Jul 1, 2011 at 3:04 PM, Pierre GM wrote:
> Mask an array with NAs? You should be able to, as IGNORE<>NA. Mask an array
> with a view? That's sharing the data with a different mask,
>
I was thinking about a mask on top of a mask, i.e., start with a bare array,
take a masked view of that,
On 07/01/2011 10:27 AM, Charles R Harris wrote:
>
>
> On Fri, Jul 1, 2011 at 1:39 PM, Christopher Barker
> mailto:chris.bar...@noaa.gov>> wrote:
>
> Joe Harrington wrote:
> > All
> > that has to happen is to allow the sense of the mask to be FALSE
> = the
> > data are bad, T
Mask an array with NAs? You should be able to, as IGNORE<>NA. Mask an array
with a view? That's sharing the data with a different mask, you should be
able to, too (np.ma works like that).
Sharing mask? That'd be great if we could... That way, there'd be almost
nothing left to do to adapt np.ma...
O
On Fri, Jul 1, 2011 at 2:42 PM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 3:36 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 1, 2011 at 2:33 PM, Mark Wiebe wrote:
>>
>>> On Fri, Jul 1, 2011 at 3:29 PM, Charles R Harris <
>>> charlesr.har...@gmail.com> wrote:
On Fri, Jul 1, 2011 at 3:36 PM, Charles R Harris
wrote:
>
>
> On Fri, Jul 1, 2011 at 2:33 PM, Mark Wiebe wrote:
>
>> On Fri, Jul 1, 2011 at 3:29 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Jul 1, 2011 at 2:26 PM, Mark Wiebe wrote:
>>>
On Fri, Jul 1, 20
On Fri, Jul 1, 2011 at 2:33 PM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 3:29 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 1, 2011 at 2:26 PM, Mark Wiebe wrote:
>>
>>> On Fri, Jul 1, 2011 at 3:20 PM, Mark Wiebe wrote:
>>>
On Fri, Jul 1, 2011 at 3:01 P
On Fri, Jul 1, 2011 at 3:32 PM, Charles R Harris
wrote:
> On Fri, Jul 1, 2011 at 1:46 PM, Dag Sverre Seljebotn <
> d.s.seljeb...@astro.uio.no> wrote:
>
>> I propose a simple idea *for the long term* for generalizing Mark's
>> proposal, that I hope may perhaps put some people behind Mark's concrete
On Fri, Jul 1, 2011 at 3:29 PM, Charles R Harris
wrote:
>
>
> On Fri, Jul 1, 2011 at 2:26 PM, Mark Wiebe wrote:
>
>> On Fri, Jul 1, 2011 at 3:20 PM, Mark Wiebe wrote:
>>
>>> On Fri, Jul 1, 2011 at 3:01 PM, Skipper Seabold wrote:
>>>
On Fri, Jul 1, 2011 at 3:46 PM, Dag Sverre Seljebotn
On Fri, Jul 1, 2011 at 1:46 PM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
> I propose a simple idea *for the long term* for generalizing Mark's
> proposal, that I hope may perhaps put some people behind Mark's concrete
> proposal in the short term.
>
> If key feature missing in Mar
On Fri, Jul 1, 2011 at 2:26 PM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 3:20 PM, Mark Wiebe wrote:
>
>> On Fri, Jul 1, 2011 at 3:01 PM, Skipper Seabold wrote:
>>
>>> On Fri, Jul 1, 2011 at 3:46 PM, Dag Sverre Seljebotn
>>> wrote:
>>> > I propose a simple idea *for the long term* for generali
On Fri, Jul 1, 2011 at 1:39 PM, Christopher Barker wrote:
> Joe Harrington wrote:
> > All
> > that has to happen is to allow the sense of the mask to be FALSE = the
> > data are bad, TRUE = the data are good, and allow (not require) the
> > mask to be of any numerical type, or at least of integer
On Fri, Jul 1, 2011 at 3:20 PM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 3:01 PM, Skipper Seabold wrote:
>
>> On Fri, Jul 1, 2011 at 3:46 PM, Dag Sverre Seljebotn
>> wrote:
>> > I propose a simple idea *for the long term* for generalizing Mark's
>> > proposal, that I hope may perhaps put some
On Fri, Jul 1, 2011 at 3:01 PM, Skipper Seabold wrote:
> On Fri, Jul 1, 2011 at 3:46 PM, Dag Sverre Seljebotn
> wrote:
> > I propose a simple idea *for the long term* for generalizing Mark's
> > proposal, that I hope may perhaps put some people behind Mark's concrete
> > proposal in the short te
On Fri, Jul 1, 2011 at 3:01 PM, Benjamin Root wrote:
> On Fri, Jul 1, 2011 at 2:22 PM, Mark Wiebe wrote:
>
>> The missing data thread has gotten a bit heated, and after sitting down
>> with Travis to discuss the issues a bit, we've concluded that it would be
>> nice to do a call with everyone wh
On Fri, Jul 1, 2011 at 3:46 PM, Dag Sverre Seljebotn
wrote:
> I propose a simple idea *for the long term* for generalizing Mark's
> proposal, that I hope may perhaps put some people behind Mark's concrete
> proposal in the short term.
>
> If key feature missing in Mark's proposal is the ability to
On Fri, Jul 1, 2011 at 2:22 PM, Mark Wiebe wrote:
> The missing data thread has gotten a bit heated, and after sitting down
> with Travis to discuss the issues a bit, we've concluded that it would be
> nice to do a call with everyone who's interested in the discussion with
> better communication
I propose a simple idea *for the long term* for generalizing Mark's
proposal, that I hope may perhaps put some people behind Mark's concrete
proposal in the short term.
If key feature missing in Mark's proposal is the ability to distinguish
between different reason for NA-ness; IGNORE vs. NA. H
Joe Harrington wrote:
> All
> that has to happen is to allow the sense of the mask to be FALSE = the
> data are bad, TRUE = the data are good, and allow (not require) the
> mask to be of any numerical type, or at least of integer type as well
> as boolean.
quick note on this: I like the "FALSE =
Mark Wiebe :
> With a non-boolean alpha mask, there's an implication of a
> multiplication operator in there somewhere, but with a boolean mask,
> the data can be any data whatsoever that doesn't necessarily support
> any kind of blending operations.
My goal in raising the point is to find a comm
The missing data thread has gotten a bit heated, and after sitting down with
Travis to discuss the issues a bit, we've concluded that it would be nice to
do a call with everyone who's interested in the discussion with better
communication bandwidth. There are lots of good ideas out there, and it is
On Fri, Jul 1, 2011 at 3:05 PM, Benjamin Root wrote:
>
>
> On Fri, Jul 1, 2011 at 12:59 PM, Skipper Seabold
> wrote:
>>
>> lib.recfunctions has never been fully advertised. The two bugs I just
>> discovered lead me to believe that it's not that well vetted, but it
>> is useful. I can't be the onl
On Fri, Jul 1, 2011 at 12:59 PM, Skipper Seabold wrote:
> lib.recfunctions has never been fully advertised. The two bugs I just
> discovered lead me to believe that it's not that well vetted, but it
> is useful. I can't be the only one using these?
>
>
Nope, you aren't the only one. I use them in
On Fri, Jul 1, 2011 at 2:22 PM, wrote:
> On Fri, Jul 1, 2011 at 1:59 PM, Skipper Seabold wrote:
>> lib.recfunctions has never been fully advertised. The two bugs I just
>> discovered lead me to believe that it's not that well vetted, but it
>> is useful. I can't be the only one using these?
>>
>
Den 01.07.2011 19:22, skrev Charles R Harris:
> Just curious as to what folks know about the current status of the
> free windows 64 bit compilers. I know things were dicey with gcc and
> gfortran some two years ago, but... well, two years have passed. This
Windows 7 SDK is free (as in beer). It
On Fri, Jul 1, 2011 at 1:59 PM, Skipper Seabold wrote:
> lib.recfunctions has never been fully advertised. The two bugs I just
> discovered lead me to believe that it's not that well vetted, but it
> is useful. I can't be the only one using these?
>
> What do people think of either deprecating lib
On Jul 1, 2011 7:14 PM, "Mark Wiebe" wrote:
>
> On Fri, Jul 1, 2011 at 10:15 AM, Nathaniel Smith wrote:
>>
>> On Fri, Jul 1, 2011 at 7:09 AM, Mark Wiebe wrote:
>> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
>> > wrote:
>> >> Do you see problems with the alterNEP proposal?
>> >
>> > Yes, I r
lib.recfunctions has never been fully advertised. The two bugs I just
discovered lead me to believe that it's not that well vetted, but it
is useful. I can't be the only one using these?
What do people think of either deprecating lib.recfunctions or at
least importing them into the numpy.rec names
Nathaniel Smith writes:
> On Fri, Jul 1, 2011 at 7:09 AM, Mark Wiebe wrote:
>> On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
>> wrote:
>>> Do you see problems with the alterNEP proposal?
>>
>> Yes, I really like my design as it stands now, and the alterNEP removes a
>> lot of the abstraction an
Matthew Brett writes:
>>> > Mainly: Reduced interoperability
>>>
>>> Meaning?
>>
>> You can't switch between the two approaches without big changes in your
>> code.
> Lluis provided a case, and it was obscure. That switch seems like a
> rare or non-existent use-case that should not guide the AP
Just curious as to what folks know about the current status of the free
windows 64 bit compilers. I know things were dicey with gcc and gfortran
some two years ago, but... well, two years have passed. This
Chuck
___
NumPy-Discussion mailing list
NumPy-Di
On Fri, Jul 1, 2011 at 10:15 AM, Nathaniel Smith wrote:
> On Fri, Jul 1, 2011 at 7:09 AM, Mark Wiebe wrote:
> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
> > wrote:
> >> Do you see problems with the alterNEP proposal?
> >
> > Yes, I really like my design as it stands now, and the alterNEP r
This is kind of late to be jumping into the 'long thread of doom', but I've
been following most of the posts, so I'd figured I'd throw in my 2 cents.
I'm Mark's officemate over the summer, and we've been talking daily about
his design. I was skeptical of various details at first, but by now Mark's
On Fri, Jul 1, 2011 at 11:20 AM, Matthew Brett wrote:
> Hi,
>
> On Fri, Jul 1, 2011 at 5:17 PM, Benjamin Root wrote:
> >
> >
> > On Fri, Jul 1, 2011 at 11:00 AM, Matthew Brett
> > wrote:
> >>
> >> > You can't switch between the two approaches without big changes in
> your
> >> > code.
> >>
> >>
Hi,
On Fri, Jul 1, 2011 at 5:18 PM, Bruce Southey wrote:
> On 07/01/2011 10:15 AM, Nathaniel Smith wrote:
> I really find that you are 'splitting hairs' in your arguments as it
> really has to be up to the application on how missing values and NaN
> have to be handled. I see no difference betwee
Hi,
On Fri, Jul 1, 2011 at 5:17 PM, Benjamin Root wrote:
>
>
> On Fri, Jul 1, 2011 at 11:00 AM, Matthew Brett
> wrote:
>>
>> > You can't switch between the two approaches without big changes in your
>> > code.
>>
>> >
>> Lluis provided a case, and it was obscure. That switch seems like a
>> rar
On 07/01/2011 10:15 AM, Nathaniel Smith wrote:
> On Fri, Jul 1, 2011 at 7:09 AM, Mark Wiebe wrote:
>> On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
>> wrote:
>>> Do you see problems with the alterNEP proposal?
>> Yes, I really like my design as it stands now, and the alterNEP removes a
>> lot of t
Hi,
On Fri, Jul 1, 2011 at 5:15 PM, Charles R Harris
wrote:
>
>
> On Fri, Jul 1, 2011 at 10:00 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Fri, Jul 1, 2011 at 4:34 PM, Mark Wiebe wrote:
>> > On Fri, Jul 1, 2011 at 9:50 AM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Jul 1,
On Fri, Jul 1, 2011 at 11:00 AM, Matthew Brett wrote:
>
> > You can't switch between the two approaches without big changes in your
> > code.
>
> >
> Lluis provided a case, and it was obscure. That switch seems like a
> rare or non-existent use-case that should not guide the API.
>
>
Just to resp
On Fri, Jul 1, 2011 at 10:00 AM, Matthew Brett wrote:
> Hi,
>
> On Fri, Jul 1, 2011 at 4:34 PM, Mark Wiebe wrote:
> > On Fri, Jul 1, 2011 at 9:50 AM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe wrote:
> >> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew
Hi,
On Fri, Jul 1, 2011 at 4:48 PM, Charles R Harris
wrote:
>
>
> On Fri, Jul 1, 2011 at 9:34 AM, Mark Wiebe wrote:
>>
>> On Fri, Jul 1, 2011 at 9:50 AM, Matthew Brett
>> wrote:
>>>
>>> Hi,
>>>
>>> On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe wrote:
>>> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew
Hi,
On Fri, Jul 1, 2011 at 4:34 PM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 9:50 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe wrote:
>> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Jul 1, 2011 at 2:3
On Fri, Jul 1, 2011 at 9:34 AM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 9:50 AM, Matthew Brett wrote:
>
>> Hi,
>>
>> On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe wrote:
>> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Jul 1, 2011 at 2:36 AM, Ke
On Fri, Jul 1, 2011 at 9:50 AM, Matthew Brett wrote:
> Hi,
>
> On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe wrote:
> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Jul 1, 2011 at 2:36 AM, Keith Goodman
> wrote:
> >> > On Thu, Jun 30, 2011 at 10:51 AM, N
Matthew Brett wrote:
> should raise an error. On the other hand, if I make a normal array:
>
> arr = np.array([1.0, 2.0, 7.0])
>
> and then do this:
>
> arr.visible[2] = False
>
> then either I should raise an error (it's not a masked array), or,
> more magically, construct a mask on the fly.
static PyObject *
my_c_method(PyObject *self, PyObject *args) {
PyArrayObject *array;
double *points;
PyArg_ParseTuple(args, "O", &array);
points=(double*)array->data
printf("points[0] = %f \n",points[0]);
}
It is should be like that.
2011/7/1 Pauli Virtanen
> Hi,
>
> Fri, 01
On Fri, Jul 1, 2011 at 7:09 AM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
> wrote:
>> Do you see problems with the alterNEP proposal?
>
> Yes, I really like my design as it stands now, and the alterNEP removes a
> lot of the abstraction and interoperability that are in my
Hi,
Fri, 01 Jul 2011 16:45:47 +0200, Marc Labadens wrote:
> I am trying to interface some python code using numpy array with some C
> code.
You can read:
http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#writing-an-extension-module
However, using Cython often saves you from writing
Hi,
On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe wrote:
> On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Fri, Jul 1, 2011 at 2:36 AM, Keith Goodman wrote:
>> > On Thu, Jun 30, 2011 at 10:51 AM, Nathaniel Smith wrote:
>> >> On Thu, Jun 30, 2011 at 6:31 AM, Matthew Brett
Hello !
I am trying to interface some python code using numpy array with some C
code.
I have tried out this:
- - - - - - - - Python code - - - - - - - -
import numpy
a = numpy.array([1.4, 2.4, 3.6], dtype=float)
my_c_method(a) # call to the C code
- - - - - - - - C code - - - - - - - - - - -
On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett wrote:
> Hi,
>
> On Fri, Jul 1, 2011 at 2:36 AM, Keith Goodman wrote:
> > On Thu, Jun 30, 2011 at 10:51 AM, Nathaniel Smith wrote:
> >> On Thu, Jun 30, 2011 at 6:31 AM, Matthew Brett
> wrote:
> >>> In the interest of making the discussion as concret
On Thu, Jun 30, 2011 at 11:32 AM, Thomas K Gamble
wrote:
> I'm trying to convert some IDL code to python/numpy and i'm having some
> trouble understanding the rules for boradcasting during some operations.
> example:
>
> given the following arrays:
> a = array((2048,3577), dtype=float)
> b = array
On Fri, Jul 1, 2011 at 6:01 AM, Neal Becker wrote:
> Just trying it out with 1.6:
>
> np.datetime64('now')
> Out[6]: 2011-07-01 00:00:00
>
> Well the time now is 07:01am. Is this expected behaviour?
>
The version of datetime in 1.6 is quite broken. When 1.6 was released, I
thought it was proba
On Fri, Jul 1, 2011 at 5:01 AM, Neal Becker wrote:
> Just trying it out with 1.6:
>
> np.datetime64('now')
> Out[6]: 2011-07-01 00:00:00
>
> I get
In [1]: datetime64('now')
Out[1]: numpy.datetime64('2011-07-01T07:18:35-0600')
You need the development branch for trials, Mark has made a lot of
f
> On 30.06.2011, at 11:57PM, Thomas K Gamble wrote:
> >> np.add(b.reshape(2048,3136) * c, d, out=a[:,:3136])
> >>
> >> But to say whether this is really the equivalent result to what IDL
> >> does, one would have to study the IDL manual in detail or directly
> >> compare the output (e.g. check wha
>
> Right, I forgot to point out that there are at least 2 ways to bring the
> arrays into compatible shapes (that's the reason broadcasting does not
> work here, because numpy only does automatic broadcasting if there is an
> unambiguous way to do so). So the IDL arrays being Fortran-ordered is t
Hi,
On Fri, Jul 1, 2011 at 2:36 AM, Keith Goodman wrote:
> On Thu, Jun 30, 2011 at 10:51 AM, Nathaniel Smith wrote:
>> On Thu, Jun 30, 2011 at 6:31 AM, Matthew Brett
>> wrote:
>>> In the interest of making the discussion as concrete as possible, here
>>> is my draft of an alternative proposal
Just trying it out with 1.6:
np.datetime64('now')
Out[6]: 2011-07-01 00:00:00
Well the time now is 07:01am. Is this expected behaviour?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussi
67 matches
Mail list logo
