[Ktechlab-devel] More on Document / Simulator interface

[P Zoltan]

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