[Top][All Lists]

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

Re: [Gnucap-devel] dc command

From: Felix Salfelder
Subject: Re: [Gnucap-devel] dc command
Date: Tue, 17 Sep 2013 13:31:38 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Sep 15, 2013 at 03:20:06AM -0400, al davis wrote:
> I think the best way to move forward is to incorporate the stack 
> version of u_sim_data to main, after review and testing, then 
> let cook as a plugin for a while.

the stack version is now in "vdcstack". just the plugin is in
the "dc" branch in plugins/

> I think it would be better to change it so it always uses the 
> stack.  The old single level would be just the stack with only 
> one thing on it.

i've replaced _vdc and (de)allocators to _vdcstack. this looks a bit
simpler now.

> Regardless, it needs a test to be sure it is properly emptied.

in fact it's not, if something goes wrong during simulation. I don't
have a (small enough) example to test the non-converging case :/

> Regarding ....
> Looks interesting .. much derived from the transient code.
> I noticed some failed regressions and questionable regressions.
> Failed regressions:
> It breaks the A to D conversion.  It seems that all analog nodes 
> are reported to have logic value "4.21" which means unknown, not 
> valid logic.

it just printed wrong stuff, because it didn't accept first (that's
because i also want to print rejected steps). i've moved the outdata
calls around a bit.

also, the initial op has control 1, not 0 (1=scUSER looks better to me),
so the tests still 'fail'.

> Questionable regressions:
> Some tests, most notably trcurve*, give different results.  At 
> first glance, the differences seem insignificant, might be an 
> improvement, but this needs to be explained.

the initial guess is different. in non pathological cases this guess it
closer, but that doesnt mean the accepted solution will be better...


reply via email to

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