5 ms·

Huh? Isn't it a question of whether you are doing matrix or array ops, so the type system is the issue? I have rarely needed to do elementwide multiply on matri

by jey 13y ago

Huh? Isn't it a question of whether you are doing matrix or array ops, so the type system is the issue? I have rarely needed to do elementwide multiply on matrices, and if I do, in Eigenproblem I can just call mat.array() to get an ArrayView. Really, the problem is that NumPy is a crappily designed library primarily intended for array ops, and is just not well suited for linear algebra.

hdevalence 13y ago
This is addressed in the proposal: Use a second type that defines __mul__ as matrix multiplication: As discussed above (Background: What's wrong with the status quo?), this has been tried this for many years via the numpy.matrix type (and its predecessors in Numeric and numarray). The result is a strong consensus among both numpy developers and developers of downstream packages that numpy.matrix should essentially never be used, because of the problems caused by having conflicting duck types for arrays. (Of course one could then argue we should only define __mul__ to be matrix multiplication, but then we'd have the same problem with elementwise multiplication.) There have been several pushes to remove numpy.matrix entirely; the only counter-arguments have come from educators who find that its problems are outweighed by the need to provide a simple and clear mapping between mathematical notation and code for novices (see Transparent syntax is especially crucial for non-expert programmers). But, of course, starting out newbies with a dispreferred syntax and then expecting them to transition later causes its own problems. The two-type solution is worse than the disease.
justincormack 13y ago
Indeed, especially as the functions that are + and * can vary based on type too, as you can have them defined over any ring.
rspeer 13y ago
> NumPy is a crappily designed library I don't think you know what you're talking about.
- jey 13y ago
  Try Eigen, you'll agree that NumPy is an array library that had linear algebra support thrown in as an afterthought.
  - rspeer 13y ago
    Of course it's an array library. The fact that it's not designed for your problem doesn't mean it's designed crappily. Suppose you ported Eigen to Python. You'd still need an array library, so you could represent the inputs and outputs in a way that's usable in Python. You'd probably use NumPy.

by jey 13y ago

hdevalence 13y ago

This is addressed in the proposal: Use a second type that defines __mul__ as matrix multiplication: As discussed above (Background: What's wrong with the status quo?), this has been tried this for many years via the numpy.matrix type (and its predecessors in Numeric and numarray). The result is a strong consensus among both numpy developers and developers of downstream packages that numpy.matrix should essentially never be used, because of the problems caused by having conflicting duck types for arrays. (Of course one could then argue we should only define __mul__ to be matrix multiplication, but then we'd have the same problem with elementwise multiplication.) There have been several pushes to remove numpy.matrix entirely; the only counter-arguments have come from educators who find that its problems are outweighed by the need to provide a simple and clear mapping between mathematical notation and code for novices (see Transparent syntax is especially crucial for non-expert programmers). But, of course, starting out newbies with a dispreferred syntax and then expecting them to transition later causes its own problems. The two-type solution is worse than the disease.

justincormack 13y ago

Indeed, especially as the functions that are + and * can vary based on type too, as you can have them defined over any ring.

rspeer 13y ago

> NumPy is a crappily designed library I don't think you know what you're talking about.

jey 13y ago
Try Eigen, you'll agree that NumPy is an array library that had linear algebra support thrown in as an afterthought.
- rspeer 13y ago
  Of course it's an array library. The fact that it's not designed for your problem doesn't mean it's designed crappily. Suppose you ported Eigen to Python. You'd still need an array library, so you could represent the inputs and outputs in a way that's usable in Python. You'd probably use NumPy.