On 18 March 2014 12:36, Andrey G. Grozin <[email protected]> wrote: > On Tue, 18 Mar 2014, Bill Page wrote: >> >> Yes, TeXmacs can embed FriCAS commands and display FriCAS output. But >> unless I am mistaken still FriCAS generates LaTeX in the usual way and >> that is interpreted by TeXmacs. > ... > This is wrong. FriCAS generates the native TeXmacs format, not LaTeX. >
Great. Thankyou for the correction. I had a lapse of memory here and should have checked the FriCAS mailing list archives first before writing. I obviously need to take a closer look at TeXmacs and FriCAS again. How well does it now handle very long and complicated expressions or overly large matrices etc. ? When I get a moment I will try it myself. > >> Yes it would be particularly nice if one could use typeset input into >> FriCAS. As you say this might involve some clever translations but I >> think it could be well worth the effort. > > Using 2D input works right now. > Excellent. Earlier you wrote that the translation rules are incomplete. Is there a document somewhere that describes what works and what does not? > >>> At the moment, TeXmacs is the best free GUI to mathematical programs. >> >> Of course that is debatable. I find the "notebook" style browser >> based interface developed for Sage (and now incorporated in IPython >> and various other I.... flavors) to be rather compelling. In this >> case quite high quality typeset mathematics is provided by MathJax. > > I somehow dislike the idea that everything should run in a browser. > Is this just a personal preference or do you think there are some objective reasons to avoid using a browser for this purpose? One good reason might be the possibility of "2D input" that you mentioned above. I think this would be harder (but not impossible) to achieve in a browser. > >> I like this idea. It reminds me to comment that most (all?) CAS >> interfaces assume only a very primitive sort of "sequential" >> asynchronous relationship between the document being generated and the >> CAS kernel state. For example, editing a variable definition >> occurring earlier in the document has not effect on the CAS output >> occurring later in the document. After the edit, the document is out >> of sync with the CAS engine. This is usually solve in a brute force >> way by resetting the kernal and forcing re-execution of all embeded >> CAS commands in the document. A much better way would be for such >> variable definitions and other operations that affect the state of the >> CAS kernel to be linked in a kind of dependency graph so that the >> state of the document could be synced with the kernel using only a >> minimum number of CAS operations. In some ways this would be like a >> spread-sheet interface. Everything including graphics could be >> dynamically updated. > > mathemagix (with TeXmacs) has not only dynamic plots but also dynamic > formulas. They remember on what they depend. When you assign a new value to > a parameter, dynamic formulas are updated automatically. You just propose to > make *all* formulas dynamic. No, I don't think that is equivalent to what I intended. > I think this is an overkill, there should be a > choice. Suppose I want > > x:=1 > <some calculation for x=1> > x:=2 > <some calculation for x=2> > > I don't want the whole calculation for x=1 to disappear immediately after I > execute x:=2. > No, certainly not. That is not what I meant. Editing the line containing the FriCAS input x:=1 should only affect those FriCAS commands that depend on the value of x embedded in the section you called <some calculation for x=1> Because the command 'x:=2' occurs some time later in the text after the command 'x:=1' it defines a new scope for x for anything that follows it. The FriCAS commands whose output depends on x in the section you called <some calculation for x=2> should not be affected because there are in the new scope. Of course the effects of this change should cascade downward in the document for any embedded FriCAS commands that depends on there results in turn. Notice that your choice of name for the section '<some calculation for x=1>' is no longer descriptive since after the edit x would not be equal to 1 in that section anymore. In the end the result of both what is displayed in the document and in the internal state of FriCAS should be exactly the same as if you had just reset the kernel and re-executed every FriCAS command from the beginning. The difference here is that only those commands that need to be re-executed are executed and the kernel is never reset, i.e. no need to execute the FriCAS command )clear completely and start over. > By the way, mathemagix is quite similar to Axiom in its main ideas - > domains, etc. > Categories also? How much of Axiom could be ported to mathemagix? What would be required in order to attempt this? > >> There have been some attempts to replace HyperDoc with a web-browser >> based interface. This has had only limited success in the original >> Axiom project although admittedly only a limited amount of effort has >> been devoted to this sort of thing. In most ways it seems like a >> browser interface for hyperdoc is more more natural than using a >> document creating system like TeXmacs. > > Maybe. I like browsers not very much. > I worry about the speed of TeXmacs for the kind of thing that you suggest. Has performance of TeXmacs improved significantly? Of course this is mitigated quite a bit by the speed of the computer hardware we are using these days but still, people's expectation is that "browsing" through the FriCAS documentation in hyperdoc or it's replacement should be very snappy. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
