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? 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 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. 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? Martin -- 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.
