Hi Stavros.
On Mon, 24 Feb 2003, Stavros Macrakis wrote:
> > ((%hypergraph) (prop1 . value1) (prop2 . value2) ...)
> The problem with that format is not in display -- which can handle
> anything you like -- but in the rest of the system. Maxima general
> representation (GR) requires everything to be either an atom or of the
> form ((<symbol> <sexpr>...) <GR>...). Maxima does use some non-GR
> representations, notably rational expressions and Poisson series, but
> unfortunately those are special-cased throughout the system, so you may
> encounter problems -- at the very least, your users will get alarming
> internal error messages rather than sensible error messages if they use
> functions which don't know about this representation (e.g. length). You
> will also not be able to take advantage of Maxima's generic manipulation
> facilities (e.g. subst, ev, map, part, ...).
I don't really want to have everything (or not even the defining
properties, i.e. edges and vertices) stored as maxima lisp. It would be
cumbersome for the rest of my package (and its working *very* well just
now). Is there some way to hide everything?
I don't know right now how I should deal with subst, ev, map, part, ...
This will require much more thought. From the top of my head I could
imagine the following:
((%hypergraph computed-props) mlist-of-vertices mlist-of-edges)
However, I would have to keep in sync the internal form of vertices and
edges with these mlists... I'm afraid this is not easy. Will my package be
notified when the user changes edges or vertices?
It would be easier for me to have
((%hypergraph props))
and just display mlist-of-vertices and mlist-of-edges. The way out might
be to have it *displayed* as
hypergraph(mlist-of-vertices, mlist-of-edges),
this would be easy for me and be consistent with maxima. Of course,
copying and pasting would loose properties that were already computed, but
NO information. Would be great!!!
I agree on your point:
> I would *very strongly* recommend, though, that the *linear* form
> (grind) of a graph give enough information to reconstruct it. That
> allows the user to save the expression to a file in a readable format,
> to cut and paste between processes, etc.
>
> > ...a graph which is not assigned to a variable gets garbage collected,
> > which is a good thing in my opinion
>
> Yes, of course if the value is not accessible it gets garbage
> collected -- that is handled by the underlying Lisp system, and you
> don't even need to think about it. But the result of a command is
> always assigned to the variable Dnnn. This is not handled by your graph
> package, but by the Maxima system. Once it is assigned to Dnnn, it will
> not be garbage collected. There is no difference as far as the system
> is concerned between assigning to Z and to D123. And this is an
> important part of the Maxima system's semantics and interaction style.
I thought that the output of the linear display routine would be assigned
to Dnnn, but in fact, its really better to have
(c1) complete_graph(5);
assign the graph to d1. Kill(d1); will remove it. This is more consistent
with the rest of maxima.
> This does not mean that the *display* of the value must include full
> information on the value. You can eat your cake and have it, too: just
> define a display function (dimension-graph) which only shows what you
> want it to show.
Could you make this explicit? Suppose that
((%hypergraph props))
Is about to be displayed and I have a function
(defun hypergraph-display (props) ... )
that does the display?
> * The internal form should follow General Representation.
> * The two-dimensional display form (dimension) can be a description
> rather than the full value.
> * The linear display form (grind) should include the full value.
> * Normal semantics should apply to graph values, assignment, etc.
OK, thanks, Martin