On Saturday 09 Jul 2011 23:12:08 Ralf Hemmecke wrote: > 1) I don't quite understand the benefit of this domain other than > perhaps drawing diagrams. What is your actual motivation for such a domain.
I am trying to work out a top level architecture for the computation framework and stuff related to function composition. For instance, it seems to me that it would be useful to support finite state machines and graphs (as in graph theory) as just two examples. However there looks like a lot of overlap and these would need to interwork with the computation framework so I would like a very general framework to link all this together. > 2) I don't actually like the design very much. (Of course, that is > debatable.) > You basically implicitly create a type OBJT and ARROW > > OBJT ==> Record(name:String,posX:NNI,posY:NNI) > ARROW ==> Record(name:String,arrType:NNI,fromOb:NNI,_ > toOb:NNI,xOffset:Integer,yOffset:Integer) > > ARROW already looks rather complicated. I'd expect something like > > Record(name: String, src: OBJT, target: OBJT). > > And more importantly, you want higher order arrows. So why not giving > the types of OBJT as an input parameter to HomSet? Higher order arrows > can then appear more naturally as arrows between arrows, i.e. the arrows > in HomSet(Arrow). > > Doing it in levels like this, it seems a bit questionable to put > posX/posY into the OBJT type. It seemed more efficient to index everything rather than reference the objects directly. One reason for this would be to support a more 'category theory' approach to defining things, that is, treat objects as black-boxes and define them from from the outside in. That is, instead of starting from a set and adding layers of structure we start with the outside structure with the arrows. > Having said that, it seems that your domain is simply for drawing and > not itself (logically) for creating diagrams. This was not my main purpose, although having said this, I would really like the ability to have a two-way graphical interface to these types of structure. > And again... output should be with OutputForm, not String. Yes, the hom-set code has a lot of the same problems as the computation framework code, but I would like to get the top level picture sorted out first. 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.
