Re: [Boost-users] [Proto] implementing an computer algebra system with proto

Subject: Re: [Boost-users] [Proto] implementing an computer algebra system with proto
From: Kim Kuen Tang (kuentang_at_[hidden])
Date: 2009-01-30 18:52:56

alfC schrieb:
>> I think the attached program solves that problem.
>>  eq_solver.cpp
>>     
>
>   
Hi Alfredo,

thank for your posting.
> Thank you for posting the compile-time solver code. Specially thanks
> to Eric N. for writing proto and proposing the sketch of the solution.
>
> I few years ago, I tried to experiment writing a mini computer algebra
> in-C++-for-C++. Think for example, if we want to *implicitly* define a
> differential equation in the C++-code to  be solved numerically by any
> existing routine which only takes *explicit* differential equation.
>   
If the grammar is properly implemented than one can easily switch 
between the implicit/explicit and crank-nicholson method.
This is also the reason why i want to implement the algebra-grammar.

> It seems that having Proto now opens the opportunity to enjoyably
> continuing with that project. But I see two problems ahead,  1) The
> (meta-)code is still obfuscated (but may be the best we can do, at
> worst it looks like LISP), 2) Even if we manage to write a fairly
> complete (compile-time) computer algebra there will be two problems
> 2a) the compilation can become really slow if not overflown (compilers
> are not yet optimized to do this kind of job).
yes i see that this can be an issue. But it will also be interesting to 
see how slow the compiler will really become.
(Perhaps we can substitute some grammars using preprocessors to increase 
the compilation time ?)

>  Imagine for example, an
> automatic derivation meta-code, it will create an unmanageable number
> of template-expressions very rapidly. (Think of the fourth derivative
> of sin(exp(x^2)) ) For an automatic integrator is even worst.
>   
especially for calculating the derivate, the method of automatic 
differentiation will help to reduce the numbers of template-expressions.
> 2b) as soon as we want to introduce some run-time aspect to the
> problem, all the static expression-templates should be converted to
> some dynamic-expression.
>
> In case I am not missing something (let me know), it seems that a
> completely compile-time solution is doomed to become unusable except
> for very simple operation and difficult to extend. On the other hand a
> completely dynamic solution is more of what we already have (e.g.
> maple, mathematica, reduce) and will be no better than them (in any
> single aspect), an will not take advantage of compilation
> optimizations (think of interfacing the results with numeric
> libraries)
>
> So I think that a combination of a compile-time solvers and dynamic-
> time solvers is the only way to make something useful and innovative.
>   
I am not sure if this is possible in proto. Perhaps Eric can give some 
comments?

> Say for example, if we transform template expression only to some
> degree during compilation and as soon as the problem becomes too
> complicated (e.g. the expression is too long, or there are many
> expressions in the compilation stack) we let the run-time code handle
> the rest of the problem.
>   
Cheers
Kim