On 17 March 2014 22:40, Andrey G. Grozin <[email protected]> wrote: > On Mon, 17 Mar 2014, Ralf Hemmecke wrote: >> >> As far as I know TeXmacs can embed FriCAS in its documents and when one >> calls fricas from TeXmacs, then fricas outputs in texmacs format and >> texmacs does the formatting. >
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 the same way that TeXmacs works with Maxima. TeXmacs however does have a native intermediate display form consisting of s-expressions very similar to what FriCAS uses internally. As we discussed many many years ago, it would in principle be very nice if FriCAS could generate TeXmacs intermediate form directly instead of using LaTeX. In particular this would probably solve the problem of displaying very long lines of FriCAS output in TeXmacs. Currently at least one version of the TeXmacs plugin for FriCAS uses the old line folding code written by Dick Jenks for use in the original Axiom book. This is also used on the AxiomWiki. Unfortunately it does not always do such a good job and may TeXmacs would do a better job if it was handed s-expression output from FriCAS instead of LaTeX. > TeXmacs can be used as a GUI front end for FriCAS, maxima, reduce, sympy, > sage, some othes CASs (Axiom, giac, macaulay2, cadabra, yacas, mathemagix, > pari, maple, Mathematica, MuPAD, maybe more), as well as to octave, scilab, > R, some plotting programs (asymptote, gnuplot) and others - the full list is > lengthy. You can open sessions to these CASs from TeXmacs window. It > provides high quality of typesetting mathematics (as high as TeX/LaTeX, but > interactively). Input for CASs also can be written in a nice typeset 2D form > (this requires some translation rules, say, how to send integrals or sums to > each CAS; such rule sets are, of course, incomplete, and in many cases a > user has to use syntax specific to a given CAS, maybe intermixed with 2D > mathematical notation). It is easy to copy-paste, say, a matrix derived in a > FriCAS session into an octave session for further numerical work. > 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. > 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. > One > program should do one thing well; TeXmacs interactively typesets mathematics > very well. It seems a waste of time to develop separate (and incompatible) > GUI front ends for each CAS. Why not use TeXmacs as the main GUI? Compared to the a browser-based notebook TeXmacs seems very "heavy" to me. It is a large program with a moderately steep learning curve compared to a browser interface. I get exactly the same feeling every time I try to use the Maple "document mode". Still I think that you have a point, especially for those people who would like to produce a (almost) publication-ready document directly from the CAS GUI front-end. > Currently, > only mathemagix is doing so. It integrates with TeXmacs closely. For > example, it has dynamic plots (and other dynamic objects). Say, I have a > plot of a function depending on some auxilliary parameters somewhere in a > TeXmacs window. I assign a new value to one of these parameters, and the > plot immediately changes, without the need to re-run a plotting command. > Such level of integration can be achieved in FriCAS, too, but this requires > further work. ioHooks are invaluable for implementing interactions of FriCAS > with external programs, such as TeXmacs and others. > 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. > I'd say that the TeXmacs format is one of the most useful ones, because it > gives FriCAS an excellent GUI. Also the fortran format is useful for anybody > who plans to use derived formulas for an intensive numerical work (it is > still done in fortran in many cases). IBM script is, probably, not used > anymore. > > I'd say that making the user experience with TeXmacs (GUI) / FriCAS (engine) > even better than it is today is very important. For example, TeXmacs can be > an improved replacement for HyperDoc, with a modern and intuitive interface > (HyperDoc definitely looks and feels old-fashioned). This can be achieved by > doing only a moderate amount of work. This is especially important in > today's world where programs without a nice and convenient GUI are > considered old-fashioned, and are often not even considered by potential > users. 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. As usual the bottom line is determined by the (lack of) available human resources. It is interesting to consider in fact that the very first Google Summer of Code project hosted by the Axiom project was concerned exactly with these same user interface issues - more than 10 years ago. 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.
