Yeah I know circuit elements really shouldn't know much about being overrated. I also think that items perhaps shouldn't know much about being overrated, but I am not very experienced with C++ and this is my best shot at it without having to rewrite the engine.
I use getJoules because it's convenient, I don't have to put maths everywhere. Whilst there aren't specific circuit types, if you do polarize a capacitor the icon does change appropriately. I don't know much about transistors and states and settings... Let me know what needs to be changed with my patch. I did compare the transistor simulation in ktechlab to another simulator (the software at my school is Yenka - it's OK but it's got lots of bugs) and it seems plenty accurate, unless both simulations are wrong... I've gotta go now, bye. Tom > tho...@tgohome.com wrote: >> Hi, >> >> I'm back again. >> >> After a bit of getting used to patch/diff - it's the first time I've >> really got used to it - I made a patch file. See here: >> >> http://files.getdropbox.com/u/1134084/ktechlab-over-rate-additions-plus-more-by-Tom-Oldbury.patch >> >> Hopefully I did it right - please can someone try it out on a copy of >> current SVN. > > I found the problem with my build, I had a "--prefix=" statement in my > kdevelop configuration. =\ > > Those SVN diffs had several problems, for one thing it includes > differences involving the makefiles, which are specific to your machine > and the version of automake you used. For some reason you have a number > of Makefile.in's, one from automake 1.9.6 and the other from 1.10.1 > > Second, I've been on a jihad against class Component. Previously, all > the code in DSubCon, DIPComponent, and SimpleComponent were all mixed > together in the same class, with hundreds of children. The new layout > makes it a bit saner. A great deal of refactoring is still required to > confine as much information as possible as tightly as possible. > > If this were Java, which deals with interfaces quite nicely, this > wouldn't be too bad, but in C++ .... > > You are currently the most enthuseastic programmer on ktechlab, and I > must say you are far more capable than even I am! =P I've been wrestling > with this code for years and had not gotten close to adding new features > of the scope you have. (on the other hand, your rapid progress is > probably in part due to my constantly tweaking the code). > > I'm not sure Item should know anything about "ratings", it's just > something that you can put on a canvas... But then this is probably an > interface issue. > > I REALLY don't like class member variables because they are a great > place for glitches if not actual bugs to hang out, bloat the memory > footprint, bloat the symbol tables in the binaries, etc etc... > m_hoverTipText should definitely be replaced by a lazy evaluator which > will generate a string ONLY when the tip is actually in the neighborhood. > > I didn't compute V_CE in BJT because it was an extra variable and it was > trivially available from V_BE and V_BC. I felt it was important to > remove that variable because it made: (V_CE != V_BE - V_CE) possible so > therefore I removed that variable and thereby removed the potential bug. > > OH CRAP, I MIGHT HAVE BEEN COMPLETELY WRONG!!! I didn't realize, at that > time, that I had to diode-clamp those other two variables, hence needing > to pre-compute V_CE... ARGH!!!! =0 Maybe I am also completely wrong > about how and where I need to diode clamp... (mosfet is currently > putting INF's into the matrix! =((( > > The pathetic attempt at computing the transistor current are these lines > here: > ###### > m_ns.I[0] = (-I_eq_B - I_eq_C) * m_pol; > m_ns.I[1] = ( I_eq_C - I_eq_E) * m_pol; > m_ns.I[2] = ( I_eq_B + I_eq_E) * m_pol; > ###### > > Those being the device's three Cnodes, or was it cbranches... since > we're setting current, I think they're cnodes... > > You are completely wrong by confusing STATE with SETTINGS. Never use > SETINGS for STATE!!!!!! > > Furthermore, state is only visible when queried, therefore if it is not > inherently part of the state, then it should be computed WHEN IT's > QUERIED. Once again, this makes it impossible for the state to become > inconsistient. In database terms, I'm trying to normalize the classes to > make inconsistiencies impossible. > > Capacitance is an abstract ideal circuit element. (look up "elemental > analysis" or something like that). > > It would be great to have specific capacitor types such as electrolytic > capacitor, with the correct symbol... (there are five or six different > symbols for different types of capacitors...) > > I don't know why you have getJoules, it seems trivial to compute from > Columbs in higher level code. > > The functions for obtaining voltage and stuff seem to be fine additions... > > In general, the stuff in Simulation is there for exactly one task, to > set up the linear algebra engine. The components shouldn't do much > except try to figure out what's happening by looking at the state of its > pins. (pin currents are problematic and moderately broken..) Components > are free to be as realistic as desired. There you get things such as the > capacitor's ESR, etc, all modeled in terms of abstract circuit elements. > > Goddamnit, I just spent the entire night using Kompare to view your > changes when I should have been catching up on my badly needed sleep. =( > > > -- > New president: Here we go again... > Chemistry.com: A total rip-off. > Powers are not rights. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ktechlab-devel mailing list > Ktechlab-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > ------------------------------------------------------------------------------ _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
