Hi Al thanks for your insight.
On Fri, Nov 29, 2013 at 07:57:26PM -0500, al davis wrote: > It's not a bug, it's a feature! :-) > > The purpose of "pulse" is spice compatibility, and so it is, > bug-for-bug. i don't know spice very well, an i don't see a need for bug-for-bug compatibility. > After a bit of puzzling and testing, that too becomes clear. > It's based on truncation error. The state change seems wrong, > so back off and try again with smaller steps. It keeps getting > smaller and smaller. this example only demonstrates the problem, other examples just don't converge at all or do other fancy things they clearly shouldnt. which is bad. the problem seems to be a conflict between the spice-like evaluator and the event mechanism (does spice use events?). if spice compatibility implies a broken pulse or requires a more elaborate implementation (events at _delay-dtmin?) i'd be really in favor of ">" over "=>" over malfunction. (i see no difference between ">" and "=>" in nonzero rise/fall cases...) my 2cts felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
