Martin Baker wrote:
>
> On Tuesday 07 Feb 2012 21:12:03 Waldek Hebisch wrote:
> > we can simply make an algorithm
> > package which just takes array arguments and converts
> > graphs to array form in the graph domain. Certainly such
> > graphs should _not_ have drawing related information
> > (such information would be pure overhead, with no reasonable
> > way to update and of limited use because it is practically
> > impossible to look at very large graph as a whole).
>
> Waldek,
>
> I am not quite sure if you mean just the algorithm package should not
> have drawing related information or the whole graph code?
just the algorithm package
> I somehow suspect there is a fundamental difference between us here in
> what we are trying to achieve. What I want is not just a set of
> algorithms but also something that is useful for human users to learn
> and experiment with this mathematics.
I understand this. As a developor I am mostly interested in
algorithmic aspects, but I appreciate need for other aspects
and actually I am happy that you take care of them.
> I don't just mean coordinates for representing in a plane but also
> designations/names for vertices and arrows and so on. Regarding the
> graphics, I think that people differ on this a lot, some people tend
> to think visually and some don't, I personally would not want to work
> on graphs without being able to see them.
>
> As a general rule I think it is important to separate out the graphics
> stuff as far as possible. I have tried to put the graphics stuff into
> the graphics framework: 'scene.spad.pamphlet'. However, in this case,
> I have not found a way to separate out these issues completely.
>
> I did consider creating a wrapper domain, which would be external to
> the graph code, that would allow annotation and coordinate information
> to be associated with a vertex. However, if we want to do this with
> arrow information (which I do), then we would have to have a separate
> external arrow domain. There might be some benefits to this but its
> also quite messy, if we continue to use indexes then they have no
> meaning outside the graph and if we specify to objects directly then
> there are efficiency issues. If we do all that then, the Rep will be
> free of annotation and coordinate information, but the graph code
> still needs to know about coordinate information. For example, if we
> are taking the product of two graphs, then we can combine the
> coordinate of the two operands to generate useful coordinate
> information for the product graph as a whole.
>
> So, in the end, I could not separate out the graphical/annotation
> information. It was just easier and more efficient to leave this
> information in Rep even though it goes against certain principles.
OK.
> I agree the graphics information becomes less useful as we scale up,
> but for me, that is no reason not to include it. In fact a matrix
> representation also scales up badly and I can't think of a
> representation based on outputForm that would be useful for a human
> reader and would scale up well. So how would large graphs actually be
> used? As algorithms for other packages?
>
> So is there a fundamental difference between us in principle here?
> Should I follow my own approach independently?
I think you misunderstood my message. Of course you need extra
information to have good presentation of graphs. And while it
would be good to separate mathematical information from "graphic"
one, I understand that it was not practical. My points are:
- your package could benefit from algoritms
- I would like algorithms which are not tied to the representation
you use now, because:
+ this representation has efficiency problems
+ I envision other clients of algorithm part
- the two points above put some constaints on domains/packages:
+ it would be wasteful to have two sets of identical algorithms
operating just on different data structures, so your graph domain
must be able to use algorithms package
+ but due to representation differences we can not put algoritns
into your graph domain, so you will have to accomodate
appropriate convertions (including some special handling
to restore/preserve graphic information)
I think this will be clearer when I present some code for
algorithms, then we will have something concrete to look at
and will see if my ideas couse problems to you (and if yes, then
how to resolve them).
BTW: I know that time passes by, and if I have too many distractions
this (adding algorithms) may move past the coming release, but ATM I
still hope that we can make it (with some tiny delay to the release).
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
