On Wed, Mar 07, 2012 at 10:40:25PM +0100, Ralf Hemmecke wrote:
>> String -> Type
>> String -> parser function
>> String -> encoder function
>> (String, String, List(String)) -> application funnction
>
> Waldek, I like that. It somehow reminds me of
> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/algebra/src/extree/sit_extree.as
> But, in fact, in some sense your approach is more general.
> Anyway, if Sergei is able to prepare the string that is sent to fricas,
> one could prepend each item with the (FriCAS) type it should belong to
> and *a parse function from this type* would then parse and read the next
> item. And such parse functions could call parse funcions from other
> types recursively.
>
> [..]
>
I thank Waldek and Ralf for thier advices.
1. I am in the middle of the attempt with parseCall, and need to finish
it. Then, I shall a) show the source and description,
b) ask for comments, c) think of your suggestion.
Most my time is spent not to the design, nor to real programming, but to
studying Spad. For example, to find a usage of tagged union has taken
of me about 12 hours of attempts, even with your help.
2. I knew that parsing a domain must, probably, be by constructing it
from a table of assignment inputs. Because domains may repeat and may
have large common parts.
3. Currenly, I keep in mind the input like the following.
Consider the call
UPol := UnivariatePolynomial(x, Fraction Integer)
gcd(3/4*x^3 +7/5*x +4, x^9 -2*x^4 -x^2 +1/3) $UnivariateGcd(UPol)
-- let gcd and UnivariateGcd be contrived, I do not know whether
such exist in Axiom and whether they are needed in reality.
It is sent to parseCall as
"( gcd -- head function name
[(F = Fraction INT) (P = UP x F)] -- table of type input
P -- returned type input
[P P] -- argument list input
(UnivariateGcd P) -- package call input
[ -- argument input list
(UP [3 1 0] [(Fr 1 1) (Fr 7 5) (Fr 4 1)]) -- arg1
(UP [9 4 2 0] [(Fr 1 1) (Fr -2 1) (Fr -1 1) (Fr 1 3)]) -- arg2
]
)"
Here <UP input> ::=
"(" "UP" <exponent list input> <coefficient list input> ")",
"UP" and "Fr" are not really necessary here in arg1, arg2,
as it is visible below.
After lexLots, parseCall deals with
["(", "gcd" ... "P", "UnivariateGcd" ... ] : LexList ==> List String
First, the types F and P are parsed from the table input.
Each type is parsed to
Product(Type, DomainConstruction)
Then, arg1 is parsed by
parseElem(P, PConstr,
lexLots "(UP [3 1 0] [(Fr 1 1) (Fr 7 5) (Fr 4 1)])"
),
where P : IntegralDomain = UP(x, Fraction INT),
PConstr : DomainConstruction = UP x (Fr INT)
-- a member of a certaing tagged union.
And so on.
4. The next generalization will be needed:
parsing ResidueRing(R, Ideal(f_1...f_n))
involves parsing the elements f_i of R.
5. After observing my parseCall, you can write you own improvement,
may be, designed totally by new.
If it occurs considerably faster, I hope to be able either to continue
it or to formulate what is neeeded to cover the DoCon needs.
I also need to do a) DoCon --> String for Axiom,
b) Axiom result --> String for DoCon,
c) fast parsing in DoCon (not done yet!).
All that I see now is that FriCAS has unnaturally slow parsing of
algebraic data, which makes the String interface almost useless.
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.
