On Sun, Aug 28, 2022 at 09:04:26PM +0200, Ralf Hemmecke wrote:
> >>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.
>
> Wouldn't it make sense to use Expression just as user interface and when it
> comes to "integrate", take the input expression and construct a proper
> differential field out of if.
My plans goes in this direction. But I am not sure if we agree what
"proper" means.
> As far as I understand the transcendental part
> of the Risch algorithm, one works with differential field s of the form
> K(t1)(t2)...(tn) where tk is an indeterminate such that D(tk) = rational
> function in t{k-1}, ..., t1.
Well, that is for elementary functions. In the recent example
we have Q(x, log(x), log(x+1)) and role of log(x) and log(x+1)
is really symmetric. When dealing with polylogs having to
put one of kernels at the top is inconvenient. And even
in case of elementary functions it is useful to re-arrage
tower in cases when this is possible.
> So at each time
> there is a concrete differential field and it is clear which tk are involve
> and what these tk model. Isn´t it done this way in FriCAS so that the tk are
> represented by the kernels? Or is internally always Expression(...) employed
> and the actual differential field must be read from the expression that is
> involved?
We have mostly expression (algebraic integrator has special type for
curves). In algebraic code there is field of coefficients, main
transcendental and algebraic generator. In legacy code (coming from
Axiom) at each stage structure is read from expression, more
precisely we take field generated by kernels containd in the
expression. This has led to a bug: when recursively calling
integrator we need to find integral in smaller field. But
function to integrate missed some kernels, so Axiom looked
for integral in too small field and falsely declared whole
function as unintegrable. intpar.spad uses different technique:
differential fields are represented by list of kernels which
generate them, so is free from such problems.
I think that using list of kernels is resonable, but I want
add more info and this would be simpler with something
different than Kernel.
--
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/20220828202616.GA1962%40fricas.math.uni.wroc.pl.
