# CAS Best Practices **URL:** https://discourse.julialang.org/t/cas-best-practices/58092 **Category:** Machine Learning **Tags:** symbolic **Created:** [March 27, 2021, 8:51pm UTC](https://discourse.julialang.org/t/cas-best-practices/58092 "2021-03-27T20:51:11Z") **Posts on this page:** 1 **Showing post:** 23

### Author: ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas) #### Post date: [March 30, 2021, 4:57pm UTC](https://discourse.julialang.org/t/cas-best-practices/58092/23 "2021-03-30T16:57:49Z")

> [@rfateman](#): > > (2) Assuming that finding simple solutions to simple parts of a complicated problem will lead to simple solutions to the difficult parts. (In this case, disregarding the evidence that – historically at least – working on solving those complicated problems has involved many clever people writing hundreds of thousands of lines of code, using tools that were, all-in-all, not necessarily inferior in capability from what you have in Julia.) To be specific, if it could be done easily, why are these programs (Mathematica, Maple, Maxima, Axiom, …) .so large? Is it plausible to believe that they are large because they were not written in Julia? I suspect that for most large projects, typically done for Lisp system building, and certainly for most of the CAS in Lisp, C, C++, … – the first order of business is to build a language support that includes what is needed to make the programmers’ tasks simpler. This could be writing macro definitions, defining structures, setting up generic definitions, writing parsers, etc. So a claim that Julia is somehow superior for writing a CAS lacks the context of “compared to …”. Maple was written in Margay, an extension of C. Axiom was written in SPAD, implemented in Lisp. Maxima has a mixture of methods, but data-directed dispatch was there from the beginning. All of your examples here violate the core principle that I want to capture which is direct embedding into the host language. I think these all make a mistake by trying to be “a language” instead of a set of symbolic tools that work seamlessly with an imperative language. SymPy has seen massive adoption compared to these tools in the last decade because of this fact. However, SymPy is about 10,000x slower than it needs to be because of its Python base and Python itself does not have good numerical batteries, making SymPy not necessarily compose well with its ecosystem. In contrast, with Julia we can directly embed within the language with full performance, pervasive multithreading, extendibility from the same language as the user, and composability with a whole package ecosystem. Just take a look at the first example of ModelingToolkit.jl’s paper: > **[ModelingToolkit: A Composable Graph Transformation System For Equation-Based...](https://arxiv.org/abs/2103.05244)** > > Getting good performance out of numerical equation solvers requires that the user has provided stable and efficient functions representing their model. However, users should not be trusted to write good code. In this manuscript we describe... Taking a code for DifferentialEquations.jl, analyzing it, differentiating the user’s 5th expression two times and then substituting in other variables to make a formulation of the pendulum that is more stable, and seamlessly giving back the code. This is done not by going to a different language, but just a single command available to the ODE solver. I admire what previous CAS’s have done for CAS’s sake, but they don’t even attempt to solve this problem. and I think this is the fundamental problem to solve in the 21st century with computer algebra. The 20th century CAS’s like Maple, Mathematica, Maxima, Axiom, etc. solved how to make computer algebra work robustly and efficiently for real-world problems. But now, how can you integrate symbolic algebra directly into programming, [mixing neural network based rewriting heuristics](https://arxiv.org/abs/1912.01412) and [automated code analysis](https://herbie.uwplse.org/) directly into standard computing. Extensions to automatic differentiation should be as simple to write as “transform this code by calculating its Groebner basis and change the array size to the subspace”. I detail this vision and where we are at in a blog post: > **[Generalizing Automatic Differentiation to Automatic Sparsity, Uncertainty,...](https://www.stochasticlifestyle.com/generalizing-automatic-differentiation-to-automatic-sparsity-uncertainty-stability-and-parallelism/)** > > Automatic differentiation is a “compiler trick” whereby a code that calculates f(x) is transformed into a code that calculates f'(x). This trick and its two forms, forward and reverse mode automatic differentiation, have become the pervasive backbone... There is a lot to admire in previous CAS work, but they don’t solve this problem, and I think it’s THE problem to solve. --- _[View the full topic](https://discourse.julialang.org/t/cas-best-practices/58092)._