Ralf Hemmecke wrote:
>
> > in final result so convertion from Expression(Complex(R)) to
> > Expression(R) must properly handle imaginary unit (replace %i by
> > sqrt(-1) if R is real).
>
> Oh... maybe I'm wrong, but AFAIU, the Expression domain is somewhat
> tailored towards a nice representation for integration. It is, in fact,
> something like
>
> K(t1, t2, ..., tn) (*)
>
> where the ti may have relations with the tj for j<i. Unfortunately, our
> Expression domain, does not explicitly show this relations. Waldek, you
> know certainly better than me that the integration code builds this
> tower of fields somehow, but in fact it's always in Expression(R) or
> maybe Expression(Complex(R)). Am I wrong?
Well, we need to look at kernels, so in some places we require domain
of category FunctionSpace(R). ATM HyperDoc says me that there 3 domains
of that category: Expression, JetBundleExpression, JetBundleXExpression.
I do not know if jet bundle stuff would work for integration, but
formally it seem to have needed properties.
> It's probably too much of rewriting to actually get rid of Expression(R)
> in the integration code and let it work with a tower of fields that is
> explicitly constructed for the expression that is to be integrated.
> What I mean is something like this
>
> given integrand -->
> build tower (*) and map integrand to that field -->
> apply Risch's algorithm -->
> transform the result back to Expression(X)
>
> I.e. during Risch's algorith there would be no involvement of
> Expression(X), but only some rational function fields. Isn't that all
> what Risch's algorithm cares about?
I looked shortly at this and I not sure if this is good idea. Parts
of integration code are quite general, for example 'TranscendentalIntegration'
need just a field and few special operations. Algebraic integration
builds its own types which are in some sense independent of Expression.
So actually relatively small part of integration code depends on
special properties of Expression. OTOH in part depending on Expression
(dealing with kernels) rigid structure of type tower would be
inconvenient. In particular, we handle some cases by re-arranging
towers. At several places we perform various ad-hoc extentions.
And we need to see structure of the whole field.
Maybe two examples will explain this better. As I wrote, algebraic
integration uses its own types. The effect is that to use those
routines from other parts of integrator one needs several lines
of setup code (to create types and perform needed convertions).
This makes reuse less convenient and potentially inefficient.
PolynomialFactorizationExplicit is potentially much worse than
old multivariate factorizer, because choice of good evaluation
points is really a global problem, one should choose best of
few evaluation points (with number depending on size of polynomial).
But in recursive structure like our implementation of
PolynomialFactorizationExplicit no sigle layer has all needed
information. Worse, the "best" type for intermediate results
can be determined only after call requesting given result.
--
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.
