From: Glen <gca...@gm...> - 2008-11-07 00:14:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any direction / ideas for what direction the simulator should go? I have my own ideas, especially now since I've probed the code a little bit, but what's really better for the project? What would people like to see it do beyond what it does now? - --G -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJE4hrLstl3vProOARAislAJ9JhKlP6yC4UJCnMeo7hiam0uOu4gCfRrha krlQKVE0MXBIgxJeQmFrquk= =HfFS -----END PGP SIGNATURE----- |
From: Julian B. <ju...@sv...> - 2008-11-07 01:09:28
|
On Friday 07 November 2008 01:14:35 Glen wrote: > Is there any direction / ideas for what direction the simulator should > go? I have my own ideas, especially now since I've probed the code a > little bit, but what's really better for the project? Some time ago, it was mentioned on the list, that the actual code won't scale. So it's really hard to add new components to the simulator. We need a way to define components more easy. XML would be something to mention here. I don't see the problem to do something like that with the visualisation part, but for the simulator I don't see a good way to do it. There is a wiki page for features: http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request I mentioned to create the simulation logic in the XML files via ECMA script, since this could be interpreted by Qt. I haven't done any speed tests till now.. shame on me. > What would people like to see it do beyond what it does now? May be, you could have a look at the feature requests and see if your ideas fit in there. I suggest to find something you want to work on and then we should talk about it (may be irc or IM, or something similar) to see, how it should be implemented. May be something needs to be ported before you start. Do you have kdelibs4 installed? IMHO it won't be a good idea to develop hot new features for the KDE3 version. bye then julian |
From: Alan G. <ag...@sp...> - 2008-11-08 18:30:42
|
> Enumerating case is only possible if the component act like a Finit > State Automaton. That may not be the case for every component. > Embedding language in javascript fashion is (I think) a bad use of > XML.Remember this: "You know you made a poor use of XML when you need > some additionnal parsing". bah! That doesn't apply because in our use case, what we are trying to encode, as data are programs, which necessarily need to be interpreted, no shame in that. It is absolutely necessary that the user be able to design components. So compiled C++ is out of the question. > Embedding a "tag language"... not writable by hand. Not easily readable. > But no additionnal parsing need to be done. > another issue I see with XML is that it would be quite heavy. XML files > may be quite big, parsing everything will take some time. can't be much worse than the current size of the ktechlab binary! =P There are several issues that I'm concerned about. A. Loading circuit save files which contain references to library components which may not be available when loaded. B. Being able to easily create derived components. IE, specifying that "this component is just like that component but here are some specific specifications". That way we'd have a model for a darlington pair transistor, then when the user finds a datasheet, he can quickly write a specific part specification based on the generic library model. Multiple inheritance is also important, On-Semi, for example, makes a power transistor teamed with a thermal diode. So therefore, we'd have to inherit both the transistor model and the thermal diode model and then assign them to a heatsink domain which may then be combined with a larger heatsink domain in the circuit, to get an accurate model of the part. To make this really work we need to develop a new parts editor that uses the same terminology and parameters found in datasheets. It should also have a mode that would let the user implement simple test circuits and verify that the graphs produced are similar to those the manufacturer provided. Of special interest, are the transfer curves for transistors (and tubes for that matter). -- It should be possible to reproduce these in the simulator. By doing that we'll be able to verify the accuracy of our models and the user will be able to understand in what ways the simulation might not match the actual part. First you'd need a proper oscilloscope... =P Then you'd need to set up continuously variable probes for X and Y, and then a stepping function where you would input a series of voltages or currents. The engine would then apply a ramp function to X and then graph Y for each value in the list. > I'm not against the use of XML, but I think that only simple components > should be written in XML. Others may be written in C/C++, compiled as > .so and loaded at launch time (or later...). Linux absolutly, positively, categorically, does not (and will not ever), in any way, support that type of dynamically linked libraries. I have no idea what gave you the impression that it did. It is conceivably possible that there are kernel calls which may make it possible BUT THEY ARE NOT DOCUMENTED, ANYWHERE!!!!, There may even be linkers which support that, but once again they are not documented anywhere, and there might be user libraries that let you do it but they are either so obscure I've never heard of them or so arcane that I'd never attempt to use them. I have spent so much time and effort in utter frustration that I've had it. I want to design my own OS that loading plugins is it's primary and essential function, however, in attempting to develop such an OS, I've not only received no support (which is expected), I've also been actively thwarted by people who have later confessed that they didn't like me so they actively worked to frustrate my efforts by banning me from chat rooms and mailing lists. I'm sorry, this is a red-hot sore hot-button issue for me. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: P Z. <zol...@gm...> - 2008-11-07 23:07:26
|
On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <ju...@sv...> wrote: > On Friday 07 November 2008 01:14:35 Glen wrote: >> Is there any direction / ideas for what direction the simulator should >> go? I have my own ideas, especially now since I've probed the code a >> little bit, but what's really better for the project? > Some time ago, it was mentioned on the list, that the actual code won't > scale. > So it's really hard to add new components to the simulator. We need a > way to > define components more easy. Actually the components are hard-coded in the program, so to change them, you need to recompile ktechlab. That's a huge problem, imo. > XML would be something to mention here. I don't > see the problem to do something like that with the visualisation part, > but for > the simulator I don't see a good way to do it. I think the models can be also defined in XML; I've mentioned this on the list earlier: some 'basic' components should be defined in the program and everything else threated as subcircuit. So in XML we should describe two things: the symbol for the new component and the equivalent subcircuit as the model. As I know, spice does something similar: there are some basic parts, and the more complex ciruits are threated as subcircuits. Things get tricky when we want to define some interactive components with XML. For that we might need some expression-evaluation algorithms. > There is a wiki page for features: > http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request > BTW Wiki: can the wiki made read-only for not registered readers? When I look at the recent changes, I see 99% spam / spam deleted. > I mentioned to create the simulation logic in the XML files via ECMA > script, > since this could be interpreted by Qt. I haven't done any speed tests > till > now.. shame on me. > |
From: Glen <gca...@gm...> - 2008-11-08 03:56:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Implement resistance, capacitance, inductance, and a few other things, and have the component libraries hold the SVG, equations, icons, etc. The important stuff is already implemented, no reason to reinvent the wheel on it, imo. - --G P Zoltan wrote: > On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <ju...@sv...> wrote: > >> On Friday 07 November 2008 01:14:35 Glen wrote: >>> Is there any direction / ideas for what direction the simulator should >>> go? I have my own ideas, especially now since I've probed the code a >>> little bit, but what's really better for the project? >> Some time ago, it was mentioned on the list, that the actual code won't >> scale. >> So it's really hard to add new components to the simulator. We need a >> way to >> define components more easy. > > Actually the components are hard-coded in the program, so to change them, > you need to recompile ktechlab. That's a huge problem, imo. > >> XML would be something to mention here. I don't >> see the problem to do something like that with the visualisation part, >> but for >> the simulator I don't see a good way to do it. > > I think the models can be also defined in XML; I've mentioned this on the > list earlier: > some 'basic' components should be defined in the program and everything > else threated as subcircuit. So in XML we should describe two things: the > symbol for the new component and the equivalent subcircuit as the model. > As I know, spice does something similar: there are some basic parts, and > the more complex ciruits are threated as subcircuits. > > Things get tricky when we want to define some interactive components with > XML. For that we might need some expression-evaluation algorithms. > > >> There is a wiki page for features: >> http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request >> > > BTW Wiki: can the wiki made read-only for not registered readers? When I > look at the recent changes, I see 99% spam / spam deleted. > >> I mentioned to create the simulation logic in the XML files via ECMA >> script, >> since this could be interpreted by Qt. I haven't done any speed tests >> till >> now.. shame on me. >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJFQ3FLstl3vProOARApjkAJ0YGUOsq8JnlsPMQN91jxPKROlP+gCbB52J /7jDb7g/iwjElzViqRySFiI= =fnMB -----END PGP SIGNATURE----- |
From: Celelibi <cel...@gm...> - 2008-11-08 11:06:16
|
2008/11/8, P Zoltan <zol...@gm...>: > On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <ju...@sv...> wrote: > >> On Friday 07 November 2008 01:14:35 Glen wrote: >>> Is there any direction / ideas for what direction the simulator should >>> go? I have my own ideas, especially now since I've probed the code a >>> little bit, but what's really better for the project? >> Some time ago, it was mentioned on the list, that the actual code won't >> scale. >> So it's really hard to add new components to the simulator. We need a >> way to >> define components more easy. > > Actually the components are hard-coded in the program, so to change them, > you need to recompile ktechlab. That's a huge problem, imo. > >> XML would be something to mention here. I don't >> see the problem to do something like that with the visualisation part, >> but for >> the simulator I don't see a good way to do it. > > I think the models can be also defined in XML; I've mentioned this on the > list earlier: > some 'basic' components should be defined in the program and everything > else threated as subcircuit. So in XML we should describe two things: the > symbol for the new component and the equivalent subcircuit as the model. > As I know, spice does something similar: there are some basic parts, and > the more complex ciruits are threated as subcircuits. > > Things get tricky when we want to define some interactive components with > XML. For that we might need some expression-evaluation algorithms. > Hum, well. You know, XML is quite a good description language. It is possible to do anything with it. But have you ever tried to imagin what a programming language would be in XML ? It could looks like <if test="x == y && x+y > c"> <then> <!-- some very useful things --> </then> <else> <!-- yet very useful things --> </else> </if> that's quite awful to write. But we could go yet farther by writing the expression in the test with tags like <and>, <equal>, <add>, <sup> and <var>. And in that way the XML document would be a ASCII representation of the abstract syntax tree. XML is a good language to describe static things (or to describe a snapshot of dynamic things) with a finit (and static) number of properties. But if you want to represent dynamic things (like some electronic components) you may : - try to make a static representation by usually enumerating every case - try to embed some kind of programming language. - In a fashion like javascript inside html pages - Or as a "tag language". Enumerating case is only possible if the component act like a Finit State Automaton. That may not be the case for every component. Embedding language in javascript fashion is (I think) a bad use of XML.Remember this: "You know you made a poor use of XML when you need some additionnal parsing". Embedding a "tag language"... not writable by hand. Not easily readable. But no additionnal parsing need to be done. another issue I see with XML is that it would be quite heavy. XML files may be quite big, parsing everything will take some time. I'm not against the use of XML, but I think that only simple components should be written in XML. Others may be written in C/C++, compiled as .so and loaded at launch time (or later...). But after all, I'm not a developer, I'm just someone who follow that project. > >> There is a wiki page for features: >> http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request >> > > BTW Wiki: can the wiki made read-only for not registered readers? When I > look at the recent changes, I see 99% spam / spam deleted. > >> I mentioned to create the simulation logic in the XML files via ECMA >> script, >> since this could be interpreted by Qt. I haven't done any speed tests >> till >> now.. shame on me. >> > Celelibi |
From: Julian B. <ju...@sv...> - 2008-11-08 17:39:54
|
On Saturday 08 November 2008 12:06:03 Celelibi wrote: > 2008/11/8, P Zoltan <zol...@gm...>: > > On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <ju...@sv...> > > wrote: > >> On Friday 07 November 2008 01:14:35 Glen wrote: > >>> Is there any direction / ideas for what direction the simulator should > >>> go? I have my own ideas, especially now since I've probed the code a > >>> little bit, but what's really better for the project? > >> > >> Some time ago, it was mentioned on the list, that the actual code won't > >> scale. > >> So it's really hard to add new components to the simulator. We need a > >> way to > >> define components more easy. > > > > Actually the components are hard-coded in the program, so to change > > them, > > > you need to recompile ktechlab. That's a huge problem, imo. > > > >> XML would be something to mention here. I don't > >> see the problem to do something like that with the visualisation part, > >> but for > >> the simulator I don't see a good way to do it. > > > > I think the models can be also defined in XML; I've mentioned this on > > the > > > list earlier: > > some 'basic' components should be defined in the program and everything > > else threated as subcircuit. So in XML we should describe two things: the > > > > symbol for the new component and the equivalent subcircuit as the model. > > As I know, spice does something similar: there are some basic parts, > > and > > > the more complex ciruits are threated as subcircuits. > > > > Things get tricky when we want to define some interactive components > > with > > > XML. For that we might need some expression-evaluation algorithms. > > Hum, well. You know, XML is quite a good description language. It is > possible to do anything with it. > But have you ever tried to imagin what a programming language would be in > XML ? > It could looks like > <if test="x == y && x+y > c"> > <then> > <!-- some very useful things --> > </then> > <else> > <!-- yet very useful things --> > </else> > </if> > > that's quite awful to write. > But we could go yet farther by writing the expression in the test with tags > like <and>, <equal>, <add>, <sup> and <var>. And in that way the XML > document would be a ASCII representation of the abstract syntax tree. > > XML is a good language to describe static things (or to describe a snapshot > of dynamic things) with a finit (and static) number of properties. > But if you want to represent dynamic things (like some electronic > components) you may : > - try to make a static representation by usually enumerating every case > - try to embed some kind of programming language. > - In a fashion like javascript inside html pages > - Or as a "tag language". > > > Enumerating case is only possible if the component act like a Finit State > Automaton. That may not be the case for every component. > Embedding language in javascript fashion is (I think) a bad use of > XML.Remember this: "You know you made a poor use of XML when you need some > additionnal parsing". > Embedding a "tag language"... not writable by hand. Not easily readable. > But no additionnal parsing need to be done. > another issue I see with XML is that it would be quite heavy. XML files may > be quite big, parsing everything will take some time. Yes, I don't think this is the way to go.. > I'm not against the use of XML, but I think that only simple components > should be written in XML. Others may be written in C/C++, compiled as .so > and loaded at launch time (or later...). I fully agree with your last point here. I'm not yet familiar with the possibilities of the kdelibs here, but I know, there is a strong plugin- interface to do such things. You are even not bound to a specific language. Kross is the name of the scripting interface, I'm not sure, if this helps here. The longer I think about it, the more I think, we need a plugin interface here, to put the computation-stuff for the components into external libraries that are loaded on demand. These libraries could also contain the representation of the components, of course. We then could make them available via KHotNewStuff so everybody can download them from within the program. These are also ideas mentioned in the wiki, but not as clear as they are to me, now. > But after all, I'm not a developer, I'm just someone who follow that > project. Anyway, thanks for your participation in the discussion. There's no need to be a developer to take part in development ;) bye then julian |
From: Glen <gca...@gm...> - 2008-11-08 18:17:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I'm not against the use of XML, but I think that only simple components >> should be written in XML. Others may be written in C/C++, compiled as .so >> and loaded at launch time (or later...). > I fully agree with your last point here. I'm not yet familiar with the > possibilities of the kdelibs here, but I know, there is a strong plugin- > interface to do such things. You are even not bound to a specific language. > Kross is the name of the scripting interface, I'm not sure, if this helps > here. > > The longer I think about it, the more I think, we need a plugin interface > here, to put the computation-stuff for the components into external libraries > that are loaded on demand. These libraries could also contain the > representation of the components, of course. Which libraries are being referred to here? I really hope you guys aren't thinking of compiling .so libs for distribution of component libraries. - --G -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJFdenLstl3vProOARAuXPAJ9kmQQ2roLxvje0oM6XstvNxxAkIQCfYpVw PVAywH2LlrKGSYO8PjYn1Ic= =PaWQ -----END PGP SIGNATURE----- |
From: P Z. <zol...@gm...> - 2008-11-10 17:35:28
|
On Sat, 08 Nov 2008 20:28:00 +0100, Glen <gca...@gm...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > First things first, I think. > > We need a dev roadmap before we can start arguing file formats. > > 1. What do we want it to *do*? > > 2. How do we make it do what we want, and how can we leverage what we > already have to make it do it sooner? > > We're already discussing #2 without being too sure of #1. I totally agree. I also see a #0 problem: what about project management issues? I mean: the project on sourceforge doesn't really have an admin, as jason doesn't have time for this project (see the bottom of the main page of the wiki). Also when do we make releases, on how many branches will we work (kde3, kde4), coding standards, ... A roadmap is definitely needed. I think we should discuss about it, too. Zoltan |
From: Julian B. <ju...@sv...> - 2008-11-08 18:47:07
|
On Saturday 08 November 2008 19:17:11 Glen wrote: > >> I'm not against the use of XML, but I think that only simple components > >> should be written in XML. Others may be written in C/C++, compiled as > >> .so and loaded at launch time (or later...). > > > > I fully agree with your last point here. I'm not yet familiar with the > > possibilities of the kdelibs here, but I know, there is a strong plugin- > > interface to do such things. You are even not bound to a specific > > language. Kross is the name of the scripting interface, I'm not sure, if > > this helps here. > > > > The longer I think about it, the more I think, we need a plugin interface > > here, to put the computation-stuff for the components into external > > libraries that are loaded on demand. These libraries could also contain > > the representation of the components, of course. > > Which libraries are being referred to here? I use the term "library" in a way here to distribute components. So this is may be a tar.gz archive that can be downloaded and imported into KTechLab. The KDE framework does have a infrastructure for such kind of things (KHotNewStuff). This way they distribute wallpapers for instance. In KDE4 this thing was expanded to be able to distribute all sort of plugins or stuff that isn't shipped in the default version of a program. > I really hope you guys aren't thinking of compiling .so libs for > distribution of component libraries. No, as Alan just meant: scripting should be the way to go and yes, it should be easily possible to have something like that with the help of Kross. It makes it possible to write python or ruby or ECMA-scripts and have access to your Qt/KDE classes. This could also be .so files or .dlls on windows, it just has to implement the right interface. (Plasmaoids are mainly .so files on Linux) bye then julian |
From: Glen <gca...@gm...> - 2008-11-08 19:28:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First things first, I think. We need a dev roadmap before we can start arguing file formats. 1. What do we want it to *do*? 2. How do we make it do what we want, and how can we leverage what we already have to make it do it sooner? We're already discussing #2 without being too sure of #1. We do have to get the QT4/KDE4 port completed if we want to get it into kdeedu (grawr this app doesn't belong there... it belongs in kdeeng, kdeedu is full of toys.) <rant> I guess this means I have to TRY to get used to kde4. The new one's a PITA to use with a trackpad. The K menu is absolutely horrible and I can't find anything in it, including how to switch it to a normal menu. The panels lost nearly ALL of their configurability. In all, I really, really hate KDE4. </very viciously edited rant> - --G -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJFehALstl3vProOARAiroAJ9bGY3s5ZfqcbxNJTsOjC9552YUnACfdvA9 wtfYflpRIe+ih4K1p8kC7Ds= =DLHM -----END PGP SIGNATURE----- |
From: Lawrence S. <det...@gm...> - 2008-11-08 20:07:48
|
Glen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > First things first, I think. > > We need a dev roadmap before we can start arguing file formats. > > 1. What do we want it to *do*? > > 2. How do we make it do what we want, and how can we leverage what we > already have to make it do it sooner? > > We're already discussing #2 without being too sure of #1. > > We do have to get the QT4/KDE4 port completed if we want to get it into > kdeedu (grawr this app doesn't belong there... it belongs in kdeeng, > kdeedu is full of toys.) > > <rant> > I guess this means I have to TRY to get used to kde4. The new one's a > PITA to use with a trackpad. The K menu is absolutely horrible and I > can't find anything in it, including how to switch it to a normal menu. > The panels lost nearly ALL of their configurability. In all, I really, > really hate KDE4. > </very viciously edited rant> > Try right-clicking on the K-Menu icon and you will find a "Switch to Classic Menu Style" entry there... <rant> I agree that we lost a LOT of configurability, I'm hoping they slowly add it back in. I fully understand what a re-write does to a codebase like KDE and am willing to be patient. And if they don't, I don't think it would be very hard to start a partial fork to write replacement configuration parts and applications, or do a full fork if it came to that. There are SOO many people that want that stuff back, We're using KDE for a REASON, otherwise gnome (ugh) would be fine. </rant> > - --G > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJFehALstl3vProOARAiroAJ9bGY3s5ZfqcbxNJTsOjC9552YUnACfdvA9 > wtfYflpRIe+ih4K1p8kC7Ds= > =DLHM > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > |
From: Julian B. <ju...@sv...> - 2008-11-08 20:33:15
|
On Saturday 08 November 2008 20:28:00 Glen wrote: > First things first, I think. > > We need a dev roadmap before we can start arguing file formats. > > 1. What do we want it to *do*? > > 2. How do we make it do what we want, and how can we leverage what we > already have to make it do it sooner? > > We're already discussing #2 without being too sure of #1. > > We do have to get the QT4/KDE4 port completed if we want to get it into > kdeedu (grawr this app doesn't belong there... it belongs in kdeeng, > kdeedu is full of toys.) I partly agree here. The point why I see KTechLab in kdeedu is, because of it's really easy to use interface. It's ready to be used in (higher) education. Engineers do want something more practical here, don't they? Some something that plays together with all the professional tools out there. I for myself use this discussion as some kind of brain storming what would be our possibilities without inventing everything from scratch. I agree that we have to define, what exactly we want, before getting more precise on techniques we are going to use. -- julian |
From: Alan G. <ag...@sp...> - 2008-11-08 21:00:28
|
> I partly agree here. The point why I see KTechLab in kdeedu is, because of > it's really easy to use interface. It's ready to be used in (higher) > education. Engineers do want something more practical here, don't they? Some > something that plays together with all the professional tools out there. I see the primary use case for the parts library as: you have a datasheet, the part isn't in the library, you create a new part, inherit the differential equations from a reference part, then add the parameters from the datasheet, then try out your part in a few test circuits to make sure that the curves it puts out are in the ballpark, then party on... A slightly less common use case is that you have a part that nobody's even heard of, say the 71A. Lets say that there isn't even a DHT model yet, so you create a new class called "DHT" then using a combination of elemental properties (resistence, transconductance, capacitance) begin to rough in a model for the part, then you'd have to go find the old mathematical equations used to design the damn thing, enter those in, and then try it out... A more general issue in the simulator, is how nonlinear properties are handled... For example, the grid of a typical tube will exponentially begin to source a (classical) current to the cathode of the tube as its voltage approaches and exceeds that of the cathode... Everyone knows how to model linear stuff with matrices... I wonder if there is a similarly elegant/generalizabile technique for simulating nonlinear components so that the current iterative approach can be avoided... -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: Glen <gca...@gm...> - 2008-11-09 18:01:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are still a lot of things missing in KDE 4.1. There appears to be no way to put a random app from the menus into a panel; apparently they all have to be plasmoids, and you cant use a random plasmoid. The wireless / network monitor cannot be moved to a different panel... in fact, more than half the default icons cant be moved. I cant change my keyboard layout. Im stuck with deadkeys I cant use... hence no quotes in this message and no apostrophes. Positive: intrepid has kernel 2.6.27. My wireless works beautifully now. Serious negative: KTechLab will not compile. My bad, I likely dont have the KDE3 dev libs installed anymore. Getting back to the discussion though, I want to see the simulator have its computation built in (even so far as replacing a subcircuit with an expression if not on the same sheet if desired to speed up computation), so it will need an equation editor. These equations could be saved in the subcircuit file. The XML is strictly a simple way of organizing the file format IMO, so that the component attributes, the SVG, the footprint, and if need be a (simple!) 3D model of the component can be included in the library. When KTechLab saves a circuit file, I like the idea of taking the component definitions with it. This functionality could be user-option to keep the file size small, i.e., ´Save Stuffed Circuit´ or ´Save Simple Circuit.´ So I have been imagining: component format: * component name, id, etc. * component reference header * component attributes (these are what are acted upon by simulator, i.e., R, C, L, W, V, or whatever else this component needs.) * component symbol SVG * component PCB footprint (if defined, also SVG) * component rough 3D shape (if defined) a Library would contain: * library symbol (SVG, for the list to the left) * component1 * component2 * ... etc. The library file would of course be shipped compressed and with a component manifest that could be searched, so that when looking for a component within the software it could check its local libraries first, and if it is not there, search our component library database on the web and automatically download the compressed file with the manifest. Add a user-submitted section and a symbol / footprint / simple model designer and we have an extensible library system on par with anything else out there, including the Big Expensive Guys, except people dont have to go looking all over the web. We´ll have it all in one place, and have a couple of mirrors just in case. Component formats for custom versions of simple items can still use inheritance. A really simple example: class resistor class 1/4_100 resistor (R 100m W .25) Still the same thing, just different numbers. Where we get into a difficult spot is where we need to use other components to make a new one. Iĺl call it a compound component for lack of a better word: compound component transformer *(all normal component attributes.. name, ref, etc.) *component inductor (primary) *component inductor (secondary1) *component inductor (secondary2) *equation secondary1 = primary V/2 *equation secondary2 = primary V/2 ... and so on. The entire operation of the device could be specified in the equation, or in the case of multiple equations, for example the Z of the transformer, can have multiple named equations that can all be solved for at run-time depending on what data the user is actually asking for. The FlowCode and the PIC processing... I see absolutely no reason to change these one bit. I honestly cant think of anything that should be added, with the exception of a ´processor class´ that all have FlowCode containers. Im not a digital guy so if anyone has a feature request, speak up... - --G Julian Bäume wrote: > On Saturday 08 November 2008 23:31:04 Glen wrote: >> I'm upgrading to ubuntu 8.10 as I write this to make dealing with the >> KDE stuff better and to fix a few things I've torn apart. I had KDE 4.0, >> not 4.1 Classic wasn't available in 4.0 and that's a large part >> wasn't enjoying the experience. > Just a short answer here: I can now understand your rants about KDE4 ;) I can > tell you: it really got better since then and will even be more powerful, when > 4.2 will be released in January. I have to admit, that I'm quite impatient, > too ;) > > julian > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkXJWoACgkQLstl3vProOCKWACgnmZ+IcU+GNQjXqZJw6WRpus2 nwsAn0sZFv66AovX4doNvNfXrTTw/8bQ =F5TV -----END PGP SIGNATURE----- |
From: Lawrence S. <det...@gm...> - 2008-11-09 19:47:13
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Glen wrote: <blockquote cite="mid:491...@gm..." type="cite"> <pre wrap="">-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are still a lot of things missing in KDE 4.1. There appears to be no way to put a random app from the menus into a panel; apparently they all have to be plasmoids, and you cant use a random plasmoid.</pre> </blockquote> >From the K menu, right click an entry, and "add to panel"<br> <blockquote cite="mid:491...@gm..." type="cite"> <pre wrap=""> The wireless / network monitor cannot be moved to a different panel... in fact, more than half the default icons cant be moved.</pre> </blockquote> Not sure about that, click on the little kde4 paint splash thingy on the right end of the main panel, and then you can lick and drag almost everything around. Desktop widget can be moved by hovering over it, and then dragging the black bar that shows up.<br> <blockquote cite="mid:491...@gm..." type="cite"> <pre wrap=""> I cant change my keyboard layout. Im stuck with deadkeys I cant use... hence no quotes in this message and no apostrophes. </pre> </blockquote> K menu >> System Settings >> Regional and Language >> Keyboard Layout >> Enable Keyboard layouts .......<br> This is also where you can change to 12 hour time format (under time and dates tab)<br> <blockquote cite="mid:491...@gm..." type="cite"> <pre wrap=""> Positive: intrepid has kernel 2.6.27. My wireless works beautifully now. </pre> </blockquote> Kool! Hope I was able to help somewhat.. ~Lawrence<br> <blockquote cite="mid:491...@gm..." type="cite"> <pre wrap=""> Serious negative: KTechLab will not compile. My bad, I likely dont have the KDE3 dev libs installed anymore. Getting back to the discussion though, I want to see the simulator have its computation built in (even so far as replacing a subcircuit with an expression if not on the same sheet if desired to speed up computation), so it will need an equation editor. These equations could be saved in the subcircuit file. The XML is strictly a simple way of organizing the file format IMO, so that the component attributes, the SVG, the footprint, and if need be a (simple!) 3D model of the component can be included in the library. When KTechLab saves a circuit file, I like the idea of taking the component definitions with it. This functionality could be user-option to keep the file size small, i.e., ´Save Stuffed Circuit´ or ´Save Simple Circuit.´ So I have been imagining: component format: * component name, id, etc. * component reference header * component attributes (these are what are acted upon by simulator, i.e., R, C, L, W, V, or whatever else this component needs.) * component symbol SVG * component PCB footprint (if defined, also SVG) * component rough 3D shape (if defined) a Library would contain: * library symbol (SVG, for the list to the left) * component1 * component2 * ... etc. The library file would of course be shipped compressed and with a component manifest that could be searched, so that when looking for a component within the software it could check its local libraries first, and if it is not there, search our component library database on the web and automatically download the compressed file with the manifest. Add a user-submitted section and a symbol / footprint / simple model designer and we have an extensible library system on par with anything else out there, including the Big Expensive Guys, except people dont have to go looking all over the web. We´ll have it all in one place, and have a couple of mirrors just in case. Component formats for custom versions of simple items can still use inheritance. A really simple example: class resistor class 1/4_100 resistor (R 100m W .25) Still the same thing, just different numbers. Where we get into a difficult spot is where we need to use other components to make a new one. Iĺl call it a compound component for lack of a better word: compound component transformer *(all normal component attributes.. name, ref, etc.) *component inductor (primary) *component inductor (secondary1) *component inductor (secondary2) *equation secondary1 = primary V/2 *equation secondary2 = primary V/2 ... and so on. The entire operation of the device could be specified in the equation, or in the case of multiple equations, for example the Z of the transformer, can have multiple named equations that can all be solved for at run-time depending on what data the user is actually asking for. The FlowCode and the PIC processing... I see absolutely no reason to change these one bit. I honestly cant think of anything that should be added, with the exception of a ´processor class´ that all have FlowCode containers. Im not a digital guy so if anyone has a feature request, speak up... - --G Julian Bäume wrote: </pre> <blockquote type="cite"> <pre wrap="">On Saturday 08 November 2008 23:31:04 Glen wrote: </pre> <blockquote type="cite"> <pre wrap="">I'm upgrading to ubuntu 8.10 as I write this to make dealing with the KDE stuff better and to fix a few things I've torn apart. I had KDE 4.0, not 4.1 Classic wasn't available in 4.0 and that's a large part wasn't enjoying the experience. </pre> </blockquote> <pre wrap="">Just a short answer here: I can now understand your rants about KDE4 ;) I can tell you: it really got better since then and will even be more powerful, when 4.2 will be released in January. I have to admit, that I'm quite impatient, too ;) julian ------------------------------------------------------------------------ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world <a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a> ------------------------------------------------------------------------ _______________________________________________ Ktechlab-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Kte...@li...">Kte...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a> </pre> </blockquote> <pre wrap=""><!----> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org">http://enigmail.mozdev.org</a> iEYEARECAAYFAkkXJWoACgkQLstl3vProOCKWACgnmZ+IcU+GNQjXqZJw6WRpus2 nwsAn0sZFv66AovX4doNvNfXrTTw/8bQ =F5TV -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world <a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a> _______________________________________________ Ktechlab-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Kte...@li...">Kte...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a> </pre> </blockquote> <br> </body> </html> |
From: Glen <gca...@gm...> - 2008-11-10 02:32:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you can write the equation on paper, can you not also write the simple steps to solving it? f(i) is too complex. Write (1/2i * log(i)) instead. log(i) should be built-in.. not the whole equation. Improvements to the models shouldn't be dependent on improvements to the system as a whole. - --Glen Celelibi wrote: > > About embedding equations inside the XML. It will be possible describe every > component with equations only if we can define our own functions. > But defining a function is useless if you don't know how to solve equation > containing it. So you need to define a way to solve any equation containing > that function. But maths says it's not possible. > Let me explain with a small example. > You have a dipole for which current/voltage is such as u=f(i)+g(i). Of > course, you want to calculate i from u. If f is a polynomial and g is > something that deals with logarithm or exponential, a generic solver will > have some pain to find something. > What I try to explain is that embeding equation inside a component > definition will lead to unsolvable problems. > > I think a more powerful solution would be to make the XML say something like > : > MyComponent behave following That_Model with parameters "voltage in pin1", > "current in pin2" etc. > > I really really think embedding equations is a bad idea. > > > Celelibi > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkXnRgACgkQLstl3vProOCMcACfVJvX7XZ4J78hbsCakbEaFywN QDAAnjRHM5cVLFlXALeg/xByyfYiNDiA =q7A1 -----END PGP SIGNATURE----- |
From: Glen <gca...@gm...> - 2008-11-10 13:02:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Perhaps I should term what I mean an "expression solver," then? It's not meant to solve differential equations nor anything that complex. Though anything that can be solved using simple steps shouldn't be too hard as long as the expression is built with simple components. The parser itself will be more difficult! i^2 + log(i) is very much in the range of what I mean. Log functions have been built into many math libraries for a long time. Every 3D modeler out there also solves differentials, but that's going a bit far unless someone else wants to put it in. Matrix math for linear equations is already in there, I saw. There's probably an easy way to hook it up so it's accessible from the outside. - --G Celelibi wrote: > 2008/11/10 Glen <gca...@gm...> > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> If you can write the equation on paper, can you not also write the >> simple steps to solving it? >> >> f(i) is too complex. Write (1/2i * log(i)) instead. log(i) should be >> built-in.. not the whole equation. Improvements to the models shouldn't >> be dependent on improvements to the system as a whole. >> > > My example with f and g was too general. > let u = i^2 + log(i) > > I wish you a very very good luck to solve it. > Actually, you just can't ! > The only known ways to solve such an equation are approximations. And the > only I know are numerical approximations. > Knowing how to compute a logarithm and it's reciprocal does not make you > know how to solve equations it appears in. > > We don't have to builtin every equation.We just need some general models > that will be able to solve some kind of equations. > For example a linear algebra solver that uses matrix can be used a lot of > time. > > Another issue I see with equations inside component definition is > differencial equation. How to write them ? How to solve them ? > > > Celelibi > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkYMM4ACgkQLstl3vProOCLeQCghPkYqBdhG9HFyQYGxiDIuN6c WyQAnjkE3M5hVLN3VQPCwpK1r/c1+tHI =Xl/1 -----END PGP SIGNATURE----- |
From: Glen <gca...@gm...> - 2008-11-08 22:31:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are a few decent tube equations out there.. I don't see why they'd be to hard to inherit to use / modify. I have no idea if anyone's found a better way to model them that doesn't involve iteration, though! I DO want to make parts inheritable... there's no reason not to. Who else does that? >I partly agree here. The point why I see KTechLab in kdeedu is, because >of >it's really easy to use interface. It's ready to be used in (higher) >education. Engineers do want something more practical here, don't they? >Some >something that plays together with all the professional tools out >there. Easy-to-use doesn't have to mean toy or educational-use-only ;) Nothing wrong with professionally using the same software you learned a trade on! KTechLab has a better interface than the vast majority of apps in the same vein. It seems that professional-quality is where we're looking to take it and I'm all for that! Maybe one day we'll spearhead a new KDE app category. I suppose one thing I should do is get feature lists from all of the favorite simulation apps and compare what we already have to it. I just wish that publishing web pages was simpler. I'm a horrible web designer. I'm upgrading to ubuntu 8.10 as I write this to make dealing with the KDE stuff better and to fix a few things I've torn apart. I had KDE 4.0, not 4.1 Classic wasn't available in 4.0 and that's a large part of why I wasn't enjoying the experience. - --G (why is it I write books in response, delete them, then rewrite different books and send?) Alan Grimes wrote: >> I partly agree here. The point why I see KTechLab in kdeedu is, because of >> it's really easy to use interface. It's ready to be used in (higher) >> education. Engineers do want something more practical here, don't they? Some >> something that plays together with all the professional tools out there. > > I see the primary use case for the parts library as: you have a > datasheet, the part isn't in the library, you create a new part, inherit > the differential equations from a reference part, then add the > parameters from the datasheet, then try out your part in a few test > circuits to make sure that the curves it puts out are in the ballpark, > then party on... > > A slightly less common use case is that you have a part that nobody's > even heard of, say the 71A. Lets say that there isn't even a DHT model > yet, so you create a new class called "DHT" then using a combination of > elemental properties (resistence, transconductance, capacitance) begin > to rough in a model for the part, then you'd have to go find the old > mathematical equations used to design the damn thing, enter those in, > and then try it out... > > > A more general issue in the simulator, is how nonlinear properties are > handled... For example, the grid of a typical tube will exponentially > begin to source a (classical) current to the cathode of the tube as its > voltage approaches and exceeds that of the cathode... Everyone knows how > to model linear stuff with matrices... I wonder if there is a similarly > elegant/generalizabile technique for simulating nonlinear components so > that the current iterative approach can be avoided... > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkWExoACgkQLstl3vProOBA8wCeIxjqPtqeGlt1oiElF0DZvtTk xuIAn2l9vGmKY4M+7HHkmsNxsd8eeBFB =mFAC -----END PGP SIGNATURE----- |
From: Julian B. <ju...@sv...> - 2008-11-09 00:07:30
|
On Saturday 08 November 2008 23:31:04 Glen wrote: > I'm upgrading to ubuntu 8.10 as I write this to make dealing with the > KDE stuff better and to fix a few things I've torn apart. I had KDE 4.0, > not 4.1 Classic wasn't available in 4.0 and that's a large part > wasn't enjoying the experience. Just a short answer here: I can now understand your rants about KDE4 ;) I can tell you: it really got better since then and will even be more powerful, when 4.2 will be released in January. I have to admit, that I'm quite impatient, too ;) julian |
From: P Z. <zol...@gm...> - 2008-11-09 10:09:14
|
On Sat, 08 Nov 2008 23:31:04 +0100, Glen <gca...@gm...> wrote: > > I suppose one thing I should do is get feature lists from all of the > favorite simulation apps and compare what we already have to it. I just > wish that publishing web pages was simpler. I'm a horrible web designer. Use the wiki: http://ktechlab.org/wiki/index.php?title=Main_Page I've already tried to enumerate all the feautres, see here : http://ktechlab.org/wiki/index.php?title=Devel:Existing_architecture#Features_.E2.80.93_detailed Zoltan |
From: Glen <gca...@gm...> - 2008-11-10 15:13:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I must be completely misunderstanding your point, or you mine. I've been of the impression that people have been suggesting that the specific equations for each model should be hard-coded into the software, not just the solvers! My thought on that was "Uh.. what?" haha... I think it turns out we are in agreement after all. > I'm not sure to understand. (I'm just a poor frog, my english is not > perfect.) Don't be so hard on yourself. Sometimes mine isn't, either. - --G Celelibi wrote: > 2008/11/10 Glen <gca...@gm...> > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Perhaps I should term what I mean an "expression solver," then? It's not >> meant to solve differential equations nor anything that complex. >> > > So, I think x^2 + log(x) = 0 is too complex. > > Though anything that can be solved using simple steps shouldn't be too >> hard as long as the expression is built with simple components. The >> parser itself will be more difficult! >> >> i^2 + log(i) is very much in the range of what I mean. Log functions >> have been built into many math libraries for a long time. Every 3D >> modeler out there also solves differentials, but that's going a bit far >> unless someone else wants to put it in. > > > I'm not sure to understand. (I'm just a poor frog, my english is not > perfect.) > So you think a "generic solver" could solve i^2 + log(i) = 0 ? > I think (but not sure) it has been proved that such equations can't be > solved without using numerical approximation. > > What argument have you against just saying in the component : > - which solver the component uses > - what parameter we give to the solver > ? > > This would be very flexible. We could have a solver that uses linear > algebra, another that just take a "simple equation" and try to solve it, > another that try to solve numerically using Newton method etc. > > And since there is a so wide range of possible solver, these should be > pluggable to ktechlab. That in order to add solvers without needing a new > release of the whole "ktech system". > Ok numerical solving works pretty well for almost every differetiable > function. But it may not be quick and/or accruate enough for everything. So > when adding a new component, we may need to add a new solver. > > > Celelibi > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkYT2UACgkQLstl3vProODaqwCeJ4OMVLVsds607DX1fbFAQtig P+4Anj9qTCQrsWk+9yQXmHCqlbUzNc2d =0ARE -----END PGP SIGNATURE----- |
From: P Z. <zol...@gm...> - 2008-11-09 10:49:54
|
On Sat, 08 Nov 2008 19:25:41 +0100, Alan Grimes <ag...@sp...> wrote: > That doesn't apply because in our use case, what we are trying to > encode, as data are programs, which necessarily need to be interpreted, > no shame in that. > > It is absolutely necessary that the user be able to design components. > So compiled C++ is out of the question. > That's clear. But I still don't understand why do we need _programs_ describing new components? Where and when should those program run? (I don't really know the internal workings of the simulator) Wouldn't be enough to describe the equations of the part? > A. Loading circuit save files which contain references to library > components which may not be available when loaded. > A few ideas (brainstorming style): - create an export option to save the circuit with all the needed components attached - ktechlab might try to connect to some 'component repositories' and search for the needed components there The components could be identified by their name. > B. Being able to easily create derived components. IE, specifying that > "this component is just like that component but here are some specific > specifications". That way we'd have a model for a darlington pair > transistor, then when the user finds a datasheet, he can quickly write a > specific part specification based on the generic library model. > I'd solve that parametrisation. (inspired from spice :D) For instance: a darlington pair with: beta=... parasitic_capacitance_be=... and so on... > >> I'm not against the use of XML, but I think that only simple components >> should be written in XML. Others may be written in C/C++, compiled as >> .so and loaded at launch time (or later...). > What about different CPU architectures? And 32bit vs 64bit? Plus see user created component argument earlier. I consider binarty, compiled component a bad idea, because: they would need to be recompiled for each platform and because a 'normal' user won't have a c++ compiler installed on his system. Zoltan |
From: Celelibi <cel...@gm...> - 2008-11-09 15:43:21
|
2008/11/9 P Zoltan <zol...@gm...> > On Sat, 08 Nov 2008 19:25:41 +0100, Alan Grimes <ag...@sp...> > wrote: > > > That doesn't apply because in our use case, what we are trying to > > encode, as data are programs, which necessarily need to be interpreted, > > no shame in that. > > > > It is absolutely necessary that the user be able to design components. > > So compiled C++ is out of the question. > > > > That's clear. > > But I still don't understand why do we need _programs_ describing new > components? Where and when should those program run? (I don't really know > the internal workings of the simulator) Wouldn't be enough to describe the > equations of the part? > There will always be the one new component you can't describe without new formulas or new algorithm. Globally, every analogue component is composed of several pins and some formulas that link current and voltage of every pin. Andn you know, linear algebra theory says the vector space of functions has infinite dimention. That means it's not possible to have a list of every possible model of function. That's why I suggest to keep them outside of the simulator's core. I think an advanced user (understand, C/C++ coder) should be able to add his own computation formulas to the simulator. About digital circuits: As a circuit become complex, it's execution time grows. Designing a whole processor with only logical gates will lead to a huge execution time. Being able to write some components in C/VHDL/whatever, really help. I'm speaking about digital circuits, but it must be the same for analogue circuit. For example when your component is a specialization of another which is a composition of two specialized components. You may really save computation time by rewriting formulas for this component. >> I'm not against the use of XML, but I think that only simple components > >> should be written in XML. Others may be written in C/C++, compiled as > >> .so and loaded at launch time (or later...). > > > > What about different CPU architectures? And 32bit vs 64bit? Plus see user > created component argument earlier. I consider binarty, compiled component > a bad idea, because: they would need to be recompiled for each platform > and because a 'normal' user won't have a c++ compiler installed on his > system. > You're right. That's why I refactored (?) my idea to put only computation in .so. I think adding components should be the last and easiest thing to do, but everything should be ready for that. Celelibi |
From: Alan G. <ag...@sp...> - 2008-11-09 18:02:50
|
> But I still don't understand why do we need _programs_ describing new > components? Where and when should those program run? (I don't really know > the internal workings of the simulator) Wouldn't be enough to describe the > equations of the part? Equations are programs, or rather the source code for programs that are designed by whatever interpreter processes the equations. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |