On Mon, Feb 10, 2014 at 6:11 PM, Charles R Harris <charlesr.har...@gmail.com
> wrote:
>
>
>
> On Mon, Feb 10, 2014 at 5:39 PM, Pauli Virtanen <p...@iki.fi> wrote:
>
>> 11.02.2014 01:39, josef.p...@gmail.com kirjoitti:
>> [clip]
>> > Almost all the code in scipy.stats and statsmodels starts with
>> np.asarray.
>> > The numpy doc standard has the term `array_like` to indicate things that
>> > can be converted to a usable object by ndasarray.
>> >
>> > ducktyping could be restricted to a very narrow category of ducks.
>> >
>> > What about masked arrays and structured dtypes?
>> > Because we cannot usefully convert them by asarray, we have to tell
>> users
>> > that they don't work with a function.
>> > Our ducks that quack in the wrong way.?
>>
>> The issue here is semantics for basic linear algebra operations, such as
>> matrix multiplication, that work for different matrix objects, including
>> ndarrays.
>>
>> What is there now in scipy.sparse is influenced by np.matrix, and this
>> is proving to be sub-optimal, as it is incompatible with ndarrays.
>>
>> > How do you handle list and other array_likes in sparse?
>>
>> if isinstance(t, (list, tuple)): asarray(...)
>>
>> Sure, np.matrix can be dealt with as an input too.
>>
>> But as said, I'm not arguing so much about asarray'in np.matrices as
>> input, but the fact that agreement on the meaning of "*" in linear
>> algebra code in Python is muddled. This should be fixed, and deprecating
>> np.matrix would point the way.
>>
>> (I also suspect that this argument has been raised before, but as long
>> as there's no canonical write-up...)
>>
>>
> This would require deprecating current sparse as well, no?
>
> I could be convinced to follow this route if there were a pedagogic
> version of a matrix type that was restricted to linear algebra available as
> a separate project. It could even have some improvements, row and column
> vectors, inv, etc, but would not be as full featured as numpy arrays. The
> idea is that it would serve for teaching matrices rather than numerical
> programming in python. Hopefully that would satisfy Alan's teaching use
> case. There is the danger of students getting tied to that restricted
> implementation, but that may not be something to worry about for the sort
> of students Alan is talking about.
>
>
Another possibility is to provide an infix matrix multiplication operator.
from sage.misc.decorators import infix_operator
@infix_operator('multiply')def dot(a,b):
return a.dot_product(b)
u=vector([1,2,3])
v=vector([5,4,3])print(u *dot* v)# => 22
@infix_operator('or')def plus(x,y):
return x*yprint(2 |plus| 4)# => 6
Chuck
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
