On Sun, Aug 28, 2022 at 11:42:10AM +0800, Qian Yun wrote:
> I'm very interested in 3), expression handling is core to
> the design of CAS. I wonder what's your original idea
> and blocked by what compiler bugs?
>
> I'd like to see improvements on expression, but I have
> no ideas on where to start...
One thing to to have "per expression" kernels. More
precisely, currently Expression serves as a kind of
universal differential field inside which we embed
other fields. This is good as user interface, because
user are spared burden of creating each needed
differential field. But integration, limits and
solvers really should work with differenatial
fields. And they need to build new fields.
Differential fields need more information than
provided in current kernels. For this reason
and for efficiency I would like to avoid current
kernel and use a new one. Basically:
- I want more info in kernels to avoid some searches
and simplify coding
- when creating kernels I want to deal only with
given differential field (and not with all
kernels that happen to live in kernel cache).
That was motivation for KernelCategory, instead
of Kernel one should be able to use any domain
that offers kernel interface. But currently
it breaks when I try to generilize ExpressionSpace
and FunctionSpace, my current try leads to compile
failure later. This is problematic, as I would like
to reuse several packages that currently require
FunctionSpace (so de facto ATM are limited to
Expression).
Another things is "factored expressions". Currently
expressions are rational functions of kernels, normalised
so that algebraic kernels are reduced by their defining
equations. Rational functions are fully expanded.
I would like variant where rational functions are
partially factored. If you look at Rubi testsuite
many epressions are already in factored form.
When input as Expression they get expanded.
That in many cases leads to much bigger expressions
later. At the input in many cases we could restore
factored form and take advantage of known factors
during computation. Of course, to recognize zero
we need to expand. But I feel that there will be
net gain.
I wrote above about differential fields. EFSTRUC
currently helps dealing with fields of elementary
functions (with some extentions to Liovillian
functions). I would like similar functionality
but doing more and covering more functions.
Basically to produce all data needed to convert
given set of expressions into differential
field generated by them and back (plus some
other info to allow more efficient queries
about structure of the field).
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20220828135105.GA30103%40fricas.math.uni.wroc.pl.
