On Thu, Mar 08, 2012 at 02:46:17PM +0100, Ralf Hemmecke wrote:
>> "( 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
>> ]
>> )"
>
> Sergei, did you see Fr in my mail?
In my letter it _was written_ that these repeated "Fr" and "UP" in
arg1, arg2 _are not necessary_.
Why do you skip this?
I have set these "Fr" for you to read this easier.
> Didn't you get the point of assigning
> "Z:=Integer;F:=Fraction(Z);..." and then using Z, F, etc in the string
> that would have to be parsed,
In my above format it is visible, that "P" is set in the input 4 times
instead of (UP (Fraction INT)).
I do not understand your first two questions.
> i.e. there is no generic denotation in
> your argument strings (arg1, arg2), but this rather depends on what you
> assign previously to the types, i.e. to Z, F etc.
More precisely, I meant this:
"( gcd -- head function name
[(F = Fr 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
( [3 1 0] [(1 1) (7 5) (4 1)] ) -- arg1
( [9 4 2 0] [(1 1) (-2 1) (-1 1) (1 3)] ) -- arg2
]
)"
It is evident. Because after P is parsed,
_together with its construction_,
it is clear for parseCall that the first list in arg1
is for NNI-s for exponents and the second list is for List Fraction INT.
For example, "(1 1)" in arg1 will be parsed by applying a more special
parseFraction(INT, "INT", "(1 1)").
Because to this moment, parseCall allready expects a fraction over INT.
May be, I am missing something.
But I cannot do these three things in the same time:
1) composing/debugging a program,
2) explaining everything about this,
3) understanding other approaches to this program.
So far, I only asked "how to use named union?"
(and finally have got the answer).
I need 1) to finish this parseCall,
2) to write down its design description -- explanation,
3) to show the result.
And then, I shall try to understand your possible notes of what is wrong
there, and to discuss the alternatives.
Because I have a feeling (it may occur wrong) that mainly the intended
design is all right.
> The reason was that reparsing types is avoided, because all this is done
> at the beginning and done just once.
It is visible from my last two letters, that in my intended program the
types are _not reparsed_.
> Even more is true. If you connect to FriCAS and keep the connection
> open. Then you probably just have to transfer the data once per session.
>
> In other words, you basically talk from Haskell with the FriCAS interpreter.
>
I do not understand this.
I think, it is faster for DoCon to "talk" with
the compiled Spad function parseCall + applying this call +
read/write of Axiom for String and the two _named pipes_.
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.
