gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] bug in pulse


From: al davis
Subject: Re: [Gnucap-devel] bug in pulse
Date: Fri, 29 Nov 2013 19:57:26 -0500
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

On Wednesday 27 November 2013, Felix Salfelder wrote:
> if the rise time is 0, the pulse value at _delay is wrong.

.....

> the pulse is evaluated to 1 at time=.1. i think this is wrong
> because for any positive value of delay it is (should be)
> zero, and delay=0 should actually be treated as
> delay=epsilon with epsilon a positive number somewhere
> between 0 and dtmin (if not just the limit -> +0).
> 
> the example above shows that _iv is required at _delay, as
> the first event is interpreted as pre-rise by the solver
> (see output below).
> 
> i'm a bit unsure on how to fix this. also fwiw, there is a
> discrepancy between the manual.pdf and the implementation
> wrt to ">" vs ">=" in tr_eval, lines "if (time >=
> _delay+_rise+_width+_fall) {".
> 
> any clues?

It's not a bug, it's a feature!  :-)

The purpose of "pulse" is spice compatibility, and so it is, 
bug-for-bug.

The documentation is obsolete.

In 2007, RCS 26.55 2007/12/05  it was changed for Spice 
compatibility.

In the older code, the interpretation of delay when period was 
specified was also different from what Spice did.

Having said that, I agree with you on what behavior makes sense, 
which is why it was that way originally when I did what I 
thought made sense as opposed to studying the nuances of spice 
code.

Then I wondered why there are so many rejections with your 
example.  There is only one rejection when the code is changed 
to the old way.

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.

Time             v(1)            v(2)            next(c1) 
 0.09999999955   0.              0.              0.                
 0.1             0.9999900001    223.044p        0.09999999975           
 0.1000000002    0.9999900001    443.042p        0.1000000006              
 
So, although it looks like a problem, it is working as designed.


You can get the behavior you want by changing ">=" to ">".  If 
you do you must change all of them in that function.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]