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. 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. Ralf -- 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.
