Graphics Issues

For mathematics specific graphic output (like graphs, lattice, plots, fractal, geometry, algebraic geometry and so on) I think it really does help to have the graphics output tightly coupled to the domains themselves (which means writing graphics code in SPAD). More info here.

Although, as you know, there are specialised libraries in other languages which it would be good to tap in to. It seems a real problem that FriCAS and other Axioms try to do everything themselves when there are not the resources to do it.

As for the coding of the web, and other, file formats (SVG, JPEG, GIF, PNG, MPEG, X3D, PDF and so on) most mainstream languages would have built-in libraries to read and write them. This means that someone else writes them and keeps them upto date. I don't think most lisp implementation have this. Of these file formats the XML based files (SVG and X3D) are relatively easy to write and support is already in scene.spad.pamphlet.

I suspect a lot of other people are put off FriCAS by poor graphics but that’s just my guess, I have no evidence. If someone is deciding whether or not to invest their time to try out a program it will probably be done quickly on look-and-feel a lot more than they would admit. I agree that the current default graphics are, at best, passed their sell-by-date and in some cases just don't work

However, this is just for static graphic output, I think there is a need to go beyond this to a two directional (input and output) graphical interface. Waldek does not think this is very important and the current graphics is good enough, so I thought it might help if I explain why this is important to me, to the extent that FriCAS is not really usable for many of the things I want to do.

To take just one issue: I would like to build a lot of finite structures (Graphs, Lattice, automata, FSM and so on). The command line interface is not good for this, requiring long lines of messy text. As you can see from what I am trying to do on this page:

Perhaps you could see what you think but I don't think I can use FriCAS for this type of thing. This very simple example requires a lot of text, I don't think this would scale up to more complicated finite structures.

An obvious solution is to split FriCAS into a front and back end with a well documented interface between them. So the Lisp code is the back-end which could be driven by command line or graphics depending on what is wanted. To some extent, this is what happens already (apart from the bit about 'graphics' and 'well documented) with the clunky 'C' code firing up the lisp, command line and hyperdoc threads and then piping them all together. I tried to document the C code on this page. but I would not really want to work on this type of code. Perhaps this is why Gaby and others have rewritten this in C++ ? I don't know if this would help with the issues here. Gaby seems to have a lot of good ideas in various areas but, without reading the code, line by line, I don't know how to find out what substance there is behind them.

I am very wary of interfaces between different languages. Its hard enough to track the changes in one language, but to track several and keep them all in sync really concerns me in terms of maintainability. From what little I know about Sage it looks like a multi-language mash-up.

I agree with comments by Ralf, also comments made by Tim, both suggesting in a different way that web standards are the way to go. I would also suggest it would make sense to meld together all the documentation types (hyperdoc, literate code and help files) 3 incompatible documentation formats seems silly to me. Tim has expressed a wish to move to HTML5 for these things, however his plan seems quite complicated with the need for custom code to be written which is just a maintenance overhead. I would prefer something much simpler which would use standard web tools.

I think that writing and maintaining graphics code requires a different mindset than mathematics code. Math structures may be eternal (even if naming conventions and so on change) but graphics and web standards change quite quickly and there is a continuous battle with browser compatibility and security. I doubt if there are the resources here to do write and maintain code to input/output all the formats that will be required in the future. When mainstream languages are used like Python(Sage) or C++(openAxiom?) then there are libraries that handle these interfaces (which are updated by other people when things change) so FriCAS programmers don't have to become graphics experts. Alternative approaches might be to do it in the browser (using Javascript libraries) or on a server but again lots of messy code to write and maintain. Javascript is a messy language but there are lots of libraries to do high level graphics stuff (although I don't have personal experience with them).

I don't know what the answer is. I don't think the FriCAS approach of writing custom code for everything is very practical but, on the other hand, I don't like multilangauge mash-ups. FriCAS seems to be trapped because of its use of Lisp.

I suspect that there is a need to simplify things (do less and do it better), even if some things are lost in the short term, like interactive parts of hyperdoc. I am not sure that replicating the current functionality in HTML would work. It seems more practical to use the web tools and libraries off-the-shelf and merge hyperdoc, literate code, help files into a common web form.

If anyone can think of a program of work that finds a way through all this and has the buy-in of all concerned then I would be happy to help - although the pessimistic side of me suspects that there is not the will to make big changes.

metadata block
see also:
Correspondence about this page

Book Shop - Further reading.

Where I can, I have put links to Amazon for books that are relevant to the subject, click on the appropriate country flag to get more details of the book or to buy it from them.

flag flag flag flag flag flag Axiom Volume 1: Tutorial. Documentation is freely availible from:


This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2021 Martin John Baker - All rights reserved - privacy policy.