On Wed, Jul 03, 2024 at 02:34:44PM +0200, Ralf Hemmecke wrote:
> It looks like smpeval
>
> smpeval(p, lk, lv) ==
> map(x +-> match(lk, lv, x,
> notfound((z : K) : % +-> map(s +-> eval(s, lk, lv), z),
> lk))$ListToMap(K, %),
> y +-> y::%,
> p)$PolynomialCategoryLifting(IndexedExponents K, K, R, MP, %)
>
> is supposed to apply "eval" recursively.
>
> However, when one analyses what match(lk,lv,x,f) actually does, then it
> means, an extension of the mapping k+->v for any value k in lk by applying f
> if k is not in lk.
>
> Now the f here is this "notfound" function.
>
> notfound(fn, lk) ==
> k +->
> empty? setIntersection(tower(f := k::%), lk) => f
> fn k
>
> and that says: apply fn whenever in the tower of k is an element from lk.
>
> In particular this function will never be applied to any value that is in
> lk, because these are handled directly by "match(lk,lv,x)".
>
> Clearly, "rootSplit" starts with "lk := rootkernels tower x".
> and in "eval(x, lk, [rootExpand k for k in lk])" the values
> are (unfortunately) NOT recursivly computed in case lk is something like
>
> [sqrt(6), sqrt(sqrt(6))]
>
> Thus, in rootFactor(sqrt(sqrt(6)), smpeval is called with
>
> lk = [sqrt(6), sqrt(sqrt(6))]]
> lv = [sqrt(2)*sqrt(3), sqrt(sqrt(6))]]
>
> and it is clear what will happen. The toplevel rational function
> representing sqrt(sqrt(6)) is just k/1 for the kernel sqrt(sqrt(6)).
> So eventually sqrt(sqrt(6)) is replaced by itself and not a recursively
> evaluated value.
>
> I think that this is not what was intended by Bronstein, otherwise, I do not
> (yet) see, why he would have put the "eval" inside the "notfound" call.
>
> That case certainly appears here:
>
> %%% (1) -> rootFactor(log(sqrt 6)*sqrt(sqrt(6)))
> +----+
> +-+ +-+ | +-+
> (3) log(\|2 \|3 )\|\|6
>
> I find it strange that substitution inside log does happen, but not inside
> sqrt.
>
> Opinions? Should I try to come up with a proper fix?
> I somehow feel such a change will have quite some consequences in different
> part of FriCAS.
Impact should be limited. Functions in AlgebraicManipulations are
mostly "user level" functions. It seems that 'ratDenom' and
'rootSimp' are called from rest of algebra. IMO we should get
rid of calls to 'rootSimp' (instead extend normalization to handle
algebraic kernels). As you noticed 'ratDenom' may be unreliable,
so probably we should replace is by something else in most of algebra.
Concerning 'rootSplit', it make sense to create better implementation.
My impression is that original AlgebraicManipulations just used
very simple tricks to get functionality similar to what other CAS-es
offerd. But it was very limited. There are now some extentions
and enhancements, but it is still limited.
--
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/Zoa0q91FBxUIFcTz%40fricas.org.
