Simplifying graphic routines

[Waldek Hebisch]

I would like to simplify out graphic routines. In particular:
- make subspace properties unmutable.
- removing "composites". They are tested by an input file, but
otherwise unused.

Let me add that "composites" in principle allow doing interesting
thing. However, they would serve as a building block for appropiate
code. I somewhat doubt that anybody wrote graphic code based on
"composites".

--
Waldek Hebisch

[Ralf Hemmecke]

Not that I care much about our current graphics engine at the moment,
but composites sounds like putting several graphics elements together.

How would I otherwise put a cylinder and a pyramid into the same picture?

I would finally be interested in something that can be shown inside the
jupyter notebook. I don't care much what the underlying machine is, I
hope that Kurt at some point comes up with an interesting project.

Ralf

[Waldek Hebisch]

On Sat, Mar 14, 2026 at 09:00:33PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Not that I care much about our current graphics engine at the moment, but
> composites sounds like putting several graphics elements together.
>
> How would I otherwise put a cylinder and a pyramid into the same picture?

One can put several components into a picture. Using that you
can put several geometric figures into the same picture. AFAICS
this works now and does not use composites.

> I would finally be interested in something that can be shown inside the
> jupyter notebook. I don't care much what the underlying machine is, I hope
> that Kurt at some point comes up with an interesting project.

Well, I would like to have a single unified graphic code. That
requres modifying what we have. Modifying unused code has its
cost, so I prefer to remove unsed parts.

--
Waldek Hebisch

[Qian Yun]

Just saying, it is unlikely that we develop high quality
plotting system in SPAD.

Interfacing with an existing, high quality scientific plotting
system is a better choice, right?

- Qian

[Ralf Hemmecke]

On 3/14/26 23:40, Qian Yun wrote:
> Interfacing with an existing, high quality scientific plotting
> system is a better choice, right?

I would also say so, but it all depends on available manpower...

Ralf

[Waldek Hebisch]

On Sun, Mar 15, 2026 at 06:40:55AM +0800, Qian Yun wrote:
> Just saying, it is unlikely that we develop high quality
> plotting system in SPAD.
>
> Interfacing with an existing, high quality scientific plotting
> system is a better choice, right?

That is mostly orthogonal to proposed simplification. Namely,
we need interface which goes into some lower level details.
That is something like "pass plot command as a string to an
external program" will not do it. "Composites" are part of
current interface.

Of course, less features in Spad code means that we have more
choice of what we could use.

Plotting has two parts: evaluating functions and graphically presenting
the result. IMO evaluating functions is part of our "core business".
But this at least partially interacts with graphic part: we need
to choose proper evaluation points. Pure graphic tasks preferably
should be delegated to external code. In the past I shortly
looked at Open GL. It looked for me that few calls to open GL
libraries could give quite satisfactory results. Maybe there
is something better now.

Concerning "high quality scientific plotting system", AFAICS
evaluating functions is large part of such thing and it could
be hard to separate graphics from evaluation.

To explain a bit more: our "implicit algebraic plot" uses symbolic
computation to determine structure of the curve. In particluar
this ensures (or should ensure) that there are no artifacts due
to numerical evaluation. I do not expect external graphic system
to have such capability unless it contains a CAS inside.

--
Waldek Hebisch

[Kurt Pagani]

On 15/03/2026 00:10, Waldek Hebisch wrote:
> On Sun, Mar 15, 2026 at 06:40:55AM +0800, Qian Yun wrote:
>> Just saying, it is unlikely that we develop high quality
>> plotting system in SPAD.

IMO the current system is not bad and in most cases sufficient for a
CAS. One has to distinguish between the drawing logic and the frontend,
of course. It's for instance easy to extend view2d/3D to allow other
frontends (e.g. gle, gnuplot, asymptote etc.).
ex: https://github.com/nilqed/spadlib/tree/master/drawfe

What do you mean by "develop high quality plotting system in SPAD."?
This would essentially mean using Lisp or old terminal systems like
ReGIS or Sixel, which actually works in some terminals, especially xterm
and mlterm.

https://github.com/nilqed/spadlib/blob/master/regis/src/regis.spad
https://github.com/nilqed/spadlib/tree/master/sixel

>>
>> Interfacing with an existing, high quality scientific plotting
>> system is a better choice, right?

I have tried a lot of them using the current plotting logic. My
favourites so far are (both installable by apt):

http://www.geomview.org/
https://glx.sourceforge.io/

https://github.com/nilqed/spadlib/blob/master/geomview/src/geomview.spad
https://github.com/nilqed/spadlib/tree/master/gle

GeomView looks also a bit "ancient", however, it is an amazing powerful
program, providing a pipe interface which allows using the current
plotting infrastructure of fricas (curve, ...). It's based on GL.

@Ralf: in the prototype there was some graphics capabilities
(matplotlib, gnuplot html canvas and some others ...). There are myriads
of *.js libraries. We can recover those any time.

The main question is of course: is there actual demand? I don't think
so, because there are so many plotting tools around, so that if focus is
on graphics, you won't use fricas for that ;)

[Qian Yun]

On 3/15/26 8:40 PM, Kurt Pagani wrote:
> On 15/03/2026 00:10, Waldek Hebisch wrote:
>> On Sun, Mar 15, 2026 at 06:40:55AM +0800, Qian Yun wrote:
>>> Just saying, it is unlikely that we develop high quality
>>> plotting system in SPAD.
>
> IMO the current system is not bad and in most cases sufficient for a
> CAS. One has to distinguish between the drawing logic and the frontend,
> of course. It's for instance easy to extend view2d/3D to allow other
> frontends (e.g. gle, gnuplot, asymptote etc.).
> ex: https://github.com/nilqed/spadlib/tree/master/drawfe
>
> What do you mean by "develop high quality plotting system in SPAD."?
> This would essentially mean using Lisp or old terminal systems like
> ReGIS or Sixel, which actually works in some terminals, especially xterm
> and mlterm.
>

I would consider the following factors:

1. multi-platform support. Native Linux/Windows/macOS and
Web interface.

2. interactive plotting. The plot can be manipulated by
buttons or spad commands in interpreter in real time.

3. high performance. I read that there are many tricks
and pitfalls regarding plot lots of points, for example,
sampling instead of plotting everything, dithering, etc.
Also for 3D plots, GPU acceleration will be needed.

What I had in mind for comparison was the plotting system of
CERN ROOT and R. But I'm not an expert in this field.

- Qian

[Andrey G. Grozin]

On Sun, 15 Mar 2026, Kurt Pagani wrote:
> GeomView looks also a bit "ancient", however, it is an amazing powerful
> program, providing a pipe interface which allows using the current plotting
> infrastructure of fricas (curve, ...). It's based on GL.

Some years ago my student had written an interface fricas -> geomview. It
more or less worked. I can try to find that code.

Andrey

[Kurt Pagani]

On 15/03/2026 14:10, Qian Yun wrote:
> On 3/15/26 8:40 PM, Kurt Pagani wrote:
>> On 15/03/2026 00:10, Waldek Hebisch wrote:
>>> On Sun, Mar 15, 2026 at 06:40:55AM +0800, Qian Yun wrote:
>>>> Just saying, it is unlikely that we develop high quality
>>>> plotting system in SPAD.
>>
>> IMO the current system is not bad and in most cases sufficient for a
>> CAS. One has to distinguish between the drawing logic and the frontend,
>> of course. It's for instance easy to extend view2d/3D to allow other
>> frontends (e.g. gle, gnuplot, asymptote etc.).
>> ex: https://github.com/nilqed/spadlib/tree/master/drawfe
>>
>> What do you mean by "develop high quality plotting system in SPAD."?
>> This would essentially mean using Lisp or old terminal systems like
>> ReGIS or Sixel, which actually works in some terminals, especially xterm
>> and mlterm.
>>
>
> I would consider the following factors:
>
> 1. multi-platform support. Native Linux/Windows/macOS and
> Web interface.

Using a web interface (hunchentoot/hsbcl) no problem :)

>
> 2. interactive plotting. The plot can be manipulated by
> buttons or spad commands in interpreter in real time.

This already works, e.g. in QGLE and geomview via sockets/pipes.

>
> 3. high performance. I read that there are many tricks
> and pitfalls regarding plot lots of points, for example,
> sampling instead of plotting everything, dithering, etc.
> Also for 3D plots, GPU acceleration will be needed.

Well, honestly, I don't think that this is fricas' core business. Do you
have any need for this?

>
> What I had in mind for comparison was the plotting system of
> CERN ROOT and R. But I'm not an expert in this field.

I see. However, CERN root for example, uses a sophisticated C++
framework, especially developed for huge amount of data. Interfacing
wouldn't be a problem, however, who takes a sledgehammer to crack a nut?

As said, I can't see any need. When I want quality graphics for paper,
for instance, I use TikZ/PGF, PSTricks etc. possibly exported from
Geogebra or use root or some of the many other available tools. But I'm
open for suggestions/ideas ;)

>
> - Qian
>

[Kurt Pagani]

On 15/03/2026 14:31, 'Andrey G. Grozin' via FriCAS - computer algebra

Oh, yes please, I'm interested. Mine is just a protoype (as usual ;).

>
> Andrey
>

[Ralf Hemmecke]

> When I want quality graphics for paper, for instance, I use TikZ/
> PGF, PSTricks etc. possibly exported from Geogebra or use root or
> some of the many other available tools. But I'm open for suggestions/

> ideas ;)But would you want to enter the commands for graphics again in GeoGebra
to produce the pictures if you already have the data (i.e. commands to
produce the graphics) in FriCAS. If I am allowed to dream... it would be
great to have a kind of system in FriCAS that sends data to external
programs if they are installed. Maybe we need a kind of "register"
system that makes the external programs available to FriCAS on-the-fly.

Although I did not yet have need... exporting graphics to TikZ/PGF
sounds cool (even if this only works through calling GeoGebra under the
hood).

Ralf

[Kurt Pagani]

On 15/03/2026 14:49, 'Ralf Hemmecke' via FriCAS - computer algebra

system wrote:
>> When I want quality graphics for paper, for instance, I use TikZ/
>> PGF, PSTricks etc. possibly exported from Geogebra or use root or
>> some of the many other available tools. But I'm open for suggestions/
>> ideas ;)

> But would you want to enter the commands for graphics again in GeoGebra
> to produce the pictures if you already have the data (i.e. commands to
> produce the graphics) in FriCAS.

I would save the data to a file, of course :) Similar as in Bill Page's
GnuDraw or write an interface to produce a suitable file format using
the data fricas produced by plot, draw, curce etc ...

> If I am allowed to dream... it would be
> great to have a kind of system in FriCAS that sends data to external
> programs if they are installed. Maybe we need a kind of "register"
> system that makes the external programs available to FriCAS on-the-fly.

Well, for that I'm using "quicklisp", especially the local-projects
folder. All you have to to do is to produce an .asd file and a few lines
of lisp code. On the other hand I'm using more and more hunchentoot (I
always build fricas using Waldek's hsbcl, very convenient. Ought to be
on github) for such tasks. Till recenty I steered clear of javascript,
however, there's a lot of possibilities regarding fricas (asynchronous
in the best way, so fricas will not be interfered). At the moment I'm
trying to parse your "formatting" in webspad with JS (see s.s.) as you
did it in the fricas kernel.

>
> Although I did not yet have need... exporting graphics to TikZ/PGF
> sounds cool (even if this only works through calling GeoGebra under the
> hood).

I think a TikZ/PGF should be no problem, even written in SPAD itself ...

>
> Ralf
>

[Tim Daly]

I suggest you run the graphics code through Claude.

It can answer a lot of questions once it sees the code.

It can also refactor the code. In fact, if you wanted to

move it to a non-X11 base it could probably do that also.

I have been using Claude. It is astonishingly good.

I haven't tried it but I'm certain it knows everything there

is to know about X11 and graphics.

Tim