oldk1331 wrote:
>
> > ATM I am looking at the bugs, but I consder shipping next
> > release without fixing them. More precisely, randomness
> > workaround is rather safe so we could ship it. But
> > properly handling other issues may delay release too
> > much.
>
> This will be a maintenance release, version will be 1.3.1?
> Do you mean "randomness workaround" by "reverting to
> previous behavior"?
partialy
> About the continuous bug in ilog, I have a reasonably good
> patch, that will improve the result of non-parametric integrals,
> but it may make some parametric integral non-continuous,
> that can be fixed if the independent variable is passed to ilog,
> which haven't been done.
> Do you think this bug should be fixed in this release?
Probably. The patches looked good, but you lost me what
is the final version. Concerning independent variable,
as I wrote I do not see strong reason to have it as
part IntegrationResult and trying to add it would be
a risky patch. OTOH passing independent variable
form 'integrate' via functions calls leading to
'ilog' seem safe and easy.
Let me say a few words about more general picture. There
are problems with expressions (essentially the recent
example by Kurt Pagani, but it can appear in various forms)
which can be fixed by 'setSimplifyDenomsFlag(true)' and
trying to fix them in different way looks very unattractive.
So it would be good to make it default setting (or the only
one available). However currently with that setting the
testIntegrate("sqrt(tan(x)^2 + 2*tan(x) + 2)", "x", "alg")
in integ.input does not finish after 1 hour (this may be
related to bugs in handling algebraic integrals that
I mentioned in other mail). We sometimes get wrong or
too complicated results due to use of 'real' during
postprocessing of integrals. However it we omit 'real'
we get bunch of test failures. To fix them we need
_selectively_ perform what real was doing. Basically,
we should rewrite new logaritms and new special
functions appearing in the integral choosing if possible
real variant. Probably we need to be extra careful
to avoid unexpected algebraic dependencies or new
constants.
Logaritmic part of integral may contain new algebraic
constants. When such new constants are needed the
simplest and most compact way is to use 'rootSum' expression.
Currently our integrator expands such sums adding
explicit algebraics. What is worse, process of adding
algebraics is done in naive way and in effect result
of integration may contain redundant algebraics
like 'sqrt(p^2 + 4)' and '(p^2 + 4)^(1/4)'. Such
redundant algebraics cause various problems later,
the simplest is that default simplification of
derivative of the integral minus integrad does not
give 0. Unfortunatly 'rootSum' is currently
not handled by definite integrator (actually main
problem is that it is not handled by series expanders
and limit code).
What the above implies for "continuity" patch: for
indefinite integrator main priority is to have good
symbolic properties of integral. Those may conflict
with attempts to avoid branch cuts on rela axis.
Certainly generating 'rootSum' will change what
'tantrick' can do (in a sense 'tantrick' job may
be simpler because it will be called in smaller
number of cases). Avoiding call to 'real' will
change what is done with results of 'expand' and
the whole process will probably change. Currently
it is neatly divided into phases, but early phases
can make work of later phases harder and later
phases can destroy what earlier did. In other
words current code ignores essential dependencies
between phases.
Now, avoiding branch cuts is just a nicety for
indefinite integrator, but essential part of job
for definite integrator. Currently definite
integrator assumes that if there are no
singularites on integration interval, than
primitive will be continuous. But this is
not true for symbolic primitive (due to branch
cuts). Definite integrator knows limits of
integration, so it can do better job of
avoiding branch cuts. In some cases it
is simpler to split integration interval
into subintervals containing branch cuts only
at ends than to try to produce primitve which
avoids branch cuts. Also, definite integrator
knows that it has to deal with branch cuts,
while attemps to get "continuous" primitive
may lead to worse symbolic behaviour in other
applications. So there are good reasons to
move code avoiding branch cuts from indefinite
integrator to definite integrator. In other
words what this code should do probably
will change quite a lot.
--
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.
