On Wed, Apr 28, 2010 at 2:46 PM, David Warde-Farley wrote:
> Would it be acceptable to retain the matrix class but not have it imported in
> the default namespace, and have to import e.g. numpy.matlib to get at them?
+1
Jarrod
___
NumPy-Discussion mai
Alan G Isaac wrote:
> On 4/28/2010 12:08 PM, Dag Sverre Seljebotn wrote:
>
>> it would be good to deprecate the matrix class
>> from NumPy
>>
>
>
> Please let us not have this discussion all over again.
>
> The matrix class is very useful for teaching.
> In economics for example, the use
On 4/28/2010 5:46 PM, David Warde-Farley wrote:
> Would it be acceptable to retain the matrix class but not have it
> imported in the default namespace, and have to import e.g.
> numpy.matlib to get at them?
If we can have A * M undefined, then I do not think this is
a needed addition. But I do n
> Alan wrote:
>> There is one change I would not mind: let
>> A * M be undefined if A is an ndarray and
>> M is a NumPy matrix.
On 4/28/2010 5:46 PM, David Warde-Farley wrote:
> What about the other binary ops? I would say, matrix goes with matrix,
> array with array, never the two shall meet unl
On Apr 28, 2010, at 4:46 PM, David Warde-Farley wrote:
On 2010-04-28, at 2:30 PM, Alan G Isaac wrote:
Please let us not have this discussion all over again.
Agreed. See my preface to this discussion.
My main objection is that it's not easy to explain to a newcomer
what the difference pre
On 2010-04-28, at 2:30 PM, Alan G Isaac wrote:
> Please let us not have this discussion all over again.
Agreed. See my preface to this discussion.
My main objection is that it's not easy to explain to a newcomer what the
difference precisely is, how they interact, why two of them exist, how the
On Wed, Apr 28, 2010 at 2:12 PM, Alan G Isaac wrote:
> On 4/28/2010 12:05 PM, Travis Oliphant wrote:
>> A proposal was made to allow "calling a NumPy array" to infer dot
>> product:
>>
>> a(b) is equivalent to dot(a,b)
>>
>> a(b)(c) would be equivalent to dot(dot(a,b),c)
>
>
> Here is a related ti
On Wed, Apr 28, 2010 at 15:50, Travis Oliphant wrote:
>
> On Apr 28, 2010, at 11:19 AM, Robert Kern wrote:
>
>> On Wed, Apr 28, 2010 at 11:05, Travis Oliphant
>> wrote:
>>>
>>> On Apr 26, 2010, at 7:19 PM, David Warde-Farley wrote:
>>>
Trying to debug code written by an undergrad working for
On 28 April 2010 14:30, Alan G Isaac wrote:
> On 4/28/2010 12:08 PM, Dag Sverre Seljebotn wrote:
>> it would be good to deprecate the matrix class
>> from NumPy
>
> Please let us not have this discussion all over again.
I think you may be too late on this, but it's worth a try.
> The matrix clas
On 4/28/2010 12:08 PM, Dag Sverre Seljebotn wrote:
> it would be good to deprecate the matrix class
> from NumPy
Please let us not have this discussion all over again.
The matrix class is very useful for teaching.
In economics for example, the use of matrix algebra
is widespread, while algebra w
josef.p...@gmail.com wrote:
> On Wed, Apr 28, 2010 at 1:30 PM, David Warde-Farley
> wrote:
>
>> On 2010-04-28, at 12:05 PM, Travis Oliphant wrote:
>>
>>
>>> a(b) is equivalent to dot(a,b)
>>>
>>> a(b)(c) would be equivalent to dot(dot(a,b),c)
>>>
>>> This seems rather reasonable.
>>>
On Apr 28, 2010, at 11:50 AM, Nikolaus Rath wrote:
> Robert Kern writes:
>>> Overloading '*' and '**' while convenient does have
>>> consequences. It
>>> would be nice if we could have a few more infix operators in
>>> Python to
>>> allow separation of element-by-element calculations and
On Apr 28, 2010, at 11:19 AM, Robert Kern wrote:
> On Wed, Apr 28, 2010 at 11:05, Travis Oliphant
> wrote:
>>
>> On Apr 26, 2010, at 7:19 PM, David Warde-Farley wrote:
>>
>>> Trying to debug code written by an undergrad working for a colleague
>>> of
>>> mine who ported code over from MATLAB,
On 4/28/2010 12:05 PM, Travis Oliphant wrote:
> A proposal was made to allow "calling a NumPy array" to infer dot
> product:
>
> a(b) is equivalent to dot(a,b)
>
> a(b)(c) would be equivalent to dot(dot(a,b),c)
Here is a related ticket that proposes a more
explicit alternative: adding a ``dot`` m
Nikolaus Rath wrote:
> Robert Kern writes:
>
>>> Overloading '*' and '**' while convenient does have consequences. It
>>> would be nice if we could have a few more infix operators in Python to
>>> allow separation of element-by-element calculations and "dot-product"
>>> calculations.
>>>
On Wed, Apr 28, 2010 at 1:30 PM, David Warde-Farley wrote:
>
> On 2010-04-28, at 12:05 PM, Travis Oliphant wrote:
>
>> a(b) is equivalent to dot(a,b)
>>
>> a(b)(c) would be equivalent to dot(dot(a,b),c)
>>
>> This seems rather reasonable.
>
> Indeed, and it leads to a rather pleasant way of permut
On 2010-04-28, at 12:05 PM, Travis Oliphant wrote:
> a(b) is equivalent to dot(a,b)
>
> a(b)(c) would be equivalent to dot(dot(a,b),c)
>
> This seems rather reasonable.
Indeed, and it leads to a rather pleasant way of permuting syntax to change the
order of operations, i.e. a(b(c)) vs. a(b)(c
Robert Kern writes:
>> Overloading '*' and '**' while convenient does have consequences. It
>> would be nice if we could have a few more infix operators in Python to
>> allow separation of element-by-element calculations and "dot-product"
>> calculations.
http://www.python.org/dev/peps/pep-022
On Wed, Apr 28, 2010 at 10:05 AM, Travis Oliphant wrote:
>
> On Apr 26, 2010, at 7:19 PM, David Warde-Farley wrote:
>
> > Trying to debug code written by an undergrad working for a colleague
> > of
> > mine who ported code over from MATLAB, I am seeing an ugly melange of
> > matrix objects and nda
On Wed, Apr 28, 2010 at 10:08 AM, Dag Sverre Seljebotn <
da...@student.matnat.uio.no> wrote:
> David Warde-Farley wrote:
> > Trying to debug code written by an undergrad working for a colleague of
> > mine who ported code over from MATLAB, I am seeing an ugly melange of
> > matrix objects and ndar
On Wed, Apr 28, 2010 at 11:05, Travis Oliphant wrote:
>
> On Apr 26, 2010, at 7:19 PM, David Warde-Farley wrote:
>
>> Trying to debug code written by an undergrad working for a colleague
>> of
>> mine who ported code over from MATLAB, I am seeing an ugly melange of
>> matrix objects and ndarrays t
David Warde-Farley wrote:
> Trying to debug code written by an undergrad working for a colleague of
> mine who ported code over from MATLAB, I am seeing an ugly melange of
> matrix objects and ndarrays that are interacting poorly with each other
> and various functions in SciPy/other libraries.
On Apr 26, 2010, at 7:19 PM, David Warde-Farley wrote:
> Trying to debug code written by an undergrad working for a colleague
> of
> mine who ported code over from MATLAB, I am seeing an ugly melange of
> matrix objects and ndarrays that are interacting poorly with each
> other
> and various
Trying to debug code written by an undergrad working for a colleague of
mine who ported code over from MATLAB, I am seeing an ugly melange of
matrix objects and ndarrays that are interacting poorly with each other
and various functions in SciPy/other libraries. In particular there was
a custom
24 matches
Mail list logo
