From: P Z. <zol...@gm...> - 2010-01-02 23:56:21
|
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. Also there is a new version of the flowcode document UML class diagram; so QGraphicsItems _can_ have children. More testing is needed... Happy New Year! |
From: Vincent N. <vin...@ya...> - 2010-01-03 00:03:16
|
Hi, is it possible to access the KDE4 branch? sf.net seems to have only the old kde3 available. Or at least something that does not want to compile with cmake. Anay help appreciated. I'm sure this info is somewhere available, just can't find it. My apologies upfront. Thanks, Vincent |
From: Julian B. <ju...@sv...> - 2010-01-03 02:35:24
|
Moin, On Sunday 03 January 2010 01:03:09 Vincent Nikkelen wrote: > is it possible to access the KDE4 branch? yes, it is. You can find my latest code in my git branch on the KTechLab project page. (There will be more repositories containing KDE4 code, including the official git repo, once this gets more usable) > sf.net seems to have only the old kde3 available. Or at least something > that does not want to compile with cmake. Anay help appreciated. Find instructions in the wiki: http://sourceforge.net/apps/mediawiki/ktechlab/index.php?title=Main_Page#Getting_the_source If anything is unclear, please use the mailing-list or try to ping me in IRC (johnyb). I saw you tried, but I wasn't there at this time. I will then update the wiki to have better instructions, if needed. bye then julian |
From: Julian B. <ju...@sv...> - 2010-01-03 02:49:46
|
Moin, On Sunday 03 January 2010 02:56:42 P Zoltan wrote: > Also there is a new version of the flowcode document UML class diagram; > so QGraphicsItems _can_ have children. More testing is needed... That looks more promising to me, now :) Another thing I'd like to mention in this context is the coordinate-system of QGraphicsView. QGraphicsItems children "see the world" relative to it's parents. So, if there is a child at position QPointF(10.0, 10.0), it's "inside" the Item. (If it is large enough). For a QGraphicsItem QPointF(0.0, 0.0) is the upper left corner of the Item. One can easily map between View-coordinates, Scene-coordinates and Item- coordinates. (see Qt documentation). If you write the Document to disk, everything should be stored in scene- coordinates, to be consistent with the recent implementation. (It even makes more sense to me, to do so.) bye then julian |
From: Julian B. <ju...@sv...> - 2010-01-03 05:08:20
|
Moin, On Sunday 03 January 2010 02:56:42 P Zoltan wrote: > Here is some code, describing the interfaces between the simulator and > document: > http://sourceforge.net/userapps/trac/zoltan_padrah/wiki/KtechlabDocumentPr > oposed > > We should discuss about it. There are some fixme-s and todo-s, too. Concerning the float/double question: on most (all?) of our target platforms, float will have single-precision, where double offers double-precision. Of course, size differs and float might be faster on embedded platforms, like arm. I think, as long as we don't encounter any performance issues, because of matrices with really large dimensions, we should use double. This will prevent us from any unwanted precision issues (at least in a better way float does ;)) Concerning the ISimulator * IPin::setVoltage(float, ISimulator *): Another way to prevent the unwanted external usage of this method is not to export it as public. We could just make it protected and define ISimulator as a friend class. This way, ISimulator can set these values and we don't need to pass a pointer every time this method is called. This way will also keep the API more clean. Why is IPin::isLogicPin() needed? Such methods raise some alarm bells in my brain, because they are mostly needed to fix bad design. Same question for IElectronicModel::isNonLinear() and IElectronicModel::isReactive(). May be, we need these methods, I just want to make sure. There are quite a few methods with the type of "numberOf...". This should IMHO be expressed in another way. We should provide access to the internal lists (however they are stored internally) and use count() or size() methods on these lists. This will be a more flexible solution, since we might want to iterate all list items anyway (somewhere) and will need these methods. Example: instead of ISimulatedDocument myDoc; int wireCount = myDoc.numberOfWires(); you just write: ISimulatedDocument myDoc; int wireCount = myDoc.wires().count(); This will keep the API more clean and it is readable, too. (Read it as: "myDoc, give me a list of all your wires and count them for me") One last note for actual implementation: Interfaces in c++ don't have to be pure-virtual, as in Java. For example, IWire can be implemented in the interface. No need to sub-class anything, because everything this class does is straight-forward. (Just sub-class, if you want to change any behaviour.) Well, that's all I have to say, for now. :) May be, we should move this API discussion to git, soon. This way, we can track changes and express our changes and thoughts in form of patches. I agree, that sf.net doesn't provide the best front-ends for git to do code- review. I hope, I can come up with a better solution, soon. We could use trac hosted by sf.net, but I think, trac's git support is still somewhat poor. bye then julian PS: thanks for your work! I appreciate to see some progress going on. |
From: Alan G. <ag...@sp...> - 2010-01-03 05:13:59
|
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. |
From: Julian B. <ju...@sv...> - 2010-01-03 15:47:20
|
On Sunday 03 January 2010 06:08:43 Alan Grimes wrote: > P Zoltan wrote: > > Here is some code, describing the interfaces between the simulator and > > > > document: > > http://sourceforge.net/userapps/trac/zoltan_padrah/wiki/KtechlabDocumen > > tProposed > > > > 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... This is not the intention of doing this. The recent API really has some design flaws. I just had a look into the header files for ItemDocument and ICNDocument. There is ItemView and ICNView, why do I see methods like: QCanvasItem* ItemDocument::itemAtTop(const QPoint &pos) const defined there? This is just one random example. The purpose of what we are doing here is to redefine the API needed for the View to get all necessary data from the simulator and update the Model (and inform the simulator) about interactive changes done by the user. What these classes should not do, is to interfere with the view or returning stuff, the view takes care of. This is, why we are working on that. > 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 want to loose the unified architecture. In the end everything will stay a Document. What I want to do is to remove responsibilities from these classes. Why should the Document care about which Items can be connected and which don't? Why should it care, where Items are painted in the Scene. > 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. KDevPlatforms Document class just extends our Document classes and renders some functionality, we have now, obsolete, while other parts need to be modified, slightly. All in all, it should just be less code to be maintained by us. I believe, you won't miss any functionality, after this process is finished. > 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!!! =| > > [...] > > 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. Thanks for that introduction, that made some things more clear to me. > 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. That sounds nice, please keep us posted. bye then julian |
From: P Z. <zol...@gm...> - 2010-01-04 21:16:21
|
On Sun, 03 Jan 2010 06:08:43 +0100, Alan Grimes <ag...@sp...> wrote: > 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. Julian explained rather well what's the point, so I'll just make another approach: These classes should describe how the simulator and the simulated components should be seen from _outside_. They have nothing to with the _inside_ workings of the objects. The ISimulator should be seen from the document; while ISimulatedDocument, IElectronicModel, IWire, IPin are the elements seen by the simulator from the document and simulated components. None of these have anything to do with the implementation. This way the big pile of code of ktechlab can be splitted in 2 smaller piles of code, connected by these abstract interfaced. Smaller piles of code are generally easier to understand, maintain, debug. > > > 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!!! =| Okay, I'll look at it. Here is an example of what my problem is with the current code: - the simulator manipulates lists of Components - inside the Component's definition: [...] /** * Angle of orientation */ int angleDegrees() const { return m_angleDegrees; } [...] /** * After calculating nodal voltages, each component will be * called to tell its nodes what the current flowing *into* * the component is. */ void setNodalCurrents(); First, there is a method that has to do with the display of the Component, then there is a method that is specifi to simulation. Why should we mix the roles of simulated component and drawn item in the same class? This is messy. And also makes the code a lot harder to debug. > > 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. > > |
From: Axel J. <axe...@ba...> - 2010-01-03 11:42:52
|
> Concerning the float/double question: > on most (all?) of our target platforms, float will have single-precision, > where double offers double-precision. Of course, size differs and float might > be faster on embedded platforms, like arm. I think, as long as we don't > encounter any performance issues, because of matrices with really large > dimensions, we should use double. If your main concern is bad performance on ARM, use qreal. It is a double on all plattforms except ARM. It is used in QGraphicsView for nearly everything. Axel |
From: Julian B. <ju...@sv...> - 2010-01-03 12:11:01
|
On Sunday 03 January 2010 12:42:42 Axel Jäger wrote: > > Concerning the float/double question: > > on most (all?) of our target platforms, float will have single-precision, > > where double offers double-precision. Of course, size differs and float > > might be faster on embedded platforms, like arm. I think, as long as we > > don't encounter any performance issues, because of matrices with really > > large dimensions, we should use double. > > If your main concern is bad performance on ARM, use qreal. It is a double > on all plattforms except ARM. It is used in QGraphicsView for nearly > everything. That was just an example ;) I'm aware of qreal and what it does (that is actually, why I choose this example here). I just wanted to make clear, that double might be a better choice, since float has only some limitations on a few (one for those Qt is running on) platforms. I don't see arm as a target platform for KTechLab (or do we expect widely deployment of arm-based netbooks any time and want to use KTechLab on them? May be, we should think about that.. ;)). The point is: float has limitations, most of our target platforms support double precision (and even long double) in hardware, so we should just use double, IMHO. bye then julian |
From: P Z. <zol...@gm...> - 2010-01-04 20:49:48
|
On Sun, 03 Jan 2010 06:07:08 +0100, Julian Bäume <ju...@sv...> wrote: > Moin, > On Sunday 03 January 2010 02:56:42 P Zoltan wrote: >> Here is some code, describing the interfaces between the simulator and >> document: >> http://sourceforge.net/userapps/trac/zoltan_padrah/wiki/KtechlabDocumentPr >> oposed >> >> We should discuss about it. There are some fixme-s and todo-s, too. > > Concerning the float/double question: > on most (all?) of our target platforms, float will have single-precision, > where double offers double-precision. Of course, size differs and float > might > be faster on embedded platforms, like arm. I think, as long as we don't > encounter any performance issues, because of matrices with really large > dimensions, we should use double. This will prevent us from any unwanted > precision issues (at least in a better way float does ;)) Considering the other discussions on this thread, there are two possibilities: - make the simulator depend on QT, and use qreal - use double It's a question of potential reuse: should or not that code depend on QT's types? If we want to use QT, then we should take full advantage of it. > > Concerning the ISimulator * IPin::setVoltage(float, ISimulator *): > Another way to prevent the unwanted external usage of this method is not > to > export it as public. We could just make it protected and define > ISimulator as > a friend class. This way, ISimulator can set these values and we don't > need to > pass a pointer every time this method is called. This way will also keep > the > API more clean. In my opinion both ways are hacks. Maybe the method of friend class is a little better, but I don't really have a preference. > > Why is IPin::isLogicPin() needed? Such methods raise some alarm bells in > my > brain, because they are mostly needed to fix bad design. Same question > for > IElectronicModel::isNonLinear() and IElectronicModel::isReactive(). May > be, we > need these methods, I just want to make sure. The issue here is optimisation of the simulator. There are different levels of needed computational power in order to simulate the circuits: - logic circuits: 2 possible levels, from the input you can tell the value of the output. Only if there is no analog circuitry or other output connected to the output node, because then we got complications. example: logic gates, flipflops Actually we should need bool IPin::isLogicInput() and IPin::isLogicOuput() ... hmm... - linear analog: these will return the same value for the elements in the circuit equation, irrespectively of the voltage/current applied to them. Have to query these coefficients only once. example: resistor - nonlinear analog: need iterative solving; the values of their matrix changes with the conditions in the circuit. Have to query them many times. example: diode - with energy storage: these components' behaviour depends on time. Maybe this sholdn't be a special case, as the time in simulator can be found out using the simulator's method. example: capacitor, coil My goal with those methods was to allow major simulator optimisations. If you have better idea on simulation, please tell. > > There are quite a few methods with the type of "numberOf...". This > should IMHO > be expressed in another way. We should provide access to the internal > lists > (however they are stored internally) and use count() or size() methods on > these lists. This will be a more flexible solution, since we might want > to > iterate all list items anyway (somewhere) and will need these methods. > Example: > instead of ISimulatedDocument myDoc; int wireCount = > myDoc.numberOfWires(); > you just write: > ISimulatedDocument myDoc; int wireCount = myDoc.wires().count(); > This will keep the API more clean and it is readable, too. (Read it as: > "myDoc, give me a list of all your wires and count them for me") My goal with those methods was to keep the implementation idiot-proof and list implementation independent. If we want to use lists, what kind of lists? std::vector, or something from QT? Also here is the tradeoff: - if we allow access to those internal lists, a code like: "myDoc.wires().clear()" would be disastorous - other one is easier to read - another problem: if the document internally modifies its structires, and doesn't inform the simulator yet, the simulator might crash, if, for instance, a wire is removed from that list, and the simulator is trying to access it. I'd say it's better to separate the internal state; we can still return a newly created list, which is a copy of our list, but then what kind of list should we return? QT vs std > > One last note for actual implementation: Interfaces in c++ don't have to > be > pure-virtual, as in Java. For example, IWire can be implemented in the > interface. No need to sub-class anything, because everything this class > does > is straight-forward. (Just sub-class, if you want to change any > behaviour.) Yes, I knwo that. I just don't want to touch the implementation yet. And yes, maybe I have too much java influence :)) > > Well, that's all I have to say, for now. :) > > May be, we should move this API discussion to git, soon. This way, we can > track changes and express our changes and thoughts in form of patches. I > agree, that sf.net doesn't provide the best front-ends for git to do > code- > review. I hope, I can come up with a better solution, soon. We could use > trac > hosted by sf.net, but I think, trac's git support is still somewhat poor. On trac wiki there are also versions. This code was just conceptual. I'll upload (not in this week, probabily...) to git some code that compiles, . > > bye then > julian > > PS: thanks for your work! I appreciate to see some progress going on. |
From: Julian B. <ju...@sv...> - 2010-01-08 23:14:46
|
On Monday 04 January 2010 23:50:19 P Zoltan wrote: > Considering the other discussions on this thread, there are two > possibilities: > - make the simulator depend on QT, and use qreal > - use double > > It's a question of potential reuse: should or not that code depend on > QT's types? If we want to use QT, then we should take full advantage of it. I'm not sure about this. There are critics out there, that demonise the introduction of library-specific types. Okay, Qt offers them, so we might use them. But I don't know about the impact, this might have. > > Why is IPin::isLogicPin() needed? Such methods raise some alarm bells in > > my > > brain, because they are mostly needed to fix bad design. Same question > > for > > IElectronicModel::isNonLinear() and IElectronicModel::isReactive(). May > > be, we > > need these methods, I just want to make sure. > > The issue here is optimisation of the simulator. There are different > levels of needed computational power in order to simulate the circuits: > > [...] > > My goal with those methods was to allow major simulator optimisations. If > you have better idea on simulation, please tell. Okay, I see. So this is an issue of _our_ simulator. IMHO there must be another way to tell the simulator about the type. This has nothing to do with the graphical representation of the circuit (and its simulated values), right? So this shouldn't be in the API. > My goal with those methods was to keep the implementation idiot-proof and > list implementation independent. If we want to use lists, what kind of > lists? std::vector, or something from QT? > Also here is the tradeoff: > - if we allow access to those internal lists, a code like: > "myDoc.wires().clear()" would be disastorous > - other one is easier to read > - another problem: if the document internally modifies its structires, and > doesn't inform the simulator yet, the simulator might crash, if, for > instance, a wire is removed from that list, and the simulator is trying to > access it. Okay, I got your point. May be, you are right and we should provide these methods. > I'd say it's better to separate the internal state; we can still return a > newly created list, which is a copy of our list, but then what kind of > list should we return? QT vs std The classes/interfaces, we are talking about should stick to Qt types. Since the front-end is Qt-based, I don't see, why we should use something else. > > May be, we should move this API discussion to git, soon. This way, we can > > track changes and express our changes and thoughts in form of patches. I > > agree, that sf.net doesn't provide the best front-ends for git to do > > code- > > review. I hope, I can come up with a better solution, soon. We could use > > trac > > hosted by sf.net, but I think, trac's git support is still somewhat poor. > On trac wiki there are also versions. This code was just conceptual. I'll > upload (not in this week, probabily...) to git some code that compiles, . Since these are just header files (almost), there is no need to compile ;) We just have to make sure, the project, as a whole, compiles. (Also, I agree, that we shouldn't have any garbage in the tree. But, I think, it's fine to have something "work in progress") bye then julian |