Ralf, your wrote about GitHub. I wanted to upload there, but it occurs that it is needed to install a certain program, etc. Too much to study in the same time.
http://botik.ru/pub/local/Mechveliani/axiQuest/DParse-0.02.zip contains a fresh dParse -- for parsing element + domain. See readme.txt and comments. If you provide your code, then you can either give a link or just send me an archive in an e-mail attachement. Will this do? > It'll take me some time to delve into it and since I > am busy with other things, I'll probably not have a helpful comment on > the code before Sunday. I can wait. Meanwhile can do my attempts. > Another idea would be the following. There is a rather big freedom of > what you send from Haskell to FriCAS. In recent mails you've already > included type information. > > What about starting with just simple functions. I.e. from Haskell you > send (a more parse-friendly string) of > > a1: T1 := v1; a2: T2 := v2; r: T := f(a1, a2)$P; r::OutputForm > > v1 and v2 would be simple values like Integer, Float or String (nothing > complicated like polynomials). But how to input, for example, a polynomial f : UP(x, INT), UP(x, Fraction INT) ? > In fact, you can send something like a well designed *.input file to > FriCAS and let the FriCAS parser do the hard work. > > You said before that this is too slow. Is it already too slow to parse > and call a function in case T1=T2=T=Integer? I thought of this. In dParse I control everything. And it is difficult for me to control parse * interpet by FriCAS (please, look into testParse.spad). Eample: In DParse-0.02, (4*x^3 + 5*x - 6) : UP(x, INT) is input as "(UP x 1 [3 1 0] [4 5 -6])" After "(", "UP", "x", it finds: f : UP(x, D), D to be found. After "1", it finds that D = Integer. Then "[3 1 0]" is parsed to the list of NonNegativeIntegers -- exponents, "[4 5 -6]" is parsed to the List Integer -- coefficients. Then the exponents and coefficients are zipped with the `monomial' function, and the monomial list is coerced to f : UP(x, INT). In the input, the exponents are already ordered as needed. The whole algorithm is _linear_. UP(x, Fraction INT) is similar, and so on. Why do you think that a1: T1 := v1; a2: T2 := v2; r: T := f(a1, a2)$P; r::OutputForm is cheaper? I suspect that in both programs computing domains takes a considerable cost. > and let the FriCAS parser do the hard work. 1) Look into dParse : String -> ... in DParse-0.02. There is no hard work. A hard work is studying Spad. For example, I define Rep := Union(dConsBasic : Symbol, dConsFr : %, dConsUP : UPCons), and now think: how to coerce "INT" :: Symbol to Rep, as dConsBasic ? So far, I fail. 2) In " a1: T1 := v1; a2: T2 := v2; r: T := f(a1, a2)$P; r::OutputForm", FriCAS will do parse * interpret. I expect, dParse is 10 times faster. Also I need to find out whether it can be done 50 times faster, some optimizations. On Mon, Mar 05, 2012 at 09:23:26PM +0100, Ralf Hemmecke wrote: >>> 1) You give ParseCallRes as a return type. But isn't it true that in the >>> end you want to have a string that you can send back to Haskell? >> >> Stage 2 will apply the needed f and produce a result r. > > Yes, and this is what I don't like. Well, we may have different ideas of > how things should work, so if I don't like something that doesn't > necessarily mean that you do something wrong. > > But the reason why I don't want r and especially its type is, because it > is unnecessary. All you need is a string format of the result. And that > you get by converting the result into OutputForm (or whatever). > OutputForm is just one type and that is good enough. All right, imagine parseCall2 : LexList -> OutputForm, String. If it is faster, then all right. But I do not guess how this String may help. String is almost the same as Any. May be, you have some idea of which I do not guess. > So my idea would be to parse the string, dive deeper while parsing, i.e. > building the intermediate types recursively and basically just return > OutputForm. Among these intermediate types there will meet `Any', and `pretend' and `retract' will be needed to apply a cople of times. I cannot imagine how can this be avoided. > But well, I don't know whether this would work. As DParse-0.02 works in examples (with Any, retract, pretend, with parsing a domain -- please see dParse), this parseCall has to work too. After I started to believe that DParse-0.02 works, the problem remains in the performance. 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.
