oldk1331 wrote:
>
> I think I have found a good enough solution:
> by using "sign" from ElementaryFunctionSign,
> it's already imported by IR2F.
>
> I also find a new problem: IntegrationResult doesn't
> even track the independent variable!
Well, what is independent variable depends on point of view.
In particular, it changes after substitutions. So
IntegrationResult can know independent variable only if
main integration code tells it. But ATM IntegrationResult
has no need to know.
> diff --git a/src/algebra/irexpand.spad b/src/algebra/irexpand.spad
> index 3e1ca4f7..7ed8ea5a 100644
> --- a/src/algebra/irexpand.spad
> +++ b/src/algebra/irexpand.spad
> @@ -104,6 +104,12 @@
> -- they differ by a constant so it's ok to do it from an IR
> tantrick(a, b) ==
> retractIfCan(a)@Union(Q, "failed") case Q => 2 * atan(-b/a)
> + sa := sign a
> + sb := sign b
> + if sa case Z and sb case "failed" then return 2 * atan(-b/a)
> + if sb case Z and sa case "failed" then return 2 * atan(a/b)
> + -- if sa case "failed" and sb case "failed" then
> + -- print("potentially noncontinuous"::OutputForm)
> 2 * atan(a/b)
>
> -- transforms i log((a + i b) / (a - i b)) into a sum of real
>
Have you looked at test results? AFAICS there are several
changes (I did not have time to examine them more carefully).
I would expect improvement, but sometimes effects
of changes are surprising (in particular sometimes improvement
on real line lead to strange things in complex plane).
Somewhat related: 'sign' may be quite heavy. Usually it
is fast enough but it would be good to check large number
of examples for possible increase in execution time.
Some more general remarks/questions:
- you made several proposals. Should this patch go together
with other or is it supposed to replace them?
- as I wrote in other message in general problem has no
solution -- there may be no way to avoid crossing conventional
branch cuts. Also, when there is solution it may be uncomputable
because it depends on sign and determing sign is uncomputable
for elementary functions.
- without sufficient information improvements for some functions
may lead to worse result for other. IMO it is important
to limit bad effects and hence limit changes which are not
clear improvement.
- avoiding branch cuts is really task of definte integrator.
In particular results may depend on integration interval
which is unknown to indefinite integrator. So we want
to do a few hopefully cheap things which give clear gain,
but avoid changes otherwise.
- from symbolic point of view it is important to have minimal
number of independent kernels. Current integration code
may easily introduce redundant kernels. Avoiding them
will need an extra pass similar to 'normalize'. Such
pass will interact with expansion of logarithms. In
particular will limit legal transformations of logarithms.
Current ones (Rioobo and tantrick) are probably OK, but
some other are excluded.
--
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
