oldk1331 wrote:
>
> On Sun, Feb 5, 2017 at 12:00 PM, Waldek Hebisch
> <[email protected]> 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"
This is needed because nelem part is an integral, but represented
by function under integral.
> 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?
I do not understand why should I know this. Logically IntegrationResult
is just alternative representatin of expressions. Specifically,
it has special representation for logarithms and allows arbitrary
Liouvilian term (nonelem part). This is not much different than
integrand. For integrand we do not put independent variable as
part of representation. Instead we pass independent variable
as an extra argument. ATM I do not see why passing independent
variable as separate argument should be worse than having
it as part of representation.
Just an extra speculation: in principle we could look at integral
of 1-form. To have integral in such case there is compatibility
condition, assume that it is satisfied. Then we could use
methods like for single variable integration, but we would have
several independent variables. AFAICS current IntegrationResult
would work for such generalized integration procedure. But
instead of single integration variable we would have list of
variables.
To put this differently: ATM is seems that independent variable
is independent from IntegrationResult so handling it separately
seem better.
> > 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')
I mean text output: diffing output before and after change I
see several changes to results of 'mapleok' (those are nastly
examples that cross branch cuts).
> > 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'.
It is not clear if they should. One use is to avoid
square roots of negative numbers, partial justification
is that whithout that we could get completely wrong
integrals (zero instead of nonzero integral). Note
that while some people make a lot of fuss about branch
cuts, that is realy indepenent task from integration.
In particular given algebraically correct result
one can transform it to change branching effects.
If we get algebraically incorrect result, that
is plainly wrong and no further postprocessing will
help. And to clarify a bit: I definitely want
algebraic correctness of integral to be independent
of determining sign, but there are dependencies that
we inherited and it will take long time to untangle
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.
>
> 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".
'sign' may fail. And before failure/success it can take a lot
of time.
--
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.
