And that matters if you are mostly worried about value, to a large extent. If you are evaluating "better" as in "supports more symbolic operations," none of those really enter into it? Right?
This is like opining that the best "car" out there is a gokart you can get complete schematics on, for all of these reasons. I think most of us would accept the argument that the better cars are the ones that pass metrics aimed at cars. In this analogy, the better algebra system is the one that does the most algebra.
If SymPy meets your needs, it is objectively better. Mathematica is expensive and you probably have to pay for licenses on a continuous basis for every instance you use. Many benchmarks are stress tests and not representative of common work.
This is kind of silly, though? Yes, if you do not need a full car, a bike may fit your needs. The bike is still not a better car, though.
You can try to broaden it to saying it is a better vehicle for you. And, sure, for a lot of folks the cost will be important there. As a CAS, though, Mathematica is tough to beat.
No it's not silly. A Lamborghini might be a better performing vehicle that could solve problems I didn't even know I had, but if I don't have the money for it and/or a Ford Pinto covers 99% of the cases I need, the Pinto is better.
I'm not arguing that SymPy is going to beat Mathematica on benchmarks. But if both of them meet your needs, and you like having money and/or control of the code, SymPy wins.
So, in this we don't really disagree. But, I would only agree that it is an objectively better choice for you. It is not an objectively better CAS. Demonstrably so, per that benchmark.
Similarly, a lamborghini is almost certainly an objectively faster car. Such that if you were discussing fast vehicles and someone pointed out that their ebike was good enough for them, it would be a statement out of nowhere that is not using the rubric for ordering that was being discussed. Are they wrong that the ebike is a better choice for them? Almost certainly not. Would it be valid to say that it is the best fast vehicle because of that? (I say this as someone that loves bikes and is fairly anti car...)
And there would be other rubrics that would shine light in either direction regarding python. Arguably, the stewardship of the language lost a lot of trust with people in the hilariously bad 2->3 migration. More so in how bad dependency management has become. Yes, you can roll your own, but people with large support contracts can almost certainly offload a lot of that to the team on Mathematica, if that is truly a concern.
(I could similarly cast shade on Mathematica, but I think my point is made. Yes, you can have a rubric that changes which is the better choice for a situation. No, there is no total ordering of correct choices.)
We are essentially in agreement. I just don't think Mathematica is worth the money unless you need it for something specific like solving tricky problems. As much shade as you can throw on Python, there are lots more possibilities to use Python with SymPy than to use Mathematica. Unfortunately, the cutting edge FOSS math scene will always lag behind the commercial tools, as it is incredibly hard for them to get donations. I remember hearing a story about the developer of Octave (the most popular Matlab clone). He had worked on it for years and hardly got any donations, despite probably having hundreds of thousands of downloads and constant feature requests.
I also think the math systems will lag for more than just donations. The work to make a good CAS is pretty intense. A lot like a good SAT system. Or really anything that is deep in the weeds of computer science. A lot of us are so far removed from the math that they focus on, that it can be mind bending to try and get back into it. (Indeed, for a lot like me, we were probably never really great at it, in the first place.)
Mathematica and Matlab are interesting to consider, as they are likely very well integrated into older workflow systems from the mainframe era. In particular, I'd expect the high end simulations for car and vehicle designs are much more integrated with those than anything open source. And a lot of that is largely availability of what they are integrating with. Most of us do not have the science labs and all of the equipment that goes with it.
Which, I think, is a bad feedback loop on this. For folks without those labs, Mathematica/Matlab are prohibitively expensive. For those with the labs, they are probably a rounding error. And there is no real path from the current equilibrium to one that can get it to more people. (The old path was free access in college. But that is becoming less of a thing in modern programming jobs.)
It's not just initial installation. I have not pursued a license lately but these kinds of products cost money for every running instance. Institutions often have license servers on premises that allow a fixed number of people to use the stuff at once. If you use a SDK to build a program with it, that's got a separate license. If you need it for a real product, we are generally talking like thousands of dollars per developer per year in perpetuity, plus god knows whatever you use for SaaS. You might have to negotiate a price for your use case.
(1) is true, but Mathematica is also supported because it is paid. (2), (3), and (4) are very iffy stances. Open source projects also fail when leaders move on, and it's actually less likely for a company. (5) has nothing to do with open source, and Mathematica is extensible.
I ask because I always see open source thrown around as if it's some paragon of quality and productiveness. In reality, the actual usefulness of a product is fairly independent of its open source status. And rarely does it matter all that much to a project that a software component is open source or not.
I'm a mathematician. One reason it matters to me is that if I write a program that computes something in a proof, I need to be able to understand and verify (or possibly check that other people I trust have verified) the source and algorithms.
I have also modified and extended open source implementations in sage to work with cases I needed. And I've added some of this back to sage.
It is undeniable that Mathematica evaluates crazy integrals better than most other tools. But it will happily output complete nonsense. And you can't check!
> One reason it matters to me is that if I write a program that computes something in a proof, I need to be able to understand and verify (or possibly check that other people I trust have verified) the source and algorithms
Do you actually do this verification? How do you accomplish this? The software stacks are huge. Why do you trust other people over the people who develop Mathematica, who just happened to be paid?
Yes, I do. And open source software can have papers and algorithms documenting various aspects. This is very much like using results of other math research papers, in that there is communal review and trees of dependencies and everything can be cross-verified.
It is also true that, just like with a generic math research paper, that I don't check every claim of every step of every implementation of every algorithm in the process. But checking is possible, and when we find errors (which we do frequently) we can look and try to explain what it happening.
But when we find errors in tools such as Mathematica, we cannot. We report the errors and then know nothing more. (And sometimes the errors are never fixed).
I doubt there's any sort of fundamental flaw in sympy. Getting more and more solutions is mostly about putting in lots of work to tweak the bag of tricks. There is no universal algorithm for solving integrals.
As an open source project depending on volunteers (or is it just the one major author?) I am impressed that sympy does as much as it does.
Though often it is not implemented because it is quite complex (its details covering two thick books) and many of the special cases it covers rarely crop up in the real world, so the effort isn't worth it.
The caveat of Risch's algorithm is that it only "works" if the function you are trying to integrate has an elementary antiderivative. Many of the problems that Mathematica can solve (but SymPy fails at) involved special (i.e. non-elementary) functions.
It's a running joke that Wolfram is a jobs program for math PhD's. The difference isn't necessarily technical, but the sheer amount of labor that has gone into adding more edge cases and niche use cases. Sympy is great but like most open source, it's created by volunteer maintainers supported by donations.
I imagine the difference is even bigger in things like solving ODE's/PDE's.
I mean, literally people with Math PhDs are being paid to work on the product, full-time. And they have a financial incentive to address feedback from customers and try to solve as many problems as possible.
By comparison, open source projects are developed by people with a wide range of knowledge level and commitment, and you simply can't expect the quality to be the same.
I find that discussions on HN often fail to acknowledge that proprietary software is usually extremely good at their domain, and what companies put into UX, support and the development/feedback loop are actually very valuable.
I know that but the idea behind my question was this: the knowledge we need to put in such a program doesn't move as fast as the program evolves. Therefore, given enough time (say 20 years), the open source solutions will cover more or less the same ground as the expensive solution. Of course the expensive one may always have an edge but that edge should get smaller over time. For example, Oracle remains a gold standard, really expensive but postgres covers many needs. Linux-on-the-desktop is also quite good, although not as good as, say, MacOS.
In the same vein, I was expecting SymPy to be like 80% of Mathematica but the given benchmark says it's about 25%. So I was suprised.
And I'm not thinking about UX, support, etc. which are indeed not often very good because, I guess, people prefer to put their energy in things that have the bigger leverage.
You mean they were Mathematica customers. Academics are incentivized to use proprietary solutions as those solutions tend to be best-in-class and also offered at a discount.
No, I mean I am yet to meet a person who has done development on SymPy (that I can recall) but I know a few academics that came from working for Wolfram on Mathematica itself.
That's interesting. You should consider yourself lucky to have met Wolfram employees, as they are obviously vastly outnumbered by users of Mathematica.
You may not be hearing about SymPy users because SymPy is not a monolithic product. It is a library. If you know mathematicians big into using Python, they are probably aware of SymPy as it is the main attraction when it comes to symbolic computation in Python. They wouldn't necessarily spit out a bunch of libraries in the same breath as "I use Python."
I have been playing around with SymPy for the last couple of weeks because the CompSci department (not entirely uncontroversially) wants to become Python native for the students to make the courses more accessible. I have been looking into ways to incorporate SymPy and SageMath into my tutoring for the mathematics for comp sci students type units.
1261 is an impressive number of contributors. I am interested to see if I could round up some people to hack up some of these test failures.
Excel is built with programming language and can certainly be used as one, but that doesn't mean it is one. It's also a bit anal to classify Excel as a programming language, most people would say spreadsheets are a tool, where you could write programs, but again, doesn't mean it's a programming language. At most, I'd give you that Excel is a tool that can do "visual programming", but that's far of from being a "programming language".
This is unfair and a far too narrow definition of programming language. Excel sits very squarely in the functional reactive language space. Just because most of it's users don't "know" they are programming and most of our common tools don't work with it doesn't change the fact that it has pretty much all of the building blocks that any programming language gives you. Are there domains where Excel is awkward to use? Absolutely. The same can be said about pretty much any programming language.
Excel deserves to have the label of programming language even if it shuns that label due to it's target audience.
I guess what I was trying to say that Excel as commonly known, is a programming environment, rather than a language. Where you can use the "Excel" programming language for performing most (if not all) tasks a general purpose programming language can.
But it's still a bit like saying "Eclipse" is a programming language. You can do programming in Eclipse, that is true, but you can also do other things that are not programming, which makes Eclipse a programming environment. Just like with Excel.
I don't think this is a true dividing line for a programming language. The Smalltalk language for instance combines both the programming environment and the language together. I don't think anyone seriously argues that smalltalk is not a programming language.
Seems like equivocation — Smalltalk is a programming language when we're using "Smalltalk" to mean Smalltalk the programming language and Smalltalk is a programming environment when we're using "Smalltalk" to mean Smalltalk the programming environment.
Excel has conditionals and several forms of map/reduce which stand in for loops all without relying on VBA. I stand by my statement that Excel qualifies in everyway that matters as a programming language.
They avoid that label because of their target audience but the label absolutely applies.
There's many open-source alternatives to Excel. Rarely used, but it settles any fear of lock in.
This also made the area palatable for other commercial competitors to enter the space - Google-sheets drive A TON of enterprise org work nowadays.
You could say that open-source alternatives immensely popularized spreadsheets and resulted in the very nice ecosystem we have now.
Sure, heave finance user stick to MS Excell because MS is pressured to cater very well to their needs, else they will move away to other free or paid alternatives.
Also, there's a reason why multi-dimensional spreadheets are not more popular despite solving so many problems of regular spreadheets: all are proprietary and very different one from another - you probably pick smth like Quantrix (https://quantrix.com/products/quantrix-modeler/), and you'd get insane prices and 100% lock-in... better stick to Excell and/or its open-source and/or free alternatives despite being a worse tool :)
ContentDetectorFunction (updated) — support for Information
DimensionReducerFunction(updated) ▪ FeatureExtractorFunction(updated)
FindClusters (updated) — support for fixed number of clusters and UpTo
ClusterClassify(updated) ▪ ClusteringComponents(updated)
Interpretable Machine Learning
FeatureValueImpactPlot — plots the impact of a feature on a model result
FeatureImpactPlot — plots the impact of each feature together
CumulativeFeatureImpactPlot — plots the cumulative impact of each feature
FeatureValueDependencyPlot — plots the result dependency on a feature value
Network Layers »
ReplicateLayer (updated) — support for integer arrays
RandomArrayLayer (updated) — support for more statistical distribution
AttentionLayer (updated) — support for dropout and local masking
ElementwiseLayer (updated) — new activations "Mish" and "GELU"
ThreadingLayer(updated) ▪ FunctionLayer(updated)
Network Training »
NetTrain (updated), LossFunction (updated) — support for multi-output and nonscalar loss
Encoders & Decoders »
"Image" (updated) — resampling and padding support
"Class" (updated) — support for top-k and top-p sampling (nucleus sampling)
Formats
"ONNX" (updated) — export support for net operators
Three of their best ML engineers /devs left in the last 12 months or so. The backend for anything deep-learning is MXNet...which is essentially a non-starter these days vs PyTorch or TensorFlow. All these functions you cite are very low level updates not real feature updates.
I would say in 2018-2019 the ML / Deep learning stack was actually very impressive compared with what was available in FOSS. Now -- it's languishing. Badly.
My Raspberry Pi 3 came with Mathematica. If I write Mathematica code on it, put the device in a box and sell it, I just violated the license agreement.
The results were Mathematica failed to solve 1,523 problems, Sympy failed to solve 48,529.
So it has some catching up to do.