Ralf Hemmecke wrote:
>
> On 07/25/2018 06:23 PM, Waldek Hebisch wrote:
> > Ralf Hemmecke wrote:
> >> 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.
>
> > Well, we need to look at kernels, so in some places we require
> > domain of category FunctionSpace(R).
>
> Wait a minute... maybe you did not understand my transformation business
>
> >> given integrand --> build tower (*) and map integrand to that field
> >> --> apply Risch's algorithm --> transform the result back to
> >> Expression(X)
>
> > I looked shortly at this and I not sure if this is good idea.
>
> I certainly cannot compete with your insight into the whole Risch
> business, but from what I understand from integration or summation
> algorithms, the problem is always first to analyse the integrand/summand
> an build a tower of respective field extensions. In FriCAS that should
> be particularly be easy to do.
Well, tell me what type hipotethical 'to_tower' should have?
At this point I gave up.
> Thus, in the whole integration there are
> no Expression(X) elements anymore. I don't know why it makes sense to
> keep a Expression(X)-element in the middle of the integration algorithm
> although the only thing that is needed are the properties of that
> element. So whether it is sin or cos or acrtan or whatever function, is
> unimportant. They should become indeterminates (plus properties) during
> the translation phase "Expression(X) --> tower of fields".
>
> > 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.
>
> As I said, you know certainly better how the FriCAS integrator works,
> but if I had to implement Risch, I would probably avoid the type
> Expression. Maybe I can only see the problems with this
> no-Expression(X)-approach, if I actually do such an implementation.
Let me put my point of view differently. It should not matter
what types we have as long as the types have needed properties.
And this is reasonably close to truth for current code. It
just happens that Expression has needed properties and there
are no other suitable type. Now the question is what would we
gain and at what cost by using different type? Some costs
are clear: we need to implement new type. Even if this is
just delegating real work to existing code we still need to
write something. More subtle cost is loss of flexibility:
presumably "tower type" would intoduce some contraints and
exclude other types. There is cost of convertions and
instantiation for new types. In particular, very
specific types require substantial effort.
Now, what would we gain?
Maybe better type checking -- but ATM I do not know how
to write tighter type constrants without going into
truble. One would like types which well correspond to
theory. Which means that we need essentially arbitrary
differential fields. Such fields can be represented
as subfields of Expression and we do this in current
code. In other words current code corresponds quite
well with theory, I see little room for improvemnent
here. So essentially I see no gains.
BTW: It is instructive to compare ExponentialExpansion
with MrvLimitPackage. ExponentialExpansion due to
type constraints can do only very special case,
while MrvLimitPackage do not have such limitation.
In principle one could introduce something like
GeneralExpansion and try to rewrite MrvLimitPackage
in terms of this. But we can do what is needed
using existing series types so I see no gain
from such change.
--
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.
