P Zoltan wrote: > Here is some code, describing the interfaces between the simulator and > document:
> > http://sourceforge.net/userapps/trac/zoltan_padrah/wiki/KtechlabDocumentProposed > We should discuss about it. There are some fixme-s and todo-s, too. I don't understand what that source code is for. It looks somewhat dated in its design pattern, a number of things I've straightened up already in SVN. Furthermore, I'm becoming increasingly distressed by the move away from the Document family and tree of classes. One of the things that makes ktechlab work so great is that everything is unified into a single class heirarchy. All documents, both text and graphical are instances of class Document. All graphical documents are instances of class ItemDocument, all documents that feature connectors between components are of class ICNdocument, etc... The apparent rush to implement the functionality of the child classes without respect for the over-arching architecture of the application is bound to be a disaster!!! =((( It's great to extend this with project management and other good features, but the unifying class hierarchy is indispensible! =( I don't mind if we use someone else's Document class, but you'll need a VERY good argument that the alternative is better. Another thing that needs to be understood is exactly what the simulator is, and what it does. In the not too distant past, I have done some massive overhauls to that class so there is no good excuse not to understand it!!! =| So here's how simulator works. The first thing to notice is that there's only one real method, everything else is just setup, teardown, and plumbing. [I'm a bit tired, so I'll rush through this and let you figure it out.] What the simulator's real responsibility is, is maintaining time. Our simulator is relatively primitive, it can't run things in parallel, and it can't be distributed across a network. It is given what, ideally at least, are generic objects that can be simulated. It doesn't care if it's a gear, a circuit, a flowcode instruction, or anything you can think of. The one critical thing is that the object exists within a universe with time. That is why the simulator's most-used function is the one which returns the current simulation time. The simulator is optimized in that it tries not to waste time simulating things that are static, or haven't changed. When things are changing, it makes sure that everything in that domain of simulation is given the CPU time it needs to advance itself one state. The code is still cumbersome because it's going down a list of different things to simulate rather than a generic bag of things to simulate. (see TODO item on line 77 of simulator.cpp) Currently some classes of things need to be handled a bit differently than other classes. Most notably, logic elements are processed basically in the abstract so that they can be processed extremely fast!! Extremely as in the current simulator can push through *MILLIONS* of state changes on badly aging hardware in a matter of a few seconds, I have a nice demo circuit to prove it, while other electronic components are processed at a corser time-granularity but a much higher electrical accuracy. This is why the simulator maintains two separate time resolutions. But the short story of it is that the simulator's only real job is to create a concept of time for all the other classes which exist within the simuation. Also: I think I finally have a handle on why the super-critical nonlinear and Diode classes aren't working. While I wait for my contract to be renewed I might have a little (hopefully not too much!) time to attempt to implement my newfound solutions. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
