17 Feb * some cleanup thanks to Vic Bancroft * got rid of the 'using namespace std' * replaced own implementation of scalar product with STL inner_product * replace 'template' syntax with 'template' because thats more ANSI * add char* and string specialisations to something2string() and string2<>() 03 Feb 2003 * further testing of cooollist, cooolvec and DensMatrix * work on writedebug and writewarn. The interface is quite ugly, though. 1.) What I would like a) knows all the string-conversions from the operator<< that are defined all over the place i.e. writedebug << cooolvec<> b) can take diverse objects in one call i.e. writedebug << "char*" << integer << endl c) line oriented: can do things like prefix each output line with "warning: " or don't have to put line-endings on lines since the class takes care of it 2.) What I know to do * define my own streambuf class and have writedebug be an std::ostream(streambuf&) This gives me a) b) but not c) at all * define my own class logger with templateoperator<< which relays it to an ostringstream for conversion to a string. Unfortunately, this does not give me a) for fancy objects like "endl" and it does not give me c) Possible Solution: don't see any. Some two-tired approach might work: something like writedebug << "char*" << integer << cooolvec << process; where "process" is a special object. Maybe "endl" could be overloaded? 02 Feb 2003 * fix cooolvec::safe_resize(), DensMatrix::safe_resize(), DensMatrix::operator*(cooolvec), cooolvec::awrite() and other methods. * Removed Matrix::operator() which was unnecessary and confusing. Replaced operator()(char*,size_t) with rowSum(size_t) operator()(size_t,char*) with colSum(size_t) * cooolvec and DensMatrix seem to work now. t.cooolmatrix.cc and t.cooolvec.cc have been extended to test more functionality. 18 Oct 2002 * upgraded toolchain to gcc 3.2/ Redhat 8.0 and adjusted Makefile.config. Also changed README.install. Thats all. 01 Oct 2002 * added a -DDEBUG symbol to the C++ FLAGS if in debug mode * if in debug mode, cooolvec does range checking on [] via a at() function (just like vector) * added a clear() function for cooolvec. right now thats the same as resize(0) * changed all occurences of resize(0) to clear() for both cooolvec and cooollist * forbid resize() for lists since that means we have a design problem * took out local version of min() and max() since ANSI C++ provides it 30 Sept 2002 * resolved the resize() issue: resize() is not allowed anymore. Instead use only safe_resize() or unsafe_resize() 29 Sept 2002 * updated the cooolvec, cooollist, writedebug, cooolexception classes * started a "test" directory with cooolvec, cooollist test programs FIRST TIME COOOL PROGRAMS COMPILE AND RUN WITHOUT CRASHING * replaced char* className, optName, objName, matrixType with string * collected all numeric literals (constants) found throughout the library and put them in config.hh. Unfortunately I don't know what most of them do... * experimented: for constructors, instead of having (int a,int b) where a and b mean what???? create nano-classes "length" and "elem" for better typechecking. So we have something like cooolvec v(length(10),elem(-1)); This basically emulates named parameters. If length and elem are inlined its still fast enough. However, it is very difficult to implement: * if done strict enough that not using this convention is a syntax error it is so intrusive that its not feasable. Too many type conversions (like length -> size_t and size_t -> length) must be written. The mechanics of a technique that should be automatic overwhelm any usage * if implemented very permissible, for instance by providing automatic type conversion operators, it does not provide much help, i.e. it does not force strong typing on the user In the end, the experiment was abandoned. Remaining are the cooollength and cooolelem classes but they are not used anywhere. I might go back to it using only the elem() classes. The syntax would be something like cooolvec v(10,elem(-1)); * started to deal with the problem that we are using different notion of how vector.resize() works: does it preserve its contents or not? Right now cooolvec knows a resize() which is "safe" (i.e. it preserves) and an unsafe_resize() which does not, just like the original valarray does. 23 Sep 2002 * included (outdated) docs in distribution 3 Sep 2002 * added Thomas Landauer's fixes (see his mail from 31 July) 14 Jul 2002 * updated README.install: make it clear that this is not usable software and only "tested" on RH Linux 7.3/GCC 3.1 * link README.install from the homepage 12 Jul 2002 * upgraded devel toolchain to gcc 3.1, which is much better than 3.0 * fix compiling and upgrade README.install 11 April 2002 * all include files are now in coool/*.hh for better namespace separation * took out Forward::isValid() and the magic_tag constant 10 April 2002 * removed all occurences of the isVerbose variable, replace with writedebug framework. 9 April 2002 * fixed a memory leak in LineSearch::gradient: it would allocate a cooolvec*, only to re-assign the pointer to something else immediatly. Pointers are dangerous..... Beware of pointers. * forbid operator*(vector a,vector b) because of confusion what it should mean: * STL thinks its a vector c with c[i]=a[i]*b[i] * algebra thinks its the sum s=sum(a[i]*b[i]) the replacements are s=scalar_prod(a,b) (algebra) and c=long_prod(a,b) (STL) * forbid: vec = vec * mat (??? what the hell? vec * mat should be a matrix) no replacement needed at this time because it should be the same as vec = mat * vec, according to the implementation found in DensMatrix.cc 8 April 2002 * make Model Model::update(Type alpha, Type beta, const cooolvec& dmod) change the object its called on. Model::updated() does not change but returns a new, updated model. This is equivalent to the Vector/List::normalize() and ::normalized() methods. * rename DensMatrix::addVal() to append_xxx() which makes it a hell of a lot easier to understand * rename delVal() to erase() * use exceptions instead of cerr<< and exit()and inValidSize() -> cooolexception.hh * use a proper debug module instead of isVerbose and cerr -> writedebugh.hh * more conversions of pointers to proper objects -> much less usage of new() and delete() 5 April 2002 * finished introduction of cooolvec<> and cooollist<> classes and conversion of pointers in *Matrix and Model to cooolvec 4 April 2002 * made classes cooolvec and cooollist as children of valarray and list put MTL plans on ice for now because it is not clean ANSI C++ * changed interface: * normalize() _always_ normalizes the object its called on calls to normalize() need to change throughout the code! * in *Matrix* classes as well as the Model class, replace all pointers with cooolvec objects. No "new" and "delete" anymore. In the DensMatrix class for instance, replaced "vector*" with cooolvec> 3 April 2002 * extremely ugly workaround a double->long cast in template template Model::Model(const Model& initmod) This needs to be fixed! Optima::optimizer() should be type agnostic But at least now it compiles without any warnings under -ansi -pedantic -Wall -W * make coool@coool.mines.edu (nee optima@coool.mines.edu) a mailman managed mailinglist 2 April 2002 * automatic dependencies in build process 1 April 2002 * get it to compile with '-pedantic -ansi -Wall -W' except for a double -> long assignment * COOOL is now lots slower and not optimized at all, but much clearer * new very lightweight buildprocess * start of a devel webpage 31 March 2002 * use STL to replace classes * AString with string * List with list * Vector with vector January 2002 * go through defs.h to look for redundancies with STL 2001 * change email adresses in install (mailhome.sh) from hldeng to coool-maintainer