I'm very interested in 3), expression handling is core to
the design of CAS. I wonder what's your original idea
and blocked by what compiler bugs?
I'd like to see improvements on expression, but I have
no ideas on where to start...
- Qian
On 8/28/22 09:46, Waldek Hebisch wrote:
This is to let you know about my developement plans. With
little details, as details would make it much longer.
1) Numeric special functions. I wrote few month ago about
Bessel functions, there is some progress here, few pieces
are commited, few other wait as they depend on to be
written parts. Eventually this will replace 'sfsfun.boot'.
1a) There is also old work I did on numeric elliptic functions.
While what is commited is quite good, there are some problems
to fix and a few functions are missing.
2) I would like to rework our polynomial system, more preciely
factorization and GCD. I have found scheme which I consider
quite promising. It starts from some old ideas of von zur
Gathen and Zippel with some newer additions. The exact
combination is probably new. I hope that this will give
quite good perfomance. Drawback is that it is substantial
work to implement and speed strongly depends on speed of
low level routines.
2a) There is new univariate factorizer over finite fields. Recently
commited version in principle can handle all finite
fields. There is some benchmarking to do, but there
is good chance that 'moddfact.spad' is reduntant now
(new factorizer can factorizations done by 'moddfact.spad',
but benchmaring is need to verify check for possible
slowdowns). Also, for general finite fields new
factorizer should be more or less as good as 'ddfact.spad'.
But in case of algebraic extentions there is faster method
which I want to add. And there is some work needed on
low level routines for important special cases.
Actually, some low level routines should be usable
in general multivariate code, so I will probaly finish
this before doing serious work on multivariate case.
3) I would like to reorganize our expression machinery.
Unfortunately my original idea is blocked by bugs
in Spad compiler. So so I am looking at alternative
plans.
3a) Change in expression handling is needed for integrator,
it should improve speed and make solution to some
problems easier. In particular with changes expression
structure it would be easier to solve problems caused
by 'real'
3b) Our limit code needs improvement. Currenly mrv_limit
uses Gruntz method, which has some performance problems
and does not handle all functions. I think that I can
improve speed and handle more functions (in particular
all correctly handled by old limit). But this needs
reorganization which would be easier if changes to
expressions machinery are done first.
3c) I would like to improve our ODE solver and transcendental
equation solver. For nonlinear ODE-s I have proof
of concept code which handles well some popular classes
of equations. But it needs work to finish. In case
of transcendental equations we probably could easily
improve equations solver quite a lot, but still,
there is some work to do.
3d) As you probably noticed I spent a lot of effort on
integrator. I plan several changes, but I also
want to improve other parts of FriCAS.
4) Spad compiler and interpreter. I have long term plans for
both, but major improvement to Spad compiler can not be
done quickly and bigger changes to interpreter should be
coordinated with complier. In short term I limit work
on compiler and interpreter to bugs fixes, instead spending
most time on points above.
BTW: In last severel years various things caused me to spent
less time on FriCAS that I would like to. I hope for best,
but just when I hoped that things will go better we got
Covid...
--
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/18327cb5-1fd8-2051-1064-25d47a0d3941%40gmail.com.
