On 07/06/2011 07:51 PM, Chris Barker wrote:
> On 7/6/11 11:57 AM, Mark Wiebe wrote:
>> On Wed, Jul 6, 2011 at 1:25 PM, Christopher Barker
>
>> Is this really true? if you use a bitpattern for IGNORE, haven't you
>> just lost the ability to get the original value back if you want to stop
>
On 7/6/11 11:57 AM, Mark Wiebe wrote:
> On Wed, Jul 6, 2011 at 1:25 PM, Christopher Barker
> Is this really true? if you use a bitpattern for IGNORE, haven't you
> just lost the ability to get the original value back if you want to stop
> ignoring it? Maybe that's not inherent to what
On Wed, Jul 6, 2011 at 7:34 PM, Charles R Harris
wrote:
>
>
> On Wed, Jul 6, 2011 at 8:09 PM, Nathaniel Smith wrote:
>>
>> On Wed, Jul 6, 2011 at 7:01 PM, Charles R Harris
>> wrote:
>> >> Numpy already has a general mechanism for defining new dtypes and
>> >> slotting them in so that they're sup
On Wed, Jul 6, 2011 at 8:34 PM, Charles R Harris
wrote:
>
>
> On Wed, Jul 6, 2011 at 8:09 PM, Nathaniel Smith wrote:
>
>> On Wed, Jul 6, 2011 at 7:01 PM, Charles R Harris
>> wrote:
>> >> Numpy already has a general mechanism for defining new dtypes and
>> >> slotting them in so that they're supp
On Wed, Jul 6, 2011 at 8:09 PM, Nathaniel Smith wrote:
> On Wed, Jul 6, 2011 at 7:01 PM, Charles R Harris
> wrote:
> >> Numpy already has a general mechanism for defining new dtypes and
> >> slotting them in so that they're supported by ndarrays, by the casting
> >> machinery, by ufuncs, and so
On Wed, Jul 6, 2011 at 7:01 PM, Charles R Harris
wrote:
>> Numpy already has a general mechanism for defining new dtypes and
>> slotting them in so that they're supported by ndarrays, by the casting
>> machinery, by ufuncs, and so on. In principle, we could implement
>
> Well, actually not in any
On Wed, Jul 6, 2011 at 7:34 PM, Nathaniel Smith wrote:
> Well, everyone seems to like my first attempt at this so far, so I
> guess I'll really stick my foot in it now... here's my second miniNEP,
> which lays out a plan for handling dtype/bit-pattern-style NAs. I've
> stolen bits of text from bo
On Wed, Jul 6, 2011 at 7:14 PM, Christopher Jordan-Squire
wrote:
> On Wed, Jul 6, 2011 at 3:47 PM, wrote:
>> On Wed, Jul 6, 2011 at 4:38 PM, wrote:
>> > On Wed, Jul 6, 2011 at 4:22 PM, Christopher Jordan-Squire
>> >> Mean value replacement, or more generally single scalar value
>> >> replaceme
Well, everyone seems to like my first attempt at this so far, so I
guess I'll really stick my foot in it now... here's my second miniNEP,
which lays out a plan for handling dtype/bit-pattern-style NAs. I've
stolen bits of text from both the NEP and the alterNEP for this, but
since the focus is on n
On Wed, Jul 6, 2011 at 5:41 PM, Lluís wrote:
> Sorry, but I didn't find a way of inserting inline comments in the gist.
I'm a little confused about how gists work, actually. For actual
discussion, it's probably just as well, since this way everyone sees
the comment on the list and has a chance to
Mark Wiebe writes:
> On Wed, Jul 6, 2011 at 12:41 PM, Pierre GM wrote:
> Ah, semantics...
> On Jul 6, 2011, at 5:40 PM, Mark Wiebe wrote:
>>
>> NA (Not Available)
>> A placeholder for a value which is unknown to computations. That
>> value may be temporarily hidden with a mask,
(snip discussion of open kimono)
> On the other hand, to try and conceal these implementation
> differences, seems to me to break my feeling for numpy arrays, and
> make me feel I have an object that is rather magic, that I don't fully
> understand, and for which clever stuff is going on, under th
On Wed, Jul 6, 2011 at 7:14 PM, Christopher Jordan-Squire
wrote:
>
>
> On Wed, Jul 6, 2011 at 3:47 PM, wrote:
>>
>> On Wed, Jul 6, 2011 at 4:38 PM, wrote:
>> > On Wed, Jul 6, 2011 at 4:22 PM, Christopher Jordan-Squire
>> > wrote:
>> >>
>> >>
>> >> On Wed, Jul 6, 2011 at 1:08 PM, wrote:
>> >>>
Sorry, but I didn't find a way of inserting inline comments in the gist.
Nathaniel Smith writes:
[...]
> Is there any less stupid-looking name than ``where1=`` and ``where2=``
> for the ``.outer`` operation? (For that matter, can ``.outer`` be
> applied to more than 2 arrays? The docs say it can't
Hi,
On Wed, Jul 6, 2011 at 7:10 PM, Christopher Jordan-Squire
wrote:
>
>
> On Wed, Jul 6, 2011 at 10:44 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Wed, Jul 6, 2011 at 6:11 PM, Benjamin Root wrote:
>> >
>> >
>> > On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >
On Wed, Jul 6, 2011 at 3:47 PM, wrote:
> On Wed, Jul 6, 2011 at 4:38 PM, wrote:
> > On Wed, Jul 6, 2011 at 4:22 PM, Christopher Jordan-Squire
> > wrote:
> >>
> >>
> >> On Wed, Jul 6, 2011 at 1:08 PM, wrote:
> >>>
> >>> On Wed, Jul 6, 2011 at 3:38 PM, Christopher Jordan-Squire
> >>> wrote:
>
On Wed, Jul 6, 2011 at 5:38 PM, Benjamin Root wrote:
> On Wednesday, July 6, 2011, Christopher Jordan-Squire
> wrote:
> >
> >
> > On Wed, Jul 6, 2011 at 5:03 PM, Benjamin Root wrote:
> >
> > On Wednesday, July 6, 2011, Dag Sverre Seljebotn
> > wrote:
> >> On 07/06/2011 08:25 PM, Christopher Ba
On Wednesday, July 6, 2011, Christopher Jordan-Squire wrote:
>
>
> On Wed, Jul 6, 2011 at 5:03 PM, Benjamin Root wrote:
>
> On Wednesday, July 6, 2011, Dag Sverre Seljebotn
> wrote:
>> On 07/06/2011 08:25 PM, Christopher Barker wrote:
>>> Mark Wiebe wrote:
1) NA vs IGNORE and bitpattern vs
On Wed, Jul 6, 2011 at 5:03 PM, Benjamin Root wrote:
> On Wednesday, July 6, 2011, Dag Sverre Seljebotn
> wrote:
> > On 07/06/2011 08:25 PM, Christopher Barker wrote:
> >> Mark Wiebe wrote:
> >>> 1) NA vs IGNORE and bitpattern vs mask are completely independent. Any
> >>> combination of NA as bi
I would like to call to the attention of the NumPy community the following call
for papers:
Second Symposium on Advances in Modeling and Analysis Using Python, 22–26
January 2012, New Orleans, Louisiana
The Second Symposium on Advances in Modeling and Analysis Using Python,
sponsored by t
On Wednesday, July 6, 2011, Dag Sverre Seljebotn
wrote:
> On 07/06/2011 08:25 PM, Christopher Barker wrote:
>> Mark Wiebe wrote:
>>> 1) NA vs IGNORE and bitpattern vs mask are completely independent. Any
>>> combination of NA as bitpattern, NA as mask, IGNORE as bitpattern, and
>>> IGNORE as mask
On Wednesday, July 6, 2011, Ralf Gommers wrote:
>
>
> On Mon, Jun 27, 2011 at 9:38 PM, Benjamin Root wrote:
>
> I found another empty input edge case. Somewhat recently, we fixed an issue
> with np.histogram() and empty inputs (so long as the bins are somehow known).
>
np.histogram([], bin
On 07/06/2011 03:37 PM, Pierre GM wrote:
> On Jul 6, 2011, at 10:11 PM, Bruce Southey wrote:
>
>> On 07/06/2011 02:38 PM, Christopher Jordan-Squire wrote:
>>>
>>> On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker
>>> wrote:
>>> Christopher Jordan-Squire wrote:
If we follow those rules for
On Wed, Jul 6, 2011 at 2:53 PM, Neal Becker wrote:
> Christopher Barker wrote:
>
> > Dag Sverre Seljebotn wrote:
> >> Here's an HPC perspective...:
> >
> >> At least I feel that the transparency of NumPy is a huge part of its
> >> current success. Many more than me spend half their time in C/Fort
On Wed, Jul 06, 2011 at 08:39:37PM +0200, Dag Sverre Seljebotn wrote:
> As for myself, I'll admit that I'll almost certainly continue with
> explicit masking without using any of the proposed NEPs -- I have to be
> extremely aware of the masks in the statistical methods I use.
My gut feeling is
On Mon, Jun 27, 2011 at 9:38 PM, Benjamin Root wrote:
> I found another empty input edge case. Somewhat recently, we fixed an
> issue with np.histogram() and empty inputs (so long as the bins are somehow
> known).
>
> >>> np.histogram([], bins=4)
> (array([0, 0, 0, 0]), array([ 0. , 0.25, 0.5
On Wed, Jul 06, 2011 at 12:26:24PM -0700, Nathaniel Smith wrote:
> A mini-NEP for the where= argument to ufuncs
I _love_ this proposal and it would probably be much more useful to me
than the different masked array proposal that are too focused on a
specific usage pattern to answer all my needs.
Christopher Barker wrote:
> Dag Sverre Seljebotn wrote:
>> Here's an HPC perspective...:
>
>> At least I feel that the transparency of NumPy is a huge part of its
>> current success. Many more than me spend half their time in C/Fortran
>> and half their time in Python.
>
> Absolutely -- and this
On Wed, Jul 6, 2011 at 4:38 PM, wrote:
> On Wed, Jul 6, 2011 at 4:22 PM, Christopher Jordan-Squire
> wrote:
>>
>>
>> On Wed, Jul 6, 2011 at 1:08 PM, wrote:
>>>
>>> On Wed, Jul 6, 2011 at 3:38 PM, Christopher Jordan-Squire
>>> wrote:
>>> >
>>> >
>>> > On Wed, Jul 6, 2011 at 11:38 AM, Christophe
On Wed, Jul 6, 2011 at 4:22 PM, Christopher Jordan-Squire
wrote:
>
>
> On Wed, Jul 6, 2011 at 1:08 PM, wrote:
>>
>> On Wed, Jul 6, 2011 at 3:38 PM, Christopher Jordan-Squire
>> wrote:
>> >
>> >
>> > On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker
>> >
>> > wrote:
>> >>
>> >> Christopher Jor
On Jul 6, 2011, at 10:11 PM, Bruce Southey wrote:
> On 07/06/2011 02:38 PM, Christopher Jordan-Squire wrote:
>>
>>
>> On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker
>> wrote:
>> Christopher Jordan-Squire wrote:
>> > If we follow those rules for IGNORE for all computations, we sometimes
>
On Wed, Jul 6, 2011 at 1:08 PM, wrote:
> On Wed, Jul 6, 2011 at 3:38 PM, Christopher Jordan-Squire
> wrote:
> >
> >
> > On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker <
> chris.bar...@noaa.gov>
> > wrote:
> >>
> >> Christopher Jordan-Squire wrote:
> >> > If we follow those rules for IGNORE
On 07/06/2011 02:38 PM, Christopher Jordan-Squire wrote:
On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker
mailto:chris.bar...@noaa.gov>> wrote:
Christopher Jordan-Squire wrote:
> If we follow those rules for IGNORE for all computations, we
sometimes
> get some weird output
On Wed, Jul 6, 2011 at 3:38 PM, Christopher Jordan-Squire
wrote:
>
>
> On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker
> wrote:
>>
>> Christopher Jordan-Squire wrote:
>> > If we follow those rules for IGNORE for all computations, we sometimes
>> > get some weird output. For example:
>> > [ [1
It'd be easier to follow if you just made changes/suggestions on github to
Mark's NEP directly. (You can checkout Mark's missing data branch to get the
NEP.) Then I'll be able to focus on the ways the suggestions differ or
compliment the current NEP.
-Chris Jordan-Squire
On Wed, Jul 6, 2011 at 12
On Wed, Jul 6, 2011 at 8:12 AM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
>
> I just commented on the "prevent direct API access to the masking array"
> part -- I'm hoping direct access by external code to the underlying
> implementation details will be allowed, at some point.
>
On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker
wrote:
> Christopher Jordan-Squire wrote:
> > If we follow those rules for IGNORE for all computations, we sometimes
> > get some weird output. For example:
> > [ [1, 2], [3, 4] ] * [ IGNORE, 7] = [ 15, 31 ]. (Where * is matrix
> > multiply and n
Here's the master copy:
https://gist.github.com/1068056
But for your commenting convenience, I'll include the current text here:
A mini-NEP for the where= argument to ufuncs
To try and make more progress
On Wed, Jul 6, 2011 at 2:20 PM, Nathaniel Smith wrote:
> So one thing that came up on the call yesterday is that there actually
> is a significant chunk of functionality that everyone seems to agree
> is useful, needed, and basically how it should work.
>
> This includes:
> -- the basic existenc
So one thing that came up on the call yesterday is that there actually
is a significant chunk of functionality that everyone seems to agree
is useful, needed, and basically how it should work.
This includes:
-- the basic existence and semantics for NA values (however this is
implemented)
-- th
On 07/06/2011 08:25 PM, Christopher Barker wrote:
> Mark Wiebe wrote:
>> 1) NA vs IGNORE and bitpattern vs mask are completely independent. Any
>> combination of NA as bitpattern, NA as mask, IGNORE as bitpattern, and
>> IGNORE as mask are reasonable.
>
> Is this really true? if you use a bitpatter
On Wed, Jul 6, 2011 at 1:25 PM, Christopher Barker wrote:
> Mark Wiebe wrote:
> > 1) NA vs IGNORE and bitpattern vs mask are completely independent. Any
> > combination of NA as bitpattern, NA as mask, IGNORE as bitpattern, and
> > IGNORE as mask are reasonable.
>
> Is this really true? if you use
On 7/6/2011 10:57 AM, Russell E. Owen wrote:
> In article
> ,
> Ralf Gommers wrote:
>
>> On Tue, Jul 5, 2011 at 11:41 PM, Russell E. Owen wrote:
>>
>>> In article,
>>> Ralf Gommers wrote:
>>>
https://sourceforge.net/projects/numpy/files/NumPy/1.6.1rc2/
>>>
>>> Will there be a Mac bina
On Wed, Jul 6, 2011 at 12:41 PM, Pierre GM wrote:
> Ah, semantics...
>
> On Jul 6, 2011, at 5:40 PM, Mark Wiebe wrote:
> >
> > NA (Not Available)
> > A placeholder for a value which is unknown to computations. That
> > value may be temporarily hidden with a mask, may have been lost
> >
On 07/06/2011 04:47 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 6, 2011 at 2:12 PM, Dag Sverre Seljebotn
> wrote:
>> I just commented on the "prevent direct API access to the masking array"
>> part -- I'm hoping direct access by external code to the underlying
>> implementation details will be
On Wed, Jul 6, 2011 at 11:38 AM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
> > It appears to me that one of the biggest reason some of us have been
> talking
> > past each other in the discussions is that different people have
> different
> > definitions for
On Wed, Jul 6, 2011 at 11:33 AM, Peter <
numpy-discuss...@maubp.freeserve.co.uk> wrote:
> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
> > It appears to me that one of the biggest reason some of us have been
> talking
> > past each other in the discussions is that different people have
> dif
On 07/06/2011 08:10 PM, Nathaniel Smith wrote:
> On Wed, Jul 6, 2011 at 6:12 AM, Dag Sverre Seljebotn
> wrote:
>> What I'm saying is that Mark's proposal is more flexible. Say for the
>> sake of the argument that I have two codes I need to interface with:
>>
>> - Library A is written in Fortran
Christopher Jordan-Squire wrote:
> If we follow those rules for IGNORE for all computations, we sometimes
> get some weird output. For example:
> [ [1, 2], [3, 4] ] * [ IGNORE, 7] = [ 15, 31 ]. (Where * is matrix
> multiply and not * with broadcasting.) Or should that sort of operation
> through
On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 6, 2011 at 5:48 PM, Peter
> wrote:
> > On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett
> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
> >>> It appears to me that one of the biggest reas
Mark Wiebe wrote:
> 1) NA vs IGNORE and bitpattern vs mask are completely independent. Any
> combination of NA as bitpattern, NA as mask, IGNORE as bitpattern, and
> IGNORE as mask are reasonable.
Is this really true? if you use a bitpattern for IGNORE, haven't you
just lost the ability to get
Dag Sverre Seljebotn wrote:
> Here's an HPC perspective...:
> At least I feel that the transparency of NumPy is a huge part of its
> current success. Many more than me spend half their time in C/Fortran
> and half their time in Python.
Absolutely -- and this point has been raised a couple times
On Wed, Jul 6, 2011 at 10:44 AM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 6, 2011 at 6:11 PM, Benjamin Root wrote:
> >
> >
> > On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jul 6, 2011 at 5:48 PM, Peter
> >> wrote:
> >> > On Wed, Jul 6, 2011 at 5:38
On Wed, Jul 6, 2011 at 6:12 AM, Dag Sverre Seljebotn
wrote:
> What I'm saying is that Mark's proposal is more flexible. Say for the
> sake of the argument that I have two codes I need to interface with:
>
> - Library A is written in Fortran and uses a seperate (explicit) mask
> array for NA
>
>
Hi,
On Wed, Jul 6, 2011 at 6:54 PM, Christopher Jordan-Squire
wrote:
>
>
> On Wed, Jul 6, 2011 at 5:05 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> Just for reference, I am using this as the latest version of the NEP -
>> I hope it's current:
>>
>>
>> https://github.com/m-paradox/numpy/blob/7b10c9
Christopher Jordan-Squire wrote:
> Here's a short-ish summary of the topics discussed in the conference
> call this afternoon.
Thanks, this is great! And thanks to all who participated in the call.
> 3. Using IGNORE to signal a jagged array. e.g., [ [1, 2, IGNORE],
> [IGNORE, 3, 4] ] should beh
In article
,
Ralf Gommers wrote:
> On Tue, Jul 5, 2011 at 11:41 PM, Russell E. Owen wrote:
>
> > In article ,
> > Ralf Gommers wrote:
> >
> > > https://sourceforge.net/projects/numpy/files/NumPy/1.6.1rc2/
> >
> > Will there be a Mac binary for 32-bit pythons (one that is compatible
> > with
On Wed, Jul 6, 2011 at 5:05 AM, Matthew Brett wrote:
> Hi,
>
> Just for reference, I am using this as the latest version of the NEP -
> I hope it's current:
>
>
> https://github.com/m-paradox/numpy/blob/7b10c9ab1616b9100e98dd2ab80cef639d5b5735/doc/neps/missing-data.rst
>
> I'm mostly relaying stuf
Hi,
On Wed, Jul 6, 2011 at 6:11 PM, Benjamin Root wrote:
>
>
> On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Wed, Jul 6, 2011 at 5:48 PM, Peter
>> wrote:
>> > On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Wed, Jul 6, 2011
Ah, semantics...
On Jul 6, 2011, at 5:40 PM, Mark Wiebe wrote:
>
> NA (Not Available)
> A placeholder for a value which is unknown to computations. That
> value may be temporarily hidden with a mask, may have been lost
> due to hard drive corruption, or gone for any number of reasons
On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jul 6, 2011 at 5:48 PM, Peter
> wrote:
> > On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett
> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
> >>> It appears to me that one of the biggest reas
Hi,
On Wed, Jul 6, 2011 at 5:48 PM, Peter
wrote:
> On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
>>> It appears to me that one of the biggest reason some of us have been talking
>>> past each other in the discussions is th
On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett wrote:
>
> Hi,
>
> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
>> It appears to me that one of the biggest reason some of us have been talking
>> past each other in the discussions is that different people have different
>> definitions for the t
Hi,
On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
> It appears to me that one of the biggest reason some of us have been talking
> past each other in the discussions is that different people have different
> definitions for the terms being used. Until this is thoroughly cleared up, I
> feel t
On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe wrote:
> It appears to me that one of the biggest reason some of us have been talking
> past each other in the discussions is that different people have different
> definitions for the terms being used. Until this is thoroughly cleared up, I
> feel the de
It appears to me that one of the biggest reason some of us have been talking
past each other in the discussions is that different people have different
definitions for the terms being used. Until this is thoroughly cleared up, I
feel the design process is tilting at windmills.
In the interests of
Hi,
On Wed, Jul 6, 2011 at 2:12 PM, Dag Sverre Seljebotn
wrote:
> On 07/06/2011 02:46 PM, Matthew Brett wrote:
>> Hi,
>>
>> Sorry, I hope you don't mind, I moved this to it's own thread, trying
>> to separate comments on the NA debate from the discussion yesterday.
>
> I'm sorry.
>
>> On Wed, Jul
On 07/06/2011 02:46 PM, Matthew Brett wrote:
> Hi,
>
> Sorry, I hope you don't mind, I moved this to it's own thread, trying
> to separate comments on the NA debate from the discussion yesterday.
I'm sorry.
> On Wed, Jul 6, 2011 at 1:27 PM, Dag Sverre Seljebotn
> wrote:
>> On 07/06/2011 02:05 P
Hi,
Sorry, I hope you don't mind, I moved this to it's own thread, trying
to separate comments on the NA debate from the discussion yesterday.
On Wed, Jul 6, 2011 at 1:27 PM, Dag Sverre Seljebotn
wrote:
> On 07/06/2011 02:05 PM, Matthew Brett wrote:
>> Hi,
>>
>> Just for reference, I am using th
On 07/06/2011 02:27 PM, Dag Sverre Seljebotn wrote:
> On 07/06/2011 02:05 PM, Matthew Brett wrote:
>> Hi,
>>
>> Just for reference, I am using this as the latest version of the NEP -
>> I hope it's current:
>>
>> https://github.com/m-paradox/numpy/blob/7b10c9ab1616b9100e98dd2ab80cef639d5b5735/doc/n
On 07/06/2011 02:05 PM, Matthew Brett wrote:
> Hi,
>
> Just for reference, I am using this as the latest version of the NEP -
> I hope it's current:
>
> https://github.com/m-paradox/numpy/blob/7b10c9ab1616b9100e98dd2ab80cef639d5b5735/doc/neps/missing-data.rst
>
> I'm mostly relaying stuff I said, a
Hi,
Just for reference, I am using this as the latest version of the NEP -
I hope it's current:
https://github.com/m-paradox/numpy/blob/7b10c9ab1616b9100e98dd2ab80cef639d5b5735/doc/neps/missing-data.rst
I'm mostly relaying stuff I said, although generally (please do
correct me if I am wrong) I a
On Fri, Jul 1, 2011 at 7:23 PM, Sturla Molden wrote:
>
> 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 year
Pierre GM gmail.com> writes:
>
>
> Hello,
> The idea behin having a lib.recfunctions and not a rec.recfunctions or
whatever was to illustrate that the
> functions of this package are more generic than they appear. They work with
regular structured ndarrays
> and don't need recarrays. Methinks we
74 matches
Mail list logo
