Well, I was trained and an engineer, but now call myself an oceanographer, but in any case, I don't need to submit my calculations for review to anyone. Though I do need to present algorithms / calculations / methods in written form that others can understand -- so a similar problem.
But frankly, Python is simply not the right tool for the job of presenting calculations that look iike math -- Ricky Teachey mentioned MathCAD -- which is indeed a tool for that job. Let's not try to squeeze Python into that role. So I don't think that trying to make Python look more like math is a reason to add a Matrix library to Python. I'm also very confused about why folks don't want to use numpy for this stuff? numpy is the right tool for the job, is robust and well supported, and virtually anyone can pip install it -- yes it took a couple decades to get to that point, but we really are there now. But: numpy has a Matrix object, which is pretty much deprecated, and there is a good reason for that. In a nutshell, the reason is that the only thing that Matrix gave you for "real work" was a nice operator for matrix multiplication, and what it lost you was compatibility with the rest of numpy -- it was really pretty painful to switch between Matrix and regular numpy arrays. -- when we finally realized that matmult really was the only important thing -- then adding the @ operator was an excellent solution -- and here we are. However, that does NOT mean that a Matrix class isn't useful, just that it's not useful for doing calculations within teh numpy ecosystem, and when you are doing 'real work", the rest of the numpy ecosystem is very important. I highly encourage anyone interested in this topic to search the archives of the numpy lists to find the many long discussions of this issue -- it will be very informative. But I'll try to hit a couple highlights, from my memory: 1) The primary motivator for a "proper" matrix object is pedagogical: being able to write code that is more or less a direct translation of what one sees in a linear algebra textbook. Why is that? Because in production code there may be one or two lines that do a classic linear algebra calculation, and hundreds of lines that do other things with arrays -- and a numpy-style ndarray is better suited for those other hundred lines. And when you add @ -- now it's maybe one, rather than two out of hundreds :-). (I saw a note earlier in this thread about how horrible broadcasting is: I'm sorry, they are "just wrong" -- broadcasting is really, really, useful -- far more useful than one or two "proper" linear algebra operations.) 2) The other reason the numpy.Matrix object didn't really work out is that it didn't quite go far enough: I highly suggest that if one writes a linear algebra package that seeks to model what we learn in textbooks, that you have not just a Matrix, but also a Scalar (duh, but MATLAB, for instance didn't really make that distinction), and a RowVector and ColumnVector objects -- you could do what numpy Matrix and MATLAB did, and have all "things" be 2D, and a 1xN matrix is a row vector, and an (Nx1) Matrix is a column vector -- but I don't recommend it. This was a source of problems for the numpy Matrix: numpy has a 1d array (i.e. vector) but no way to distinguish Row vs Column -- it gets awkward. There may be other examples I can't think of now, but in short: if you are going to do it, really go for it, make it all about linear algebra, and not try to be a general purpose array computation system -- we have numpy for that, and we know that mixing and matching those two does not work out well. Another suggestion: to leave the door open to better performance (with C or Cython), I'd consider using an array.array for internal storage, and support the buffer protocol for interchange with numpy, and image processing libs, and .... If you want to support "non-standard" numeric types, like Decimal and Fraction, you could have a generic number type and use a list to store those. On the other hand, maybe performance simply isn't the point here. So: does such a thing belong in the standard library? I don't think so. But then again, I didn't think statistics did either. Though this really is less useful that the statistics module -- as said above it's really about teaching more than anything. Yes, a generally useful array computation lib would be nice -- but if we went that way, a "numpy-lite" would be the thing to do -- not a Matrix object. But in any case, it sure as heck could start out as a PyPi package to hammer out the wrinkles. BTW: There MUST be a Python Matrix lib out there already! Here's one that's not too old. https://pypi.org/project/matrix7/ I have no idea if it's any good but looking for prior art certainly makes sense. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LX7HSNMGJ553EDFQMDREUBFZCNI3S3XJ/ Code of Conduct: http://python.org/psf/codeofconduct/
