4 ms·

From looking at the FriCAS github: "Additionally, FriCAS algebra library is written in a high level strongly typed language (Spad), which allows natural expres

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.
- ywei3410 6y ago
  Regarding your point about dimensions, it really isn't impossible; it requires a little bit of type-level mechanisms, but not very much and quite a few languages already have it. Here are some examples in some languages. The author of Libra (which I /think/ was the first to use this technique) gave a good talk [4] on the mechanism. [1] https://to-ithaca.github.io/libra/ https://to-ithaca.github.io/libra/ (Scala) [2] https://hackage.haskell.org/package/dimensional https://hackage.haskell.org/package/dimensional (Haskell) [3] https://docs.rs/dimensioned/0.7.0/dimensioned/ https://docs.rs/dimensioned/0.7.0/dimensioned/ (Rust) [4] https://www.youtube.com/watch?v=CrwVD0Pco5Q https://www.youtube.com/watch?v=CrwVD0Pco5Q
  - dan-robertson 6y ago
    Ok I guess I concede that it is technically possible in haskell and rust. But note that the way it works in both cases is quite hacks, relying on typeclasses with associated types (ie effectively type-level functions) to fake numbers (up to some maximum), and then representing the dimension of something as a fixed length vector of these numbers. This is fine for dimensional analysis of real world physical things I guess but as soon as you’re trying to look at dimensions of something to see if a calculation makes sense it will fail because there won’t be an appropriate slot in your vector, or will need you to reimplement or modify the hacks. I don’t think it is sustainable to need to jam that kind of trickery into every step.
    - steveklabnik 6y ago
      Rust is getting real type-level numbers in a couple of weeks. It’s just the bare minimum though. More to come in the future.
      - ywei3410 6y ago
        Do you know whether there's going to be any near term support for ordering constraints (i.e. N < M) with the type-level numbers?

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.

ywei3410 6y ago
Regarding your point about dimensions, it really isn't impossible; it requires a little bit of type-level mechanisms, but not very much and quite a few languages already have it. Here are some examples in some languages. The author of Libra (which I /think/ was the first to use this technique) gave a good talk [4] on the mechanism. [1] https://to-ithaca.github.io/libra/ https://to-ithaca.github.io/libra/ (Scala) [2] https://hackage.haskell.org/package/dimensional https://hackage.haskell.org/package/dimensional (Haskell) [3] https://docs.rs/dimensioned/0.7.0/dimensioned/ https://docs.rs/dimensioned/0.7.0/dimensioned/ (Rust) [4] https://www.youtube.com/watch?v=CrwVD0Pco5Q https://www.youtube.com/watch?v=CrwVD0Pco5Q
- dan-robertson 6y ago
  Ok I guess I concede that it is technically possible in haskell and rust. But note that the way it works in both cases is quite hacks, relying on typeclasses with associated types (ie effectively type-level functions) to fake numbers (up to some maximum), and then representing the dimension of something as a fixed length vector of these numbers. This is fine for dimensional analysis of real world physical things I guess but as soon as you’re trying to look at dimensions of something to see if a calculation makes sense it will fail because there won’t be an appropriate slot in your vector, or will need you to reimplement or modify the hacks. I don’t think it is sustainable to need to jam that kind of trickery into every step.
  - steveklabnik 6y ago
    Rust is getting real type-level numbers in a couple of weeks. It’s just the bare minimum though. More to come in the future.
    - ywei3410 6y ago
      Do you know whether there's going to be any near term support for ordering constraints (i.e. N < M) with the type-level numbers?