Serge D. Mechveliani wrote:
> 
> On Wed, Nov 16, 2011 at 02:08:45PM +0100, Waldek Hebisch wrote:
> > 
> > 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.
> 
> I am thinking of this. I do not know what is a socket.

Sockets were invented for network interfaces.  But they can
be used without network to exchange data between programs
without need for temporary files.  For start see:

http://en.wikipedia.org/wiki/Berkeley_sockets

> But let it be say, a file  call.txt
> 
> The haskell function applies 
>                              
>     factorPolynomialOverInteger f =  
>       let 
>           str = concat ["res = factorPolynomialOverInteger_axiom ", 
>                         show f, "; writeToFile \"result.txt\" res"
>                        ]
>       in  putString "call.txt" str
> 
> (a contrived code, needs correction)
> This puts the string printing of the Spad program
> 
>           res = factorPolynomialOverInteger_axiom <f>;
>           writeToFile "result.txt" res
> 
> (a contrived code, needs correction) to the file  call.txt.
> 
> The Axiom dialogue process is perpetually run and performs the command 
> 
>           loadFromFileAndEvaluate "call.txt"
> 
> When the end symbol of input appears in  call.txt,
> loadFromFileAndEvaluate  starts, the input in  str
> (1) is parsed, 
> (2) compiled to Lisp  (?),
>     (is the representation for  f  converted further than the Lisp data?)

Simple operations are just interpreted, it is faster than compilation.

> (3) type-checked,
> (4) interpreted, 
>     but  factorPolynomialOverInteger_axiom  is applied as a binary, 
>     because it is kept in the library as already compiled to binary,
>     the result  res_lisp  (Lisp representation for a list of polynomials) 
>     is produced,
> (5) the printing of  res_lisp,  with conversion to ..., it put to  
>     result.txt
> 
> It this true? Please, comment this. 
 

Input is first parsed.  Typechecking is intertwined with compilation
or interpretation, given part is typechecked first and than
interpreted or compiled.

> There are the following questions.
> 
> 1. The client Haskell function may need to apply many times writing 
>    to a file and reading from a file, and using the read value.
>    I never wrote such functions (which do not look functional) in 
>    Haskell, except a trivial one "repeat input-evaluate-output".
>    May be, this can be arranged, may be by using the C interface ...
>    let us hope.

IIUC your original description suggested using separate file
for each expression, but this is unnecesary.
 
> 2. One needs to avoid parsing in Axiom and in Haskell, and to avoid
>    as much type check and compilation as possible.
> For example, parsing  
>              "factorPolynomialOverInteger_axiom (x^2 + x*y + y^3)" 
> 
> and compiling to Lisp is, probably, much slower than its proper evaluation.

Parsing text is slow, if it is too slow depends on your usage
scenario.  I was thinking about sending data encodend in binary.
For some simple types such data can be parsed at cost comparable
to cost of copy.   In for more general types I would expect
parsing biary representation to be order of maginitude more
expensive (that is about 10 times) than copy.  

> On the other hand, I believe, I know how to directly produce from Haskell
> the Lisp data corresponding to  f :: Pol Integer  
> (and for many other data too),
> can write this conversion in Haskell (in both directions)

Stricly speaking "Lisp data" is binary data allocated in memory
space managed by Lisp and known to Lisp garbage collector.
Some people enjoy handling raw memory they probably would
dare to "directly" create it, but most folks (and what you
wrote indicates that you belong to this majority) regard
creating Lisp data without using Lisp as impossible.

In other words you call supplied constructor functions and
they create data you want.  Theoretically, you can call
Lisp functions, but calling Spad functions should be
more convenient.

> This needs to use a knowledge of how the data are represented in Axiom-Lisp 
> for each of the constructors
> Vector, Matrix, Pol, Fraction, Residue, ...  used in DoCon
> I believe, this can be studied and used in conversion.
> 
> But how to put this Lisp data to the memory  buffer  for the call 
> evaluation at the Lisp data level in Axiom?  Does such a buffer exist?
> How to directly envocate the interpreter (Boot ?) with the Lisp data?
> Will this save much of the performance cost?
> 


As I wrote, puting Lisp data direcly into memory is hard.  But
you can pass streams of bytes either via sockets or via C
interface.  On one end you encode, on the other decode.

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

Reply via email to