On Wed, Nov 16, 2011 at 07:57:14PM +0100, Waldek Hebisch wrote:
> 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.
> >
> > 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
> Input is first parsed. Typechecking is intertwined with compilation
> or interpretation, given part is typechecked first and than
> interpreted or compiled.
>
> > 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.
I think cost(parse) = 20*cost(copy) is small, because it is
smaller on average than the target library function evaluation. Because
all the heavy-weight functions have complexity O((argument zise)^2)
and higher.
But I do not understand your note about "binary", how can a Haskell
function prepare a binary data for Axiom to parse?
Anyway, I see from your response that the approach with sending the
Lisp data will not do.
On the other hand, I believe now that I know how to satisfactory reduce
the cost of the text parsing, at both ends in DoCon and in Axiom.
Introduce to DoCon the class
class AxiomParse a where toAxiom :: a -> String
fromAxiom :: a -> String -> a
and its instances for the constructors
Vector, Matrix, Pol, Fraction, Residue, ... used in DoCon.
toAxiom produces such a string which can be fast parsed by Axiom.
fromAxiom sm str
parses a string to the DoCon element of the domain of the sampe sm,
where str is certain string which is easy to parse by DoCon.
Similarly, Category DoConParse(a) {fromDoCon : String -> a,
toDoCon : a -> String}
is added to the Axiom library
(the Spad syntax needs correction),
with is instances corresponding to the instances for AxiomParse.
The operation instances for toAxiom, fromAxiom, fromDoCon, toDoCon
provide fast parsing at both ends.
For example, for an integer polynomial f, DoCon will send not
the string "(x^2 + 4*x*y + 5*y^3)" but something like
"Pol Integer (Vars "x" "y") (Mons (1, [2,0]) (4, [1,1]) (5, [0,3]))"
-- may be, with additional tags, to make possible fast parsing in Axiom
by the operation fromDoCon. Parsing this to Axiom does not need to
check operation arities, precedence, types etc.
And the instances for fromDoCon need
to be programmed respectively in Spad, compiled and joined to the librray.
Similary, if res is an integer polynomial in Axiom, then
toDoCon res is not "(x**2 + 4*x*y + 5*y**3)" but
"[(1, [2,0]), (4, [1,1]), (5, [0,3])]"
-- may be with additional tags. So, fromAxiom will parse this fast,
because the string is fully prepared, tagged.
The linear cost for parsing is considered as very good.
There remains only the question of the repeated input-output in the
"middle" of a Haskell function, I believe, something must be possible,
need to look into this.
Regards,
Sergei.
[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.
