Tracing shows the computation diverge at "extendedEuclidean" in
"normalHermiteIntegrate" of TranscendentalHermiteIntegration in
intrf.spad.
The reason that "extendedEuclidean" gives wrong result is that
something wrong happened earlier: there are expressions with
the same appearance but have different kernel underneath.
The creation of different kernels happens at "trigs2explogs"
in "integrate" in integrat.spad.
The definition of "trigs2explogs" seems alright, still it's
unknown why the same input may produce different kernels.
If we replace
gg := eval(gg0, tgg0, tgg1)
in integrat.spad with
gg := trigs2explogs(gg0, [])
then this bug disappears. But I'm still not clear about the
root cause of this bug.
--
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/9382c90f-9d93-a0dc-016e-2f0cda31358b%40gmail.com.
