On Sat, Feb 14, 2015 at 5:21 PM, wrote:
> On Sat, Feb 14, 2015 at 4:27 PM, Charles R Harris
> wrote:
> >
> >
> > On Sat, Feb 14, 2015 at 12:36 PM, wrote:
> >>
> >> On Sat, Feb 14, 2015 at 12:05 PM, cjw wrote:
> >> >
> >> > On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote:
> >> >>
> >> >> On W
On Sat, Feb 14, 2015 at 4:27 PM, Charles R Harris
wrote:
>
>
> On Sat, Feb 14, 2015 at 12:36 PM, wrote:
>>
>> On Sat, Feb 14, 2015 at 12:05 PM, cjw wrote:
>> >
>> > On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote:
>> >>
>> >> On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson
>> >> wrote:
>> >>>
>>
On Sat, Feb 14, 2015 at 12:36 PM, wrote:
> On Sat, Feb 14, 2015 at 12:05 PM, cjw wrote:
> >
> > On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote:
> >>
> >> On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson
> >> wrote:
> >>>
> >>> Colin,
> >>>
> >>> I currently use Py3.4 and Numpy 1.9.1. However, I
On Sat, Feb 14, 2015 at 12:05 PM, cjw wrote:
>
> On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote:
>>
>> On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson
>> wrote:
>>>
>>> Colin,
>>>
>>> I currently use Py3.4 and Numpy 1.9.1. However, I built a quick test
>>> conda
>>> environment with Python2.7 and
On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote:
> On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson wrote:
>> Colin,
>>
>> I currently use Py3.4 and Numpy 1.9.1. However, I built a quick test conda
>> environment with Python2.7 and Numpy 1.7.0, and I get the same:
>>
>>
>> Python 2.7.9
On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson wrote:
> Colin,
>
> I currently use Py3.4 and Numpy 1.9.1. However, I built a quick test conda
> environment with Python2.7 and Numpy 1.7.0, and I get the same:
>
>
> Python 2.7.9 |Continuum Analytics, Inc.| (default, Dec 18 2014, 16:57:52)
Thanks Ryan.
There are a number of good thoughts in your message. I'll try to keep
track of them.
Another respondent reported different results than mine. I'm in the
process of re-installing to check.
Colin W.
On 11 February 2015 at 16:18, Ryan Nelson wrote:
> Colin,
>
> I currently use Py3
Colin,
I currently use Py3.4 and Numpy 1.9.1. However, I built a quick test conda
environment with Python2.7 and Numpy 1.7.0, and I get the same:
Python 2.7.9 |Continuum Analytics, Inc.| (default, Dec 18 2014, 16:57:52)
[MSC v
.1500 64 bit (AMD64)]
Type "copyright", "credits" or "lic
11.02.2015, 21:57, Alan G Isaac kirjoitti:
[clip]
> I think gains could be in lazy evaluation structures (e.g.,
> a KroneckerProduct object that never actually produces the product
> unless forced to.)
This sounds like an abstract linear operator interface. Several attempts
have been made to this
On 2/11/2015 2:25 PM, cjw wrote:
> I think of the matrix as a numeric object. What would the case be for having
> a Boolean matrix?
It's one of my primary uses:
https://en.wikipedia.org/wiki/Adjacency_matrix
Numpy alread provides SVD:
http://docs.scipy.org/doc/numpy/reference/generated/numpy.l
On 11-Feb-15 12:13 PM, Alan G Isaac
wrote:
Just recalling the one-year-ago discussion:
http://comments.gmane.org/gmane.comp.python.numeric.general/56494
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@s
Thanks Sebastian,
This would appear to make a case for considering not having Matrix
as a sub-class of an np array.
On the other hand, so much work has gone into np, and there is some
commonality between the needs of Matrix and Array.
Colin W.
On 11 February 2015 at 18:22, Stephan Hoyer wrote:
> In my opinion, a "fixed" version of np.matrix should (1) not be a
> np.ndarray subclass and (2) exist in a third party library not numpy itself.
>
+1 for both of those ... but especially the first.
_
On Wed, Feb 11, 2015 at 9:19 AM, Sebastian Berg
wrote:
> On Mi, 2015-02-11 at 11:38 -0500, cjw wrote:
> No, I just mean the fact that a matrix is always 2D. This makes some
> things like some indexing operations awkward and some functions that
> expect a numpy array (but think they can handle sub
On Mi, 2015-02-11 at 11:38 -0500, cjw wrote:
>
> On 11-Feb-15 10:47 AM, Sebastian Berg wrote:
>
> > On Di, 2015-02-10 at 15:07 -0700, cjw wrote:
> > > It seems to be agreed that there are weaknesses in the existing Numpy
> > > Matrix
> > > Class.
> > >
> > > Some problems are illustrated below.
Just recalling the one-year-ago discussion:
http://comments.gmane.org/gmane.comp.python.numeric.general/56494
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 11-Feb-15 10:21 AM, Ryan Nelson
wrote:
So:
In [2]: np.mat([4,'5',6])
Out[2]:
matrix([['4', '5', '6']], dtype='
Thanks Ryan,
We are not singing from the same hymn book.
Using PyScripter, I get:
*** Python 2.7.9 (default, Dec 10
On 11-Feb-15 10:47 AM, Sebastian Berg
wrote:
On Di, 2015-02-10 at 15:07 -0700, cjw wrote:
It seems to be agreed that there are weaknesses in the existing Numpy Matrix
Class.
Some problems are illustrated below.
Not to delve deep
On Di, 2015-02-10 at 15:07 -0700, cjw wrote:
> It seems to be agreed that there are weaknesses in the existing Numpy Matrix
> Class.
>
> Some problems are illustrated below.
>
Not to delve deeply into a discussion, but unfortunately, there seem far
more fundamental problems because of the always
So:
In [2]: np.mat([4,'5',6])
Out[2]:
matrix([['4', '5', '6']], dtype=' wrote:
> It seems to be agreed that there are weaknesses in the existing Numpy
> Matrix
> Class.
>
> Some problems are illustrated below.
>
> I'll try to put some suggestions over the coming weeks and would appreciate
> comme
It seems to be agreed that there are weaknesses in the existing Numpy Matrix
Class.
Some problems are illustrated below.
I'll try to put some suggestions over the coming weeks and would appreciate
comments.
Colin W.
Test Script:
if __name__ == '__main__':
a= mat([4, 5, 6])
On Apr 29, 2008, at 2:50 AM, Robert Cimrman wrote:
> FYI:
> In scipy, the iterative solvers (cg and like) should work with
> LinearOperator (a class with matvec, rmatvec, and eventually matmat
> methods) passed instead of the A matrix argument. There is a function
> aslinearoperator() is scipy.spa
Bill Spotz wrote:
> On Apr 28, 2008, at 10:47 PM, Bill Spotz wrote:
>
>> As for this example, my version should work with a properly
>> implemented sparse_matrix A, but the array approach precludes that.
>> That is to say, I could convert A to a matrix if it is provided as an
>> array, but you cou
On Mon, 28 Apr 2008, Bill Spotz apparently wrote:
> If matrix multiplication in my example is replaced with
> np.dot() in yours, then when IS anything gained by using
> matrices?
When matrix algebra is clearer than array algebra.
But that is not the case for this algorithm.
(Just the opposite,
On Apr 28, 2008, at 10:47 PM, Bill Spotz wrote:
> As for this example, my version should work with a properly
> implemented sparse_matrix A, but the array approach precludes that.
> That is to say, I could convert A to a matrix if it is provided as an
> array, but you could not convert a sparse_ma
On Apr 28, 2008, at 10:15 PM, Alan G Isaac wrote:
> On Mon, 28 Apr 2008, Bill Spotz apparently wrote:
>> http://www.scipy.org/ConjugateGradientExample ... provides
>> one small area where the vector classes would be useful.
>
> Maybe not.
> I posted an alternate version of your algorithm,
> just b
On Mon, 28 Apr 2008, Bill Spotz apparently wrote:
> http://www.scipy.org/ConjugateGradientExample ... provides
> one small area where the vector classes would be useful.
Maybe not.
I posted an alternate version of your algorithm,
just below yours,
sticking very close to your example.
Cheers,
Al
On Apr 24, 2008, at 8:52 PM, Bill Spotz wrote:
On Apr 24, 2008, at 5:45 PM, Timothy Hochberg wrote:
Bill Spotz wrote:
> I have generally thought about this in the context of, say, a
> Krylov-space iterative method, and what that type of interface
would
> lead to the most readable code.
Can
On Thu, Apr 24, 2008 at 5:45 PM, Timothy Hochberg <[EMAIL PROTECTED]>
wrote:
>
>
> Chris.Barker wrote:
>
>> Alan G Isaac wrote:
>> > the cost of complexity should be justified by a gain in functionality.
>>
>> I don't think functionality is the right word here. the Matrix class(es)
>> is all about
On Apr 24, 2008, at 5:45 PM, Timothy Hochberg wrote:
Bill Spotz wrote:
> I have generally thought about this in the context of, say, a
> Krylov-space iterative method, and what that type of interface would
> lead to the most readable code.
Can you whip up a small example, starting with the curr
Chris.Barker wrote:
> Alan G Isaac wrote:
> > the cost of complexity should be justified by a gain in functionality.
>
> I don't think functionality is the right word here. the Matrix class(es)
> is all about clean, convenient API, i.e. style, not functionality -- we
> have all the functionality a
31 matches
Mail list logo
