[clean-list] Clean and plotting, etc. ...[loooongish]

[Jerzy Karczmarczuk]

Siegfried Gonzi :

> Would it be possible to link to an existent plotting library? I mean,
> this is what all the time the Python guys are doing.

OK, another few comments. I confess I have written some plotting packages,
at glorious times when Monsieur Gonzi was not born yet (seriously). Most
problems are of relatively high-level. Low-level issues are not interesting.

1. In principle, having a FFI (e.g. to C), foreign plotting or other
   libraries can be used. The output can be redirected through some
   Tcl/Tk modules, as in Python Tkinter module (slowly becoming obsolete).
   But personally I think this is pointless. The Clean IO has its own,
   specific protocol, it is quite nice, even if difficult, and any higher-
   level graphical layer should be adapted to it. So, I disagree with such
   an ideology:

> ... in Clean it is possible to call foreign C functions, therefore it should
> be possible to link to plotting packages (maybe not implemented fully
> yet).

   Want cheap solutions? OK, use Clean to produce JUST NUMERIC PLOT DATA,
   plus some textual descriptions, and feed everything to Gnuplot. Or, generate
   matrices of points, dump onto a file, and launch Matlab to plot it. Or,
   generate a PLOT structure and feed it into Maple.
   Or (I could continue for some time yet...) -- generate PostScript using
   Clean, or even "sexier" - produce MetaPost program using Clean, then 
   generate PostScript using MetaPost.
   Then you will begin to scratch your head, and you will ask yourself such
   questions as "damn it, do I really need this awful Clean?..."

   No, the package should be built within Clean, if only for ideological
   reasons. Plenty of occasions to exploit non-trivial I/O local states.
   The package should exploit the Clean type system, and higher-order
   functions.

2. The plotting issue - I repeat from the previous posting - is mainly the
   interface between the internal data structures (arrays and functions ge-
   nerating them), and a whole bunch of "virtual" graphic entities: 
   A. Standard 2D graphics:
   * Axes, with scaling procedures, ticks, frames, labels ...
   * Sampled points, and plotting discipline:
       straight lines  \
       splines         /  continuous, dotted, dashed,...; colour, width...
       markers: form, size, colour
       histograms
     with: plotting precision, smoothing, handling of singularities;
     automatic rescaling, manual rescaling; adapting to externally changed
     window size...
   * Additional attributes: backgrounds, procedures internal to plotting
     such as zooming; numerical procedures such as interpolators.
   * All loading/saving layer...
   B. Specific 3D issues (for "math" style surfacic plots)
   * Camera, focal or orthogonal projection. Where, how oriented.
   * Reconstruction of polygons/patches from numerical data
   * Hidden entity removal. Z-buffer, or silly Painter, or what not...
   * Colour and lighting procedures, Gouraud/Phong interpolation, etc...

   Again, I could continue... But it has nothing to do with the main religious
   issues on this mailing list, I assure you only that Clean is a VERY GOOD
   language to program such stuff.

=====

> A few weeks ago I contacted a Clean team member with the question about
> bitmaps and whether a future I/O version will include it. I got the
> advice to start a discussion on the Clean mailinglist, but I have been
> hesitating, because I am not a specialist on that field. And I cannot
> require or suggest further improvements when I do not have at least a
> basic unterstanding of the topic. I only red a few chapters in "Inside
> Macintosh", but this is completely insane (pointers, pointer to pointers
> and so forth).

For the moment the situation (for me) is the following.

A. I modified slightly one library module: osbitmap. Don't scream yet, the
   change is trivial: the standard .dcl def. module exports Bitmap as an
   opaque, abstract entity. The .icl contains its definition, such as the
   #Char array which contains the Windows DiB structure (essentially the
   contents of a BMP file). I added the .icl details to .dcl module.

B. I can thus load off-line (outside I/O) a BMP file, index the contents
   as a 2-dim matrix, make all kind of massacre, plot it using a reconstructed
   drawBitmap procedures, or save it on the disk. Making fractals, Erik??
   Quite straightforward. But slow, so I had no special motivation.

C. It is relatively trivial to do relatively trivial things, such as the
   rotation (with bi-linear or other interpolation), making global colour
   modification, etc. All is implemented in my simplistic texturing package,
   which I will give you in about 2 - 3 weeks, when I finish the September
   session chores (exams, stages, course planning and some murders...)

D. A lot of more work is needed, such as low-pass filtering (for downsizing),
   JPG and PNG input/output. (The JPG stuff exists independently, see Clean 
   contributions, but it should be reworked a bit.) 
   How to make a bitmap out of the graphic Device Context used by Picture
   manipulation? (The question is badly posed, but you know what I mean).


> I am not sure how Java handles a platform independet GUI and display
> system and whether we can learn from it.

I repeat my old song: the primitive graphic I/O layer is not so different
on different platforms. An interfacing go-between module linking it to
the "main" computation layer is something standard. Not only Java. Tcl/Tk
does it as well, full multi-platform portability. 
GTK under Linux is another example. The Haskellians have it already, Manuel
Chakravarty delivered a new version.

My favourite option would be WxWindows, because I have seen it at work, and
I use it simultaneously on 4 platforms through DrScheme. I am reluctant to
jump into it, but if in Clean 2 the graphic I/O layer continues to be just
Windows oriented, I will surely think about it, provided I get this mythical 
new version before my well merited Alzheimer, and if this version is 
sufficiently open for interfacing.

Jerzy Karczmarczuk
Caen, France