recent CAS projects that mentions FriCAS

[Qian Yun]

I find out the following reference to fricas:

https://github.com/yfyang86/maximast/pull/5/

https://github.com/alkahest-cas/alkahest/pull/113

Both projects are less than 2 month old.

Both projects uses Rust.

Both projects are AI assisted.

Are we experiencing a CAS Renaissance or what?!

I haven't tried them out manually yet.

They seem to recognize FirCAS's strong ability in integration
via Risch algorithm, and tries to implement it?

I do hope they succeed, although unlikely.
If they do, we can ask AI to patch up the remaining holes
in Risch algorithm implementation...

- Qian

[Waldek Hebisch]

On Sun, Jun 21, 2026 at 07:26:24PM +0800, Qian Yun wrote:
> I find out the following reference to fricas:
>
> https://github.com/yfyang86/maximast/pull/5/
>
> https://github.com/alkahest-cas/alkahest/pull/113
>
> Both projects are less than 2 month old.
>
> Both projects uses Rust.
>
> Both projects are AI assisted.
>
> Are we experiencing a CAS Renaissance or what?!
>
> I haven't tried them out manually yet.
>
> They seem to recognize FirCAS's strong ability in integration
> via Risch algorithm, and tries to implement it?

In maximast I see reference to thesis by Sutherland. Google search
returns nothing, but title is the same as title of Schultz thesis.
So, it seems that reference is made up (hallucination). It seems
that FriCAS managed to get some recognition for its integration
abilities and LLM-s probably are able to extract this recognition
from data available on the Internet.

More generally, several reports indicate that LLM-s have trouble
with math. So people working on LLM-s are interested in improving
their math capabilities. One way to do this is to use a CAS to
generate a lot of training data. That may explain some interest
in CAS-es among people working with LLM-s. Also, it seem that
there was always non-negigable group of people intereted in CAS,
but doing not much because progress was hard. LLM-s lower
barrier of entry. Also, tasks like indefinite symbolic integration
are testable, which helps in LLM use.

--
Waldek Hebisch

[Ralf Hemmecke]

On 6/21/26 20:04, Waldek Hebisch wrote:

> More generally, several reports indicate that LLM-s have trouble
> with math.

Certainly true. Some have still problems to multiply two big integers.

> So people working on LLM-s are interested in improving
> their math capabilities. One way to do this is to use a CAS to
> generate a lot of training data.

Maybe, one way. But I guess many of these guys now rather implement a
connection to a CAS, let the LLM translate the problem to a CAS-call and
then return the answer from the CAS. That is certainly more reliable. A
CAS does not hallucinate. The hard work is not suddenly useless, just
because LLMs exist.

Ralf

[Dima Pasechnik]

There is quite a bit of activity in creating CAS/formal proof assistants bridges, as proof assistants are nowadays very bad in doing even elementary CAS computations.

see e.g. <https://www.renaissancephilanthropy.org/bridging-proof-and-computation-a-verified-leanmacaulay2-interface>

[Qian Yun]

What's your opinion on maximast/research/survey/ALGORITHM_SURVEY.md ?

How accurate is it?

On the other hand, maximast uses a tree-like structure to represent
expressions, unlike fricas.

Also, it doesn't have Lisp like lists -- without GC, you can't
have Lisp like lists with reference counting. Let's see how far
it can go.

- Qian

[Waldek Hebisch]

On Mon, Jun 22, 2026 at 07:12:30AM +0800, Qian Yun wrote:
> What's your opinion on maximast/research/survey/ALGORITHM_SURVEY.md ?
>
> How accurate is it?

AFAICS it repeats many "known" things, but there are inaccuracies. As
I wrote, reference to Sutherland looks like AI hallucination.

I see no mention of Risch structure theorem. Maybe it is considered
as part of Risch algorithm, but it is usable and important well beyond
integration.

There is mention of our intef.spad and intrf.spad as implementing
transcendental integration, but in fact transcendental integration
needs several files. First there is integrat.spad and efstruct.spad,
before function get to intef.spad. There is intpar.spad (essential
for transcendental completeness) and rdeefx.spad (most deals with
integration in terms of special functions, but it is used also in
elementary case).

The survey repeats old inaccurate claims. The Risch–Norman heuristic
is frequently claimed to be fast and in a sense it is fast: on simple
integrands it runs much faster then expected from simple estimate of
compexity. But take more complicated integand and executation time
grows quite a lot. Both myself and Sympy folks noticed that execution
time grows quite a lot and at least in FriCAS on complicated integands
Risch is faster than Risch–Norman.

I did not look at Maple code (supposedy Maple usere can extract and
see significant part of source code) nor at Mathematica code, so
it is hard to make strong statements. Experiments show that they
do not have full implementation of transcendental part of Risch
algorithm, but IIUC after Risch–Norman fails Maple uses its
version of Risch and Mathematica also uses some version of Risch.

> On the other hand, maximast uses a tree-like structure to represent
> expressions, unlike fricas.
>
> Also, it doesn't have Lisp like lists -- without GC, you can't
> have Lisp like lists with reference counting. Let's see how far
> it can go.

I have noticed that some algorithms initially were implemented for
machine precision integers. That may be enough to test the code,
but in heavier use is going to overflow. And going to arbitrary
precision integers means that they will have to deal with memory
management. IIUC safe Rust is memory safe, that is does not allow
freeing memory when there are references and forces programmer
to free memory when last reference is lost (otherwise the program
will not compile). I wonder how they will handle this: structuring
program so that Rust rules are satisfied looks tricky.

--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Jun 21, 2026 at 09:39:11PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> On 6/21/26 20:04, Waldek Hebisch wrote:
>
> > More generally, several reports indicate that LLM-s have trouble
> > with math.
>
> Certainly true. Some have still problems to multiply two big integers.
>
> > So people working on LLM-s are interested in improving
> > their math capabilities. One way to do this is to use a CAS to
> > generate a lot of training data.
>
> Maybe, one way. But I guess many of these guys now rather implement a
> connection to a CAS, let the LLM translate the problem to a CAS-call and
> then return the answer from the CAS.

That too. But apparently a lot of effort goes into doing all things
inside LLM.

> That is certainly more reliable. A CAS
> does not hallucinate. The hard work is not suddenly useless, just because
> LLMs exist.

For you and me it is natural way. But IIUC people developing LLM
think differently. Apparently for them math is not the end goal,
but rater serves as a test. They hope that improvements on math
will translate to other domains.

--
Waldek Hebisch