On Thursday 19 November 2009, [email protected] 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!! _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
