22 ms·

CASes are one of the most difficult things to write and they’re never complete. There are always bugs, performance concerns, anemic mathematical domains, etc. E

CASes are one of the most difficult things to write and they’re never complete. There are always bugs, performance concerns, anemic mathematical domains, etc. Every major free or commercial CAS that’s still in use is under active development to battle these inadequacies. Dozens of CASes have come and gone in the past 30 years, the majority of which have bitrotted or stopped being maintained. And not a single CAS has reigned supreme as the CAS that beats all CASes. It’s very exciting to see more work in CASes being done, but I worry that “starting a CAS from scratch” isn’t the right approach. The Axiom [0, 1] project rightly identified that building a general-purpose CAS for working practitioners of computational mathematics is an effort requiring nearly generational timespans [2], and that you must have the right language to describe mathematical objects and their relationships. They had a literate programming policy, where all math code must be accompanied by publication-quality documentation, precisely because it’s so hard to build and maintain these systems. Some of the greatest computational discoveries and expositions came out of the development of Axiom, like the richest and most complete implementation of the renowned Risch algorithm for doing symbolic integrals. Axiom fell into disuse for a variety of reasons, but from my perspective, found new life in a fork called FriCAS [3, 4], which is actively developed and allows a more “software engineer friendly” approach to the development of the system. The code they have is enormously complex and has mountains of knowledge from foremost experts in computer algebra. I really wish new computer algebra initiatives attempted in earnest to make use of and extend Axiom/FriCAS so that we could continue to build up our knowledge of this exceedingly delicate and tricky subject without constantly starting from zero. Axiom has a manual that is over 1,000 pages of dense mathematics and that’s really hard to rebuild correctly. (The only project I know who honestly tried to build upon and subsequently extend CAS functionality is Sage [5], which builds upon a plethora of existing open source general-purpose and specialized computational math systems.) [0] https://en.m.wikipedia.org/wiki/Axiom_(computer_algebra_system) https://en.m.wikipedia.org/wiki/Axiom_(computer_algebra_syst... [1] http://www.axiom-developer.org/ http://www.axiom-developer.org/ [2] Quote from Axiom manual (http://fricas.sourceforge.net/doc/book.pdf http://fricas.sourceforge.net/doc/book.pdf): > With that in mind I’ve introduced the theme of the “30 year horizon”. We must invent the tools that support the Computational Mathematician working 30 years from now. How will research be done when every bit of mathematical knowledge is online and instantly available? What happens when we scale Axiom by a factor of 100, giving us 1.1 million domains? How can we integrate theory with code? How will we integrate theorems and proofs of the mathematics with space-time complexity proofs and running code? What visualization tools are needed? How do we support the conceptual structures and semantics of mathematics in effective ways? How do we support results from the sciences? How do we teach the next generation to be effective Computational Mathematicians? The “30 year horizon” is much nearer than it appears. [3] https://en.m.wikipedia.org/wiki/FriCAS https://en.m.wikipedia.org/wiki/FriCAS [4] http://fricas.sourceforge.net/ http://fricas.sourceforge.net/ [5] https://www.sagemath.org/ https://www.sagemath.org/

UncleOxidant 6y ago
From looking at the FriCAS github: "Additionally, FriCAS algebra library is written in a high level strongly typed language (Spad), which allows natural expression of mathematical algorithms." One could argue that Julia also allows natural expression of mathematical algorithms. Coupled with Julia features like multiple dispatch, high performance (due to Julia's LLVM backend) and growing ecosystem of AD and ML libraries, it seems like Julia is probably the more “software engineer friendly” approach at this point. It doesn't seem odd that the Julia folk would want to implement their CAS in Julia. That's not to say that maybe bridges from Julia to FriCAS couldn't be built as has been done with both R and Python.
- reikonomusha 6y ago
  Axiom, in its original commercial incarnation, took 20 years to build. My comment meant to suggest not spending another 20 for the dubious promise of a bit of additional “software engineer friendliness”, which is why FriCAS forked Axiom instead of building one from scratch.
- ChrisRackauckas 6y ago
  We definitely can, should, and will interface with it. There's no reason to throw away great work. Just like how DifferentialEquations.jl always had a focus on pure Julia solvers, it made sure to wrap every solver it could. Building such wrappers is required for good research anyways, it's required for both timing and calculating efficiency in other ways (like amount of simplification or percentage of integrals solved).
- dan-robertson 6y ago
  There are lots of things which may go wrong trying to make a mathematics fit into a type system. In particular you need a particularly general typesystem. I think Julia has a better chance than haskell/rust/ml (let alone C++) because types are less rigid so functions may return values of types that are functions of the arguments. The difficulty is subtyping. For a trivial example, the integers under addition form a group. But they also form a ring, which is that group plus a different monoid structure (and extra rules), and the real numbers form a field (two connected groups with extra structure) which meets with the ring structure of the integers. If I write an algorithm about groups, I want a way to be able to apply it to the additive or multiplicative groups of the reals. You need the ability to easily talk about forgetting extra structure but then taking results back from the simpler structure. Another example is dimensions. It is, as far as I know, basically impossible to encode something like “force (ie mass times distance per time squared) divided by time is commensurate with current times voltage” in a type system like that in ocaml/haskell/rust (you can maybe do it with c++ but the compiler can’t check that your template is correct) The next problem with general algorithms is that there are isomorphisms and then there are isomorphisms so things that work in mathematics (this group is cyclic and g is a generator so for my element h, there is some integer a such that g^a=h) are sometimes infeasible on computers (the process described above is trivial in integers under addition, hard in integers mod p under multiplication, and very hard in elliptic curve groups (of rank 1), even though they are all cyclic). I don’t think these are reasons not to try and I think Julia feels like a good language for a combination of performance and interface ergonomics, as well as the library being useful in the ecosystem of other scientific or mathematical libraries.

UncleOxidant 6y ago

From looking at the FriCAS github: "Additionally, FriCAS algebra library is written in a high level strongly typed language (Spad), which allows natural expression of mathematical algorithms." One could argue that Julia also allows natural expression of mathematical algorithms. Coupled with Julia features like multiple dispatch, high performance (due to Julia's LLVM backend) and growing ecosystem of AD and ML libraries, it seems like Julia is probably the more “software engineer friendly” approach at this point. It doesn't seem odd that the Julia folk would want to implement their CAS in Julia. That's not to say that maybe bridges from Julia to FriCAS couldn't be built as has been done with both R and Python.

reikonomusha 6y ago
Axiom, in its original commercial incarnation, took 20 years to build. My comment meant to suggest not spending another 20 for the dubious promise of a bit of additional “software engineer friendliness”, which is why FriCAS forked Axiom instead of building one from scratch.
ChrisRackauckas 6y ago
We definitely can, should, and will interface with it. There's no reason to throw away great work. Just like how DifferentialEquations.jl always had a focus on pure Julia solvers, it made sure to wrap every solver it could. Building such wrappers is required for good research anyways, it's required for both timing and calculating efficiency in other ways (like amount of simplification or percentage of integrals solved).
dan-robertson 6y ago
There are lots of things which may go wrong trying to make a mathematics fit into a type system. In particular you need a particularly general typesystem. I think Julia has a better chance than haskell/rust/ml (let alone C++) because types are less rigid so functions may return values of types that are functions of the arguments. The difficulty is subtyping. For a trivial example, the integers under addition form a group. But they also form a ring, which is that group plus a different monoid structure (and extra rules), and the real numbers form a field (two connected groups with extra structure) which meets with the ring structure of the integers. If I write an algorithm about groups, I want a way to be able to apply it to the additive or multiplicative groups of the reals. You need the ability to easily talk about forgetting extra structure but then taking results back from the simpler structure. Another example is dimensions. It is, as far as I know, basically impossible to encode something like “force (ie mass times distance per time squared) divided by time is commensurate with current times voltage” in a type system like that in ocaml/haskell/rust (you can maybe do it with c++ but the compiler can’t check that your template is correct) The next problem with general algorithms is that there are isomorphisms and then there are isomorphisms so things that work in mathematics (this group is cyclic and g is a generator so for my element h, there is some integer a such that g^a=h) are sometimes infeasible on computers (the process described above is trivial in integers under addition, hard in integers mod p under multiplication, and very hard in elliptic curve groups (of rank 1), even though they are all cyclic). I don’t think these are reasons not to try and I think Julia feels like a good language for a combination of performance and interface ergonomics, as well as the library being useful in the ecosystem of other scientific or mathematical libraries.