On Sun, 03 Jan 2010 06:07:08 +0100, Julian Bäume <jul...@svg4all.de> 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. ------------------------------------------------------------------------------ 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
