On Sun, Feb 5, 2017 at 12:00 PM, Waldek Hebisch
<hebi...@math.uni.wroc.pl> wrote:
> 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.
1. Even after substitutions, there still should be an independent
variable.
2. So we should add a slot to the Rep of IR, and main
integration code should tells it.
3. In the Rep.nelem, there's already "intvar : F"
4. There's a need to know about the independent variable, see:
SIGMA
2
%F - 4%F + 15 = 0
,
%F
*
log
y x
- 10%e - 10%e - 3
------------------- %F
80
+
y 2 x y x 2 x
80(%e ) + (160%e + 30)%e + 80(%e ) + 30%e - 3
--------------------------------------------------
80
Type: IntegrationResult(Expression(Integer))
Is x the independent variable and y the parameter, or vice versa?
> 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).
I looked at test results, there are no unexpected failure caused
by this patch, I think? (I just run make in src/input, then 'grep
"unexpected failure" *output')
> 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.
Other parts of integration already use 'sign'.
> Some more general remarks/questions:
>
> - you made several proposals. Should this patch go together
> with other or is it supposed to replace them?
I though this would be a relatively simple bug, but it turns out
that there are servel bugs. This patch should go together
with other, but some integrals will only be fixed by both patches.
> - 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.
But current implementation of 'sign' is determinated (I think),
it limits the depth of recursion. And I didn't try to solve the general
case, the simple ones require "IR has an independent variable".
> - 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.
I totally agree. I think this change only results the difference
between "atan(a/b)" and "atan(-b/a)", and the change will
improve the reuslt's continuity.
> - 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.
I think this change fit your requirement.
> - 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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
