Serge D. Mechveliani wrote:
>
> On Sat, Nov 12, 2011 at 10:06:23PM +0100, Ralf Hemmecke wrote:
> > Instead of answering your questions in detail, how do you want to access
> > the axiom library?
>
> For any occasion: this may will be only 20-30 concrete functions in
> the Axiom library to which the interface is needed.
> For example, about 95% constitute the functions such as
> lc, lm, cont, coefficientToPolynomial, multiplyPolynomials ...
> which are not needed, because DoCon has such of its own.
> The interface is needed only to 20-30 concrete heavy-weight functions,
> which set we call InterfFuncs =
> {factorPolynomialOverInteger, factorPolynomialOverSuchAndSuchField,
> solvePolynomialSystem, itergateSymbolically, sumSeries ...
> }.
I think you underestimate number of "interesting" functions.
There is about 6000 functions in the library (counting
overloaded functions separately). 95% is of trivial kind,
but 5% still gives 300. Also, one aspect of "power" of
library is that many such trivial functions are already
defined.
If you are satisfied with interfacing only to selected
family of "heavy" functions, then you may consider
socket interace: have FriCAS running as separate
process and interchange data via sockets. You need
to write routines to pack and unpack data on both
sides of connection, but it is probably less work than
other approaches.
> Probabbly, Spad compiles into some v-machine which is some slight extension
> of Common Lisp with some non-functional operations (?).
> Let us call it Lisp-ext.
> Let us suggest, so far, for simplicity, that we have wrote an interpreter
> of Lisp-ext in Haskell
> (the question is: how to interpret the code made from setelt!(a, 5, 1) ?).
setelt! takes old state and returns new state -- inelegant but
purely functional. Bigger challenge is to make sure that it
is efficient enough -- state is likely to be large, and new
state differs only slightly form old state.
With smart translation technique you could try to minimize
state -- in many cases destructive functions simply produce
new data discarding old one. However, doing so automatically
is not easy, so probably would cost a lot of work.
> The interface needs to be defined individually for each function f from
> the set InterfFuncs. This interface is found by manually writing in Spad
> the corresponding function declaration for f, applying the Spad compiler
> to it and considering the obtained Lisp-ext code.
>
> The greatest obstackle is, probably in that the functions in IterfFuncs
> have many destructive function calls in their code: updating a position
> in a matrix, and such.
> So, the project looks as not realistic.
> It may have sense to find among IterfFuncs the functions which Spad
> source can be easily freed of destructive things. But probably, noone
> will occur easy.
Most higher level FriCAS functions have purely functional
interface. But efficient routines typically use destructive
update at low level. If you go down to Lisp level, then
eliminating destructive things will be harder, because
much of semantic information is lost.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
