On Sun, Aug 16, 2020 at 1:19 AM Christopher Barker firstname.lastname@example.org wrote:
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.
If you are right, I find it sad. I love python to pieces. It's so very close to being what I want it to be in this aspect (displaying "just math, man").
I will say that at least python is much much closer to doing the job of presenting calculations than the most popular tool actually used for this purpose in the industry: that's right, it's Excel. Oh the devastating ennui. And python is also free. I'm the only person I know with a copy of mathcad on their machine and as a result I can't share any of my calculation tools with clients and colleagues-- all the tools I write that will ever be used (rather than just read) by others are currently written in Excel.
I've been creating workflows to turn python into that tool for quite a while now. Still not there. The closest I have come is what I described in my previous message: write code that works, copy and paste it into a separate text file and replace the bits that don't look enough like math.
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.
It's certainly what I use for all those reasons!
But there is still the occasional downside. Example: I just downloaded 3.9 rc1 yesterday and tried pip installing numpy, and building the wheel for the virtual env took forever (and btw pandas would not install at all). And there are still situations where putting numpy on a machine is difficult or impossible (Tobias Kohn described one).
A native, non performance critical library that doesn't have to be installed would just be really cool.
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 :-).
This was really helpful for me to understand why numpy works the way it does. Thanks.
(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.)
Totally agree. Broadcasting is not something I use a lot personally but I do think it is critical to the basic utility of numpy for many others. May not be critical to bring to a native python matrix class. Just not sure.
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.
I don't think it is. Maybe down the road.
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.
I'm far from the right person to say whether it belongs or not but if it was there, I am pretty sure I'd use it a lot for creation of calculations. Even if it didn't have broadcasting (which I only need sometimes). Just because of the convenience of not having to install it.
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.
I agree a numpy lite is probably better, so long as it implements matmul to make the educators happy.
BTW: There MUST be a Python Matrix lib out there already! Here's one that's not too old.
I have no idea if it's any good but looking for prior art certainly makes sense.
I spent last night throwing together my own numpy lite thing. I'll probably share it later this week once I polish it a bit (if I can get over the fear of actually submitting something intended for others to look at).
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler