echempp-devel Mailing List for EChem++ (Page 23)
Status: Beta
Brought to you by:
berndspeiser
Menu
▾
▴
echempp-devel — discussions of developer involved with EChem++
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(6) |
Dec
(1) |
| 2005 |
Jan
(3) |
Feb
(12) |
Mar
(4) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
(9) |
Sep
(2) |
Oct
|
Nov
(5) |
Dec
(4) |
| 2006 |
Jan
(56) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(29) |
Jun
(38) |
Jul
(3) |
Aug
(4) |
Sep
(5) |
Oct
(1) |
Nov
(33) |
Dec
(26) |
| 2007 |
Jan
|
Feb
(56) |
Mar
(68) |
Apr
(14) |
May
(25) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(60) |
| 2008 |
Jan
(15) |
Feb
|
Mar
(59) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(17) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bernd S. <ber...@un...> - 2005-02-24 15:40:54
|
Dear all, I have updated the ExcitationFunction module on the cvs server, which now includes an insert() method. This allows to insert a Segment into an ExcitationFunction at a specified position, thereby updating all information in _Imax. While this method checks that the types of the dependent and the independent variable are idential to those required for the excitation function, it does not check additional constraints such as implemented by Alain in his GUI editor, for example that CV LinearSegments need to be alternating in the sign of the potential variation with time. Such checks have to be done outside of the ExcitationFunction library. Please not also, that this new cvs version relies on the up-to-date Quantities code. This has also been updated on the cvs server. Please download and install this first. Unfortunately, there had to be some changes to the user interface of Quantities since the last release (see also the html documentation generated with doxygen when doing `make install' during the installation!). In particular two changes have to be considered: (1) if you should happen to use the version() compile-time function, please do change this into Version() (capital V). The lower-case method version() is now for run-time questioning the version only, i.e. you write Time::Version (); // get info at compile-time or Time t(); t.version (); // get info at run-time (2) There has been a change in the namespace use in Quantities. If you do not define your own quantities, but rather use those predefined in the PhysicalQuantities directory, you should only have to change scope qualifiers for units. For example, previously you wrote TimeUnits::Minute Now you should write _Time::Minute (note the underscore!!) In general, exchange xxxUnits:: as qualifier into _xxx:: at all instances. Sorry about trouble with these changes, but this makes some things more consistent within Quantities. Best regards Bernd -- =================================================================== Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =================================================================== |
|
From: Kai L. <kai...@un...> - 2005-02-14 13:54:49
|
Hi Kim, > $ rpm -q boost > boost-1.32.0-1.fc3 > > export SPIRITSRC=3D/usr/include/boost It seems that the spirit files of the boost-1.3.2 library include their headers with respect to the upper boost directory. Just to be sure: - Is spirit.hpp located in your /usr/include/boost directory? - I need the first part of the error message below. I assume that g++ first complains about missing header files. > > $ make > ... what happens here? > In file included from kineticCompiler.cpp:33: > ../Ecco/parser.hpp: In constructor > `ecco::Parser::definition<ScannerT>::definition(const ecco::Parser&)': > ../Ecco/parser.hpp:298: error: `leaf_node_d' undeclared (first use this > function) > ../Ecco/parser.hpp:298: error: (Each undeclared identifier is reported > only once for each function it appears in.) > ../Ecco/parser.hpp:456: error: `infix_node_d' undeclared (first use thi= s > function) > ../Ecco/parser.hpp:480: error: `inner_node_d' undeclared (first use thi= s > function) > ../Ecco/parser.hpp:502: error: `discard_node_d' undeclared (first use > this function) > ../Ecco/parser.hpp:593: error: `discard_last_node_d' undeclared (first > use this function) > make[2]: *** [libEcco_la-kineticCompiler.lo] Error 1 > make[2]: Leaving directory `/home/krlux/Desktop/ecco > install/Ecco-1.0.1/Ecco' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/krlux/Desktop/ecco > install/Ecco-1.0.1/Ecco' > make: *** [all-recursive] Error 1 > > Regards, Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Kai L. <kai...@un...> - 2005-02-12 18:00:46
|
Hi, > $ gcc -dumpversion > 3.4.2 > > $ rpm -q boost > boost-1.32.0-1.fc3 Ok - I've seen that boost-1.32.0 includes Spirit-1.8.1. We've developed and tested Ecco with boost-1.31.0 (Spirit-1.7.0). Anyway - I assume that some include directives have been changed within the Spirit library. I will check this on Monday. At this opportunity we will provide a new Ecco release on sourceforge, since also the interfaces of the Law classes have been changed. Regards, Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Kim L. <lu...@di...> - 2005-02-11 19:49:35
|
Here is the info you requested.
It would be great, if you could post me some facts about your
environment, i.e
>
> system,
> compiler,
> installed boost and/or spirit version,
> installed ginac version,
> installed GMM++ version
>
system: $ uname -a
Linux zd7280 2.6.10-prep #2 Tue Jan 25 23:34:47 MST 2005 i686 i686 i386
GNU/Linux
$ gcc -dumpversion
3.4.2
$ rpm -q boost
boost-1.32.0-1.fc3
GiNaC-1.3.0
gmm-1.7
export SPIRITSRC=/usr/include/boost
[krlux@zd7280 Ecco-1.0.1]$ export GINACSRC=/usr/local/include/ginac
[krlux@zd7280 Ecco-1.0.1]$ export GINACLIB=/usr/local/lib
[krlux@zd7280 Ecco-1.0.1]$ export GMMSRC=/usr/local/include/gmm
[krlux@zd7280 Ecco-1.0.1]$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/sh: /home/krlux/Desktop/ecco: No such file or directory
configure: WARNING: `missing' script is too old or missing
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for $SPIRITSRC... /usr/include/boost
checking for $GINACSRC... /usr/local/include/ginac
checking for $GINACLIB... /usr/local/lib
checking for $GMMSRC... /usr/local/include/gmm
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking build system type... i686-pc-linux
checking host system type... i686-pc-linux
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for g77 option to produce PIC... -fPIC
checking if g77 PIC flag -fPIC works... yes
checking if g77 supports -c -o file.o... yes
checking whether the g77 linker (/usr/bin/ld) supports shared
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating Ecco/Makefile
config.status: creating Ecco/test/Makefile
config.status: creating Ecco/documentation/Makefile
config.status: creating Patterns/Makefile
config.status: creating Patterns/test/Makefile
config.status: creating Numerics/Makefile
config.status: creating Numerics/documentation/Makefile
config.status: creating Numerics/test/Makefile
config.status: executing depfiles commands
-------------------------------------------------------------
Ecco is now configured and the Makefiles
are generated.
In order to compile it and to generate the documentation
(doxygen required), just type 'make' and then 'make doc'.
For more information, see the README file.
-------------------------------------------------------------
$ make
...
In file included from kineticCompiler.cpp:33:
../Ecco/parser.hpp: In constructor
`ecco::Parser::definition<ScannerT>::definition(const ecco::Parser&)':
../Ecco/parser.hpp:298: error: `leaf_node_d' undeclared (first use this
function)
../Ecco/parser.hpp:298: error: (Each undeclared identifier is reported
only once for each function it appears in.)
../Ecco/parser.hpp:456: error: `infix_node_d' undeclared (first use this
function)
../Ecco/parser.hpp:480: error: `inner_node_d' undeclared (first use this
function)
../Ecco/parser.hpp:502: error: `discard_node_d' undeclared (first use
this function)
../Ecco/parser.hpp:593: error: `discard_last_node_d' undeclared (first
use this function)
make[2]: *** [libEcco_la-kineticCompiler.lo] Error 1
make[2]: Leaving directory `/home/krlux/Desktop/ecco
install/Ecco-1.0.1/Ecco'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/krlux/Desktop/ecco
install/Ecco-1.0.1/Ecco'
make: *** [all-recursive] Error 1
--
Kim Lux, Diesel Research Inc.
|
|
From: Kai L. <kai...@un...> - 2005-02-11 11:25:16
|
Hi, > version 1.0 has the same error, plus two others, both being #include > <gmm/gmm.h> Ok - the bug regarding the gmm/gmm.h directive was fixed in version 1.0.1. Regards, Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Kai L. <kai...@un...> - 2005-02-11 11:21:29
|
Hello Kim, It would be great, if you could post me some facts about your environment, i.e system, compiler, installed boost and/or spirit version, installed ginac version, installed GMM++ version and, if possile, the output of the ./configure command. With this information, I hope to reproduce the error below. Regards, Kai > Version 1.0.1 > > ./configure works fine. > > In file included from kineticCompiler.cpp:33: > ../Ecco/parser.hpp: In constructor > `ecco::Parser::definition<ScannerT>::definition(const ecco::Parser&)': > ../Ecco/parser.hpp:298: error: `leaf_node_d' undeclared (first use this > function) > ../Ecco/parser.hpp:298: error: (Each undeclared identifier is reported > only once for each function it appears in.) > ../Ecco/parser.hpp:456: error: `infix_node_d' undeclared (first use thi= s > function) > ../Ecco/parser.hpp:480: error: `inner_node_d' undeclared (first use thi= s > function) > ../Ecco/parser.hpp:502: error: `discard_node_d' undeclared (first use > this function) > ../Ecco/parser.hpp:593: error: `discard_last_node_d' undeclared (first > use this function) > make[2]: *** [libEcco_la-kineticCompiler.lo] Error 1 > make[2]: Leaving directory `/home/krlux/Desktop/ecco > install/Ecco-1.0.1/Ecco' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/***/Desktop/ecco > install/Ecco-1.0.1/Ecco' > make: *** [all-recursive] Error 1 > > -- > Kim Lux, Diesel Research Inc. > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users= . > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Echempp-devel mailing list > Ech...@li... > https://lists.sourceforge.net/lists/listinfo/echempp-devel > --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Kim L. <lu...@di...> - 2005-02-10 23:16:11
|
version 1.0 has the same error, plus two others, both being #include <gmm/gmm.h> In file included from kineticCompiler.cpp:33: ../Ecco/parser.hpp: In constructor `ecco::Parser::definition<ScannerT>::definition(const ecco::Parser&)': ../Ecco/parser.hpp:299: error: `leaf_node_d' undeclared (first use this function) ../Ecco/parser.hpp:299: error: (Each undeclared identifier is reported only once for each function it appears in.) ../Ecco/parser.hpp:457: error: `infix_node_d' undeclared (first use this function) ../Ecco/parser.hpp:481: error: `inner_node_d' undeclared (first use this function) ../Ecco/parser.hpp:503: error: `discard_node_d' undeclared (first use this function) ../Ecco/parser.hpp:594: error: `discard_last_node_d' undeclared (first use this function) make[2]: *** [libEcco_la-kineticCompiler.lo] Error 1 make[2]: Leaving directory `/home/krlux/Desktop/ecco install/Ecco-1.0/Ecco' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/krlux/Desktop/ecco install/Ecco-1.0/Ecco' make: *** [all-recursive] Error 1 On Thu, 2005-02-10 at 15:16 -0700, Kim Lux wrote: > Version 1.0.1 > > ./configure works fine. > > In file included from kineticCompiler.cpp:33: > ../Ecco/parser.hpp: In constructor > `ecco::Parser::definition<ScannerT>::definition(const ecco::Parser&)': > ../Ecco/parser.hpp:298: error: `leaf_node_d' undeclared (first use this > function) > ../Ecco/parser.hpp:298: error: (Each undeclared identifier is reported > only once for each function it appears in.) > ../Ecco/parser.hpp:456: error: `infix_node_d' undeclared (first use this > function) > ../Ecco/parser.hpp:480: error: `inner_node_d' undeclared (first use this > function) > ../Ecco/parser.hpp:502: error: `discard_node_d' undeclared (first use > this function) > ../Ecco/parser.hpp:593: error: `discard_last_node_d' undeclared (first > use this function) > make[2]: *** [libEcco_la-kineticCompiler.lo] Error 1 > make[2]: Leaving directory `/home/krlux/Desktop/ecco > install/Ecco-1.0.1/Ecco' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/***/Desktop/ecco > install/Ecco-1.0.1/Ecco' > make: *** [all-recursive] Error 1 > -- Kim Lux, Diesel Research Inc. |
|
From: Kim L. <lu...@di...> - 2005-02-10 22:17:00
|
Version 1.0.1 ./configure works fine. In file included from kineticCompiler.cpp:33: ../Ecco/parser.hpp: In constructor `ecco::Parser::definition<ScannerT>::definition(const ecco::Parser&)': ../Ecco/parser.hpp:298: error: `leaf_node_d' undeclared (first use this function) ../Ecco/parser.hpp:298: error: (Each undeclared identifier is reported only once for each function it appears in.) ../Ecco/parser.hpp:456: error: `infix_node_d' undeclared (first use this function) ../Ecco/parser.hpp:480: error: `inner_node_d' undeclared (first use this function) ../Ecco/parser.hpp:502: error: `discard_node_d' undeclared (first use this function) ../Ecco/parser.hpp:593: error: `discard_last_node_d' undeclared (first use this function) make[2]: *** [libEcco_la-kineticCompiler.lo] Error 1 make[2]: Leaving directory `/home/krlux/Desktop/ecco install/Ecco-1.0.1/Ecco' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/***/Desktop/ecco install/Ecco-1.0.1/Ecco' make: *** [all-recursive] Error 1 -- Kim Lux, Diesel Research Inc. |
|
From: Kai L. <kai...@un...> - 2005-02-09 13:21:53
|
Hi, I've added the assignment operator to the excitation function class. Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: <ber...@t-...> - 2005-02-07 18:17:47
|
as a follow up to Alains bug report, I have corrected ecSegments.hpp on the cvs server. Regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2005-02-05 09:09:19
|
Kai Ludwig wrote: Hi, > I've uploaded changed configure.in files: > Now, the option > > --enable-optimize > > is available for each package (including the > top configure script) > > It passes the flags > > -O2 -Wuninitialized -funroll-loops > -funroll-all-loops -fstrict-aliasing > > to g++ OK. I have now uploaded an improved ecSegments.hpp including the exponential Et segment, as requested by Alain. Best regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Kai L. <kai...@un...> - 2005-02-04 16:34:12
|
Hi All, I've uploaded changed configure.in files: Now, the option --enable-optimize is available for each package (including the top configure script) It passes the flags -O2 -Wuninitialized -funroll-loops -funroll-all-loops -fstrict-aliasing to g++ Have a nice weekend, Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: <ber...@t-...> - 2005-01-26 07:37:29
|
Kai Ludwig wrote: Hi, > A simpler (easier to understand) > possibility would be to use the STL vector's back() > function at that point: > > _Imax.push_back(newSeg.maximum() + _Imax.back()); > > instead of > > _Imax.push_back(newSeg.maximum() + *( _Imax.end() - 1 ) ); Indeed, that's possible, and should be safe since _Imax always contains at least one element (this is ensured by the default constructor of DIExcitationFunction<D, I>. I changed the code and this part compiles fine. However, due to the new Quantities libraries, there are some problems. I will try to resolve this as quickly as possible, and then upload the new code to the cvs server. Regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Kai L. <kai...@un...> - 2005-01-12 12:46:56
|
Hello Bernd, > (2) I have made a small change to the add function (the old line ist st= ill > in the code, commented), where I think there was an error: the val= ue > returned from the call to maximum () was overwritten. Probably, th= is > error did not cause any harm since the value was not used further. > But, > anyway, just to prevent future problems ... > > Kai, could you briefly comment on this? Maybe there was no error, then = we > would > have to switch back, but then some comment in the file would be necessa= ry. Ok - it is clean to use '+' instead of '+=3D'. A simpler (easier to understand) possibility would be to use the STL vector's back() function at that point: _Imax.push_back(newSeg.maximum() + _Imax.back()); instead of _Imax.push_back(newSeg.maximum() + *( _Imax.end() - 1 ) ); Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Bernd S. <ber...@un...> - 2005-01-12 09:39:35
|
It seems that this mail never reached the list ...
sorry
-------- Original Message --------
Subject: inits and ends in ExcitationFunction
Date: Sat, 18 Dec 2004 16:36:52 +0100
From: Bernd Speiser <ber...@un...>
Reply-To: ber...@un...
To: ber...@un...
References: <40D...@un...>
Hi,
I have just uploaded to the cvs server some changes in the ExcitationFunction code.
(1) I have added two new member functions to the excitation functions
(a) std::vector<I> inits (void)
(b) std::vector<I> ends (void)
These functions return a vector with the values of the independent
variable at the beginning of all segments (inits) and at the ends of
all segments (ends).
Alain, I don't know whether you are in this mailing list (I can't get acces to
the list admin page in the moment; please send me a short note if you are!!!),
but these two functions should give you all the information you need for your
GUI. Just retrieve the values needed from the return vectors.
(2) I have made a small change to the add function (the old line ist still
in the code, commented), where I think there was an error: the value
returned from the call to maximum () was overwritten. Probably, this
error did not cause any harm since the value was not used further. But,
anyway, just to prevent future problems ...
Kai, could you briefly comment on this? Maybe there was no error, then we would
have to switch back, but then some comment in the file would be necessary.
Regards
Bernd
--
=======================================================================
Bernd Speiser
Institut f"ur Organische Chemie
Auf der Morgenstelle 18
D-72076 T"ubingen
Germany
phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory)
fax: +49-7071-295518
e-mail: ber...@un...
Internet: http://www.uni-tuebingen.de/speiser
=======================================================================
--
===================================================================
Bernd Speiser
Institut f"ur Organische Chemie
Auf der Morgenstelle 18
D-72076 T"ubingen
Germany
phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory)
fax: +49-7071-295518
e-mail: ber...@un...
Internet: http://www.uni-tuebingen.de/speiser
===================================================================
|
|
From: Kai L. <kai...@un...> - 2004-12-14 16:35:29
|
Hi All, Alain needs a method that removes the last segment from the excitation function. I've just implemented a "pop_back()" method in the DIExcitationFunction template and committed it to cvs. Check it out :) Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Kai L. <kai...@un...> - 2004-11-29 11:41:57
|
Hi All, due to Alain's suggestion, I've added a new function to the ExcitationFunction interface. // returns index of segment within exciation function size_t segment_index(const I &iValue) const available from cvs. Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Kai L. <kai...@un...> - 2004-11-08 13:02:16
|
hi all, this weekend I've made some changes to the exciation function package: - new method in excitation function to obtain the function's derivative. - added EPP_DEBUG macro to value/derivative methods of segments: should increase performance - changed file names acccording to our EChem++ convention (mixed case file names starting with lower case letter, suffixes *.hpp or *.cpp) a top level 'checkout' should bring you upto date. Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: 07071/29-73049 Mail: kai...@un... |
|
From: Bernd S. <ber...@un...> - 2004-11-08 11:42:55
|
Kai Ludwig wrote: > Well, it's just an arbitrary name definition - maybe the name 'MACRO' > is misleading here. We could pass the -DEPP_DEBUG directive to g++ > if --enable-eppdebug is specified. Yes, this should be done. bernd -- =================================================================== Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =================================================================== |
|
From: Kai L. <kai...@un...> - 2004-11-08 10:50:19
|
> Kai Ludwig wrote: > > Kai, > >> I propose the use of the EPP_DEBUG macro that can be set >> to g++ by configure options (e.g. --enable-eppdebug). >> With this Macro, it is possible to switch on/off >> possibly slow run time error checking - e.g. checking >> for right sizes of vectors etc. > > is this a generally available macro, or has it been designed by > you for EChem++ use only? Well, it's just an arbitrary name definition - maybe the name 'MACRO' is misleading here. We could pass the -DEPP_DEBUG directive to g++ if --enable-eppdebug is specified. Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: 07071/29-73049 Mail: kai...@un... |
|
From: <ber...@t-...> - 2004-11-08 07:10:49
|
Kai Ludwig wrote: Kai, > I propose the use of the EPP_DEBUG macro that can be set > to g++ by configure options (e.g. --enable-eppdebug). > With this Macro, it is possible to switch on/off > possibly slow run time error checking - e.g. checking > for right sizes of vectors etc. is this a generally available macro, or has it been designed by you for EChem++ use only? If the latter: is it included in the cvs code? Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Kai L. <kai...@un...> - 2004-11-04 10:11:45
|
Hi All,
A note to time critical calculation and run time error handling:
I propose the use of the EPP_DEBUG macro that can be set
to g++ by configure options (e.g. --enable-eppdebug).
With this Macro, it is possible to switch on/off
possibly slow run time error checking - e.g. checking
for right sizes of vectors etc.
In your code, use e.g.
#ifdef EPP_DEBUG
if( vector.size() =3D=3D 0 )
{
throw error(...);
}
#endif
Regards,
Kai
--=20
http://echempp.sourceforge.net
Kai Ludwig
Institut f=FCr Organische Chemie
Auf der Morgenstelle 18
72076 T=FCbingen
Tel.: 07071/29-73049
Mail: kai...@un...
|
|
From: Kai L. <kai...@un...> - 2004-10-21 07:32:17
|
Hi All, next month EChem++ will be 2 years old. Here are some funny facts I generated with the sloccount program: SLOC Directory SLOC-by-Language (Sorted) 18217 Model cpp=3D18214,sh=3D3 15725 GUI cpp=3D15725 8310 top_dir sh=3D8310 1545 Experiment cpp=3D1542,sh=3D3 537 Utilities cpp=3D537 130 EChem++ cpp=3D130 0 autom4te.cache (none) 0 CVS (none) 0 CVSROOT (none) 0 documentation (none) 0 HardwareControl (none) Totals grouped by language (dominant language first): cpp: 36148 (81.30%) sh: 8316 (18.70%) Total Physical Source Lines of Code (SLOC) =3D 44,464 Development Effort Estimate, Person-Years (Person-Months) =3D 10.75 (129.= 01) (Basic COCOMO model, Person-Months =3D 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) =3D 1.32 (15.85= ) (Basic COCOMO model, Months =3D 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) =3D 8.14 Total Estimated Cost to Develop =3D $ 1,452,281 (average salary =3D $56,286/year, overhead =3D 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU G= PL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL lice= nse; see the documentation for details. Please credit this data as "generated using David A. Wheeler's 'SLOCCount= '." Happy Birthday :) Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: 07071/29-73049 Mail: kai...@un... |
|
From: Kai L. <kai...@un...> - 2004-10-14 13:28:25
|
Hi, I just changed all relevant Makefile.am-files and commited them to the cvs-server. So remove your old EChem++ libs from your local (cvs)-installation directory and make a cvs update from the top level. Kai > >> Kai Ludwig wrote: >>> Hi all, >>> >>> in my opinion it would be necessary to >>> add a prefix (e.g. epp) to our EChem++ >>> library names, say libeppExperiment >>> instead of libExperiment. >>> >>> This will avoid name confusions if some >>> other software installed on a system uses >>> the same name >>> (maybe this is not often the case for >>> libExperiments, but we also have libraries >>> like Solvers, Numerics, Visualization etc.) >>> >>> what do you mean? >>> Kai >>> >> >> I agree. This will cause some editing of the automake facilities, but >> we will have less trouble as you describe. >> Can you start the tranformation process? > > all right - I'll post a message as soon as I finished. > (maybe during the weekend) > > Kai > > -- > http://echempp.sourceforge.net > > Kai Ludwig > Institut f=FCr Organische Chemie > Auf der Morgenstelle 18 > 72076 T=FCbingen > Tel.: 07071/29-73049 > Mail: kai...@un... > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on > ITManagersJournal Use IT products in your business? Tell us what you > think of them. Give us Your Opinions, Get Free ThinkGeek Gift > Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Echempp-devel mailing list > Ech...@li... > https://lists.sourceforge.net/lists/listinfo/echempp-devel --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: 07071/29-73049 Mail: kai...@un... |
|
From: Kai L. <kai...@un...> - 2004-10-14 12:09:00
|
> Kai Ludwig wrote: >> Hi all, >> >> in my opinion it would be necessary to >> add a prefix (e.g. epp) to our EChem++ >> library names, say libeppExperiment >> instead of libExperiment. >> >> This will avoid name confusions if some >> other software installed on a system uses >> the same name >> (maybe this is not often the case for >> libExperiments, but we also have libraries >> like Solvers, Numerics, Visualization etc.) >> >> what do you mean? >> Kai >> > > I agree. This will cause some editing of the automake facilities, but > we will have less trouble as you describe. > Can you start the tranformation process? all right - I'll post a message as soon as I finished. (maybe during the weekend) Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: 07071/29-73049 Mail: kai...@un... |
