Re: [Gnucap-devel] Re: [Help-gnucap] how to model sinusoidal dependence on charge?

[al davis]

On Thursday 19 November 2009, address@hidden 
wrote:
> I have extended an old version of gnucap (2008-08-10 !) to
>  enable the  use of such functions :
> E1 (out 0 in 0) FUNC(3,5) exp=true   means : out=e^(3*in+5)
> E1 (out 0 in 0) FUNC(314,-78.5) cos=true means :
>  out=cos(314*in -0,785)  =  sin(314*in)
> E1 (out 0 0 0) FUNC(4,5) xtime=true means : out=4*t+5 where t
>  is the  time of the simulation
> 
> I hope it fit with a new version but I haven't time enough to
>  test it.  So try it and if it doesn't fit
> I'll write it again in a few day (I have started to upgrade
>  to 2009-11-10)
> 
> Here what I did in a test purpose. It's not a good program,
>  you are free  to enhance it.
> Morever, I don't know how such an extension fit with the
>  convergence  algorithm.
> So I distribute it in the hope that it will be useful but
>  WITHOUT ANY  WARRANTY      ;-)
> 

Thank you!!

I would like to distribute it so others can use it.  Is that ok?

It needs some changes to match the latest version, but they 
should be easy.

A few comments ...

1. You don't need to change the makefile to use it.  Instead, 
compile it as a shared object (.so on Linux) and use the "load" 
command to bring it in.  This way, when the stable version comes 
out, and the distros package it, you can add things like this 
without recompiling the whole simulator.

"g++ -shared -fPIC -o bm_func.so bm_func.cc"

then from gnucap:

"load /full/path/to/bm_func.so"

or on the command line:

"gnucap -a /full/path/to/bm_func.so  ......."


2. As it stands (with version update) I can include it with the 
separate "tools" tarball, if it is ok with you.

Better yet ...  I would prefer that it is done as 5 separate 
files, one for each function, using "bm_tanh.cc" as a style 
guide.  If you can do this, I will include it with the main 
distribution, along with posy and tanh that are already there.


3. You made a comment "//why??" on a line "untested();" ..

This is a hint to me that I really need to explain the testing 
macros!

In a normal build, those macros are eliminated and so do 
nothing.  If you use the "old" build system, with "make debug" 
which defines "TRACE_UNTESTED", it prints a trace whenever that 
line is executed.  It is extremely useful in making test cases 
that really cover the code.  What I usually do when making test 
files is to insert those "untested();" calls after every curly 
brace, then take them out when I know that block is adequately 
tested, and there are files in the test suite that prove it.  
When you see any left in distribution code, it is an admission 
that the official test suite misses that line, and that file 
needs better testing.

When you see "itested();" it means that there are informal tests 
that have shown that block works as intended, but  they are not 
in the official test suite.

Others "trace1", and similar ones, are also used in debugging.  
In a debug version, they can be turned on or off.  In a normal 
build, they are eliminated.

All of these are truly eliminated in a normal build, so there is 
no overhead.


Thanks again for the contribution!!