> PS: Yes, the compiler is quite bad when it comes to throwing appropriate > error messages at you. Sometimes it is not only bad but even the error > can be at a totally different place. In particular, little things like > this missing colon can be hard to debug. >
In that regard I already thought whether it could be better to write the code in Aldor (within FriCAS with the FriCASlib import). I just assume that the compiler is much better, but I could be wrong. But this probably opens a new can of worms, and I'm better off trying to compile "every additional line" or so to immediately catch issues until I'm more fluent with things. Here's some insight into my problem set (with some additional background if you are curious): The start is to solve Feynman loop integrals for higher-order perturbative calculations in quantum field theory (physics). For a given (difficult) perturbative calculation one starts typically with thousands of linearly dependent integrals. These can be reduced to a basis of O(100) integrals, and this itself is a problem involving solving large linear systems with intermediate expression swell. For that purpose solvers with rational function reconstruction have been created, but it can still require a few hundred GB of memory and days of CPU time. Anyway, this is another problem that I am not concerned about here. I am concerned about the actual solution of the (master) integrals, which depend on a few parameters. They satisfy a system of first-order linear ODEs. If the integral basis holds certain properties, it can sometimes be solved analytically in terms of a function class called multiple-polylogarithms. But in general elliptic functions appear and a fully analytic solution is often not feasible. So in my case I want to solve such systems numerically. The problem has lots of subtleties so that I can't use ODE solvers that are readily available (in FriCAS). For large parts of the system I can get a solution in terms of iterated integrals of the series-expanded matrix defining the ODE system. The series expansions are typically around regular singular points and have only a limited radius of convergence. So I need to patch together many series expansions to transport from the boundary condition point to the target point. As for the series, I will have to rely on the most general implementation (GeneralUnivariatePowerSeries) so that I can also expand around logarithmic singularities (series(log(x)*f(x),x=0)). FriCAS seems to handle that well. Integration of such general series is not implemented, so this is something that I am working on. Since the terms in my series expansion are always of the form log(x)^k1 * x^k2, I can take the series Stream, pattern match and plug in the solution. There are also subtleties regarding taking the right branch cut when evaluating the log's and fractional power expressions (it's not always the standard cut), but I think I have an appropriate scheme to handle that. The Stream-type series expansion in FriCAS makes it very attractive to truncate dynamically after some precision goal has been reached. And at some point I will also play around with series acceleration methods (various transformations, conformal mappings). So this part comprises series expansion of sparse matrices (~ 70x70), multiplication with vectors, integration (pattern matching), taking care of correct branch cuts when evaluating the result; patching together multiple series solutions. For a smaller subset of the system (at a later stage) I will need to construct homogenous solutions with the Frobenius method. And this part will be more complicated. The integrals themselves depend on 2-3 parameters and have sharply peaked structures and even singular points in that parameter space. The integrals will also have to be evaluated close to the singularities; both numerical precision and performance matter. At the last stage I need to interface with a Fortran code, or possibly construct an interpolation mesh (or maybe play around with radial basis function interpolation). This depends on how fast the code is and how easy it will be to interface with the Fortran code. Previously people have tackled solving these integrals with Mathematica, but mostly for smaller problems and for testing. For my particular application I need a high-performance implementation that can be deployed on a cluster. For Mathematica there would be a license issue to deploy it on hundreds of cores. And I believe (hope!) that with a FriCAS implementation I can gain some significant speedup compared to a Mathematica implementation. So far my tests seem to indicate that it can handle things quite well and that apart from simple issues with SPAD and the compiler I should have no roadblocks inherent from FriCAS. In principle, one could generalize a lot of things here, but for this specific project I need to be goal-oriented, and the goal (for now) is not to have it neatly generalized into independent mathematical domains and categories. Depending on how well everything turns out I can think about that afterwards, since the method can be applied to other perturbative calculations where the constraints and subtleties can be generalized. Best wishes, Tobias -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CANL0awbZeHWpEF2Hsstenkqc%3DeJF28EB3YRKfS7Sn-w9Ap-ZqA%40mail.gmail.com.
