On Mon, 2008-05-12 at 00:39 -0600, Charles R Harris wrote:
>
> Which makes the spot where a gets initialized almost invisible. It is
> amazing how much easier the code is to read and understand with these
> simple changes. But if we plan tasks for the release, then we also
> have to assign peopl
Could we add a "from __future__ import something" along with a
deprecation warning?
This could be used for Tim's "new matrix" class, or any other API change.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600
On Mon, May 12, 2008 at 12:17 AM, Jarrod Millman <[EMAIL PROTECTED]>
wrote:
> On Sun, May 11, 2008 at 10:42 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > I dunno. I tend to agree with Mike Ressler that Numpy really shouldn't
> > change very quickly. We can add new features now and then, o
On Mon, May 12, 2008 at 12:43 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> On Sun, May 11, 2008 at 9:42 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> The semantics of major.minor.micro for numpy got confused because of
>> an early mistake (IMO) wherein we designated 1.1 as a release which
>> wou
On Sun, May 11, 2008 at 10:42 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> I dunno. I tend to agree with Mike Ressler that Numpy really shouldn't
> change very quickly. We can add new features now and then, or move more
> stuff to type specific functions, but those aren't really user visible.
On Mon, May 12, 2008 at 12:37 AM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
> 2008/5/11 Robert Kern <[EMAIL PROTECTED]>:
>
>> Perhaps, but ufuncs only allow 0 or 1 for this value, currently.
>
> That's a shame, minus infinity is the identity for maximum too.
>
>> Also, I was wrong about using PyUFu
On Sun, May 11, 2008 at 9:42 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> The semantics of major.minor.micro for numpy got confused because of
> an early mistake (IMO) wherein we designated 1.1 as a release which
> would allow code breakage.
I disagree. I didn't realize that the ma change was goi
On Sun, May 11, 2008 at 10:26 PM, Jarrod Millman <[EMAIL PROTECTED]>
wrote:
> On Sun, May 11, 2008 at 7:59 PM, David Cournapeau
> <[EMAIL PROTECTED]> wrote:
> >I would like to know how people feel about going toward a
> time-based
> > release process for numpy (and scipy). By time-based re
2008/5/11 Robert Kern <[EMAIL PROTECTED]>:
> Perhaps, but ufuncs only allow 0 or 1 for this value, currently.
That's a shame, minus infinity is the identity for maximum too.
> Also, I was wrong about using PyUFunc_ff_f. Instead, use PyUFunc_ff_f_As_dd_d.
Hmm. Well, I tried implementing logsum()
On Sun, May 11, 2008 at 9:42 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> My impression, but maybe I am missing something, is that the release
> slipped because everybody added new code. If we have a strict policy to
> say no new code, only bug fixes at least for 2 weeks before a release
> (an
On Sun, May 11, 2008 at 11:14 PM, Mike Ressler
<[EMAIL PROTECTED]> wrote:
> Numpy doesn't (and probably shouldn't) change that rapidly. I would
> really hope that the core numpy is solid, stable, and predictable. I
> like major and minor version numbers that indicate a major change is
> coming. If
On Sun, 2008-05-11 at 21:26 -0700, Jarrod Millman wrote:
>
> The one caveat to this is that you may recall I have tried to start
> having a 3 month release cycle ever since I took over release
> management last summer. I was almost able to do it for the first
> release of NumPy and SciPy. But si
On Sun, May 11, 2008 at 9:14 PM, Mike Ressler <[EMAIL PROTECTED]> wrote:
> I'm just a common user, but please, no. The big Linux distros do this
> and it drives me nuts. Just when things are finally beginning to
> settle down, they throw another big, buggy release out the door
> because they are tr
On Sun, 2008-05-11 at 21:14 -0700, Mike Ressler wrote:
>
> I'm just a common user, but please, no. The big Linux distros do this
> and it drives me nuts. Just when things are finally beginning to
> settle down, they throw another big, buggy release out the door
> because they are trying to meet s
On Sun, May 11, 2008 at 7:59 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
>I would like to know how people feel about going toward a time-based
> release process for numpy (and scipy). By time-based release, I mean:
>- releases of numpy are time-based, not feature based.
>
On Sun, May 11, 2008 at 7:59 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to know how people feel about going toward a time-based
> release process for numpy (and scipy).
-1
I'm just a common user, but please, no. The big Linux distros do this
and it drives me n
On Sun, May 11, 2008 at 7:59 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to know how people feel about going toward a time-based
> release process for numpy (and scipy). By time-based release, I mean:
> - releases of numpy are time-based, not feature base
On Sun, May 11, 2008 at 8:09 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sun, May 11, 2008 at 12:16 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > To be specific: I do not recall any place in the NumPy Book
> > where this behavior is promised.
>
> It's promised in the docstring!
>
> """ A
On Sun, May 11, 2008 at 12:16 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> To be specific: I do not recall any place in the NumPy Book
> where this behavior is promised.
It's promised in the docstring!
""" A matrix is a specialized 2-d array that retains
it's 2-d nature through operations
""
On Sun, May 11, 2008 at 9:50 PM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
> 2008/5/11 Robert Kern <[EMAIL PROTECTED]>:
>
>> Basically, you need 3 arrays: functions implementing the type-specific
>> inner loops, void* extra data to pass to these functions, and an array
>> of arrays containing the t
Hi,
I would like to know how people feel about going toward a time-based
release process for numpy (and scipy). By time-based release, I mean:
- releases of numpy are time-based, not feature based.
- a precise schedule is fixed, and the release manager(s) try to
enforce thi
2008/5/11 Robert Kern <[EMAIL PROTECTED]>:
> Basically, you need 3 arrays: functions implementing the type-specific
> inner loops, void* extra data to pass to these functions, and an array
> of arrays containing the type signatures of the ufunc. In numpy, we
> already have generic implementations
On Sun, May 11, 2008 at 1:04 PM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Suppose I have a C function,
> double logsum(double a, double b);
> What is needed to produce a ufunc object whose elementwise operation
> is done by calling this function?
Basically, you need 3 arrays: functions
I added a wiki page: http://scipy.org/NewMatrixSpec
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Sun, May 11, 2008 at 12:44 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> On Sun, May 11, 2008 at 1:01 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
>>
>> The most basic, and the most contentious, design decision of a new
>> matrix class is matrix indexing. There seems to be two camps:
>>
>> 1
On Sun, May 11, 2008 at 1:01 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> The most basic, and the most contentious, design decision of a new
> matrix class is matrix indexing. There seems to be two camps:
>
> 1. The matrix class should be more like the array class. In particular
> x[0,:] should
The most basic, and the most contentious, design decision of a new
matrix class is matrix indexing. There seems to be two camps:
1. The matrix class should be more like the array class. In particular
x[0,:] should return a 1d array or a 1d array like object that
contains the orientation (row or co
2008/5/11 Alan McIntyre <[EMAIL PROTECTED]>:
> On Sun, May 11, 2008 at 2:04 PM, Anne Archibald
> <[EMAIL PROTECTED]> wrote:
>> Also, is there a way to take a python function and automatically make
>> a ufunc out of it? (No, vectorize doesn't implement reduce(),
>> accumulate(), reduceat(), or ou
On Sun, May 11, 2008 at 2:04 PM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
> Also, is there a way to take a python function and automatically make
> a ufunc out of it? (No, vectorize doesn't implement reduce(),
> accumulate(), reduceat(), or outer().)
I've not used it, but have a look at numpy.
Hi,
Suppose I have a C function,
double logsum(double a, double b);
What is needed to produce a ufunc object whose elementwise operation
is done by calling this function?
Also, is there a way to take a python function and automatically make
a ufunc out of it? (No, vectorize doesn't implement redu
On Sun, May 11, 2008 at 01:16:44PM -0400, Alan G Isaac wrote:
> That seems like the same thing to me. What I mean is that
> part of the problem is that the handling of scalar indexing
> is being treated as part of the API contract simply because
> it was discoverable behavior.
OK, I didn't und
>> I suspect part of the problem is that "backward
>> compatability" is being interpreted in terms of discoverable
>> behavior, rather than in terms of documented behavior.
On Sun, 11 May 2008, Gael Varoquaux wrote:
> Not at all. It is to be interpreted in terms of "I have
> a few dozens kilol
On Sun, May 11, 2008 at 12:26:49PM -0400, Alan G Isaac wrote:
> As Anne pointed out, examples are accumulating that there is
> a *fundamental* problem with matrix handling of scalar
> indexing. I agree with this. It is not just an
> "annoyance". It keeps affecting code that tries to handle
>
On Sun, 11 May 2008, Gael Varoquaux apparently wrote:
> Pluging one annoyance to create another one (IMHO worse),
> and in addition breaking backward compatibility seems
> utterly wrong to me.
I'm a little puzzled by this phrasing.
As Anne pointed out, examples are accumulating that there is
On Thu, May 08, 2008 at 10:04:28AM -0600, Charles R Harris wrote:
>What realistic probability is in the range exp(-1000) ?
I recently tried to do Fisher information estimation of a very noisy
experiment. For this I needed to calculate the norm of the derivation of
the probability over the enti
On Mon, May 05, 2008 at 08:19:10PM -0400, dieter h wrote:
> I humbly suggest Sphinx[1] as the generating tool and markup rather
> than just regular ReST. I'm in the process of converting all of my
> local documentation to this engine's format.
I agree with you that Sphinx rocks hard. Ipython, symp
On Fri, May 09, 2008 at 12:53:40PM -0500, Nathan Bell wrote:
> True, but scipy.sparse makes fairly limited use of matrix and I have
> 386 unittests to tell me what broke. End-users might spend
> considerably longer sorting out the problem, particularly if they
> don't know what they're looking for
37 matches
Mail list logo
