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