November 2005 - GiNaC-devel

tinfo
by Jens Vollinga 30 Nov '05

30 Nov '05

Hi everybody, just an idea for a better(?) tinfo mechanism in ginac: if we added two static constants to every class like class SOMECLASS { public: const static char* tinfo_name; const static unsigned tinfo; // ... rest of class ... } const char* SOMECLASS::tinfo_name = "SOMECLASS"; const unsigned SOMECLASS::tinfo = (unsigned)SOMECLASS::idstring; it seems that we would get a tinfo mechanism for ginac without having to set the tinfo numbers by hand. But maybe I am mistaken. So I'd like to ask somebody who knows C++ better than me, if there might be some hidden pitfalls. Is the conversion a problem (what about 64bit machines)? Is it guaranteed that the address of the static string is unique to every class? Maybe some optimizer will break this? Does it only work with gcc on linux etc.? Regards, Jens

3 12

new function system
by Jens Vollinga 29 Nov '05

29 Nov '05

Hi, here now a small code example to make clear what I was taking about when I mentioned class-functions. A log10 function is declared as an example. The fclass (-> function) class basically installs some default printing and has some convenience ctors. I know there are some issues about the macros (fixed archiving defaults, naming, ...), some print stuff is missing in fclass, and there is no special code for log10 (series, ...) yet, but the main concept should become clear. Eval: - compatibility is severly broken (but maybe we should break it anyhow: why not rename tgamma to Gamma, beta to Beta, lgamma to logGamma?) + logic like if (is_a<function>(e)) { std::string name = ex_to<function>(e).get_name(); if (name == "H") { ... can be replaced by more efficient code + hierarchies like polylog->nielsen_polylog->multiple_polylog possible + function.pl is no longer needed + eval/evalf slightly faster (?) + non-ex arguments for ctors (and eval, ...) possible + extra methods/logic/data can be included in the function class (projects like nestedsums, xloops suffer from not being able to do this at the moment) + more OOP like (disputable, but we will never hear the often raised question 'why didn't you just define the functions as classes?' again + better (OOP-like) handling of look-up tables (as static data or maybe the function might become a singleton) - no nice separation of cln and GiNaC code possible + print-Methods can also be changed at runtime for functions - archiving slightly slower because of longer reg_info list Regards, Jens #include <iostream> #include <fstream> #include <stdexcept> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; namespace GiNaC { /** Primary macro for inclusion in the declaration of each registered class. */ #define NEW_GINAC_DECLARE_REGISTERED_CLASS_NO_CTORS(classname, supername) \ public: \ typedef supername inherited; \ private: \ static GiNaC::registered_class_info reg_info; \ public: \ static GiNaC::registered_class_info &get_class_info_static() { return reg_info; } \ virtual const GiNaC::registered_class_info &get_class_info() const { return classname::get_class_info_static(); } \ virtual GiNaC::registered_class_info &get_class_info() { return classname::get_class_info_static(); } \ virtual const char *class_name() const { return classname::get_class_info_static().options.get_name(); } \ \ classname(const GiNaC::archive_node &n, GiNaC::lst &sym_lst) : inherited(n, sym_lst) {} ; \ static GiNaC::ex unarchive(const GiNaC::archive_node &n, GiNaC::lst &sym_lst) \ { return (new classname(n, sym_lst))->setflag(status_flags::dynallocated); }; \ class visitor { \ public: \ virtual void visit(const classname &) = 0; \ virtual ~visitor() {}; \ }; \ private: /** Macro for inclusion in the declaration of each registered class. * It declares some functions that are common to all classes derived * from 'basic' as well as all required stuff for the GiNaC class * registry (mainly needed for archiving). */ #define NEW_GINAC_DECLARE_REGISTERED_CLASS(classname, supername) \ NEW_GINAC_DECLARE_REGISTERED_CLASS_NO_CTORS(classname, supername) \ public: \ classname() { tinfo_key = TINFO_##classname; } \ virtual classname * duplicate() const { return new classname(*this); } \ \ virtual void accept(GiNaC::visitor & v) const \ { \ if (visitor *p = dynamic_cast<visitor *>(&v)) \ p->visit(*this); \ else \ inherited::accept(v); \ } \ private: //////////////////////////////////////////////////////////////////////////////// const unsigned TINFO_fclass = 0x47231232U; class fclass : public exprseq { NEW_GINAC_DECLARE_REGISTERED_CLASS(fclass, exprseq) public: fclass(unsigned ti, const ex& x1) : inherited(x1) { tinfo_key = ti; } fclass(unsigned ti, const ex& x1, const ex& x2) : inherited(x1,x2) { tinfo_key = ti; } fclass(unsigned ti, const ex& x1, const ex& x2, const ex& x3) : inherited(x1,x2,x3) { tinfo_key = ti; } protected: void fclass::do_print(const print_context &c, unsigned level) const { c.s << class_name(); inherited::do_print(c,level); } }; GINAC_IMPLEMENT_REGISTERED_CLASS_OPT(fclass, exprseq, print_func<print_context>(&fclass::do_print)) //////////////////////////////////////////////////////////////////////////////// const unsigned TINFO_log10 = 0x47321232U; class log10 : public fclass { NEW_GINAC_DECLARE_REGISTERED_CLASS(log10, fclass) public: log10(const ex& x) : inherited(TINFO_log10, x) {} log10(const ex& x, const ex& y) : inherited(TINFO_log10, x, y) {} }; GINAC_IMPLEMENT_REGISTERED_CLASS(log10, fclass) //////////////////////////////////////////////////////////////////////////////// } main() { try { symbol x("x"); ex d = x; ex r1 = log10(d) * log10(x) + x; cout << r1 << endl; cout << tree << r1 << endl; cout << dflt << log10(lst(x,x),lst(x)) << endl; } catch (const exception& e) { cout << e.what() << endl; } return 0; }

2 5

CLN 1.1.11 released
by Richard B. Kreckel 22 Nov '05

22 Nov '05

Good evening, This is to announce the availability of CLN 1.1.11. It's a maintenance release with only one change: All input of numbers is now much speedier (except when the base is a power of two, in which case the performance was already optimal). As always, it is available from <http://www.ginac.de/CLN/>. Enjoy! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

new tinfos
by Jens Vollinga 22 Nov '05

22 Nov '05

Hi, I want to share some findungs about the new tinfo mechanism I proposed lately: In principle, it works! The return_type_tinfo() methods have to be changed a little bit, because the bit pattern arithmetics done for clifford and color classes (there, tinfo is combined with the representation label) are no longer possible. The quick and dirty fix I made for that should cause a slight performance loss, but I was not able to measure one, yet. In practice, there is a problem: Two checks fail. One check is the normalization check: e = (pow(x, 2) - pow(y, 2)) / pow(x-y, 3); d = (x + y) / pow(x - y, 2); result += check_normal(e, d); Since now the tinfos do change from compilation to compilation, also the hash values do change. So the canonical ordering can be different and normal seems to be very dependent on that ordering. In 50% of the cases the check fails, because the normalization returns (x+y) * pow(-x+y,-2), which is correct but doesn't compare well. The second check that fails is from the clifford checks: e = dirac_gamma(mu, 0) * dirac_gamma(mu.toggle_variance(), 1) * dirac_gamma(nu, 0) * dirac_gamma(nu.toggle_variance(), 1); result += check_equal_simplify(dirac_trace(e, 2), canonicalize_clifford(e)); // e will be canonicalized by the calculation of the trace Here sometimes (like every third invocation) canonicalize_clifford(e) returns a wrong result: (dirac_gamma.nu*dirac_gamma.mu)*(dirac_gamma^nu*dirac_gamma^mu) The mu and nu are swapped! I don't know how to interpret these failures. Is the new tinfo mechanism doomed? Is there a bug in canonicalize_clifford and the normalization check is flawed? The reason to think about a new tinfo mechnism for me is the idea to get rid of the current function class and replace it by a every-ginac-function-is-class way of doing it. Regards, Jens

2 6

Patch for products of dummy summations
by Vladimir Kisil 17 Nov '05

17 Nov '05

>>>>> "RK" == Richard B Kreckel <kreckel(a)ginac.de> writes: RK> deteriorated recently. Indeed, times like Lewis-Wester O1 have RK> dropped by about 50%. I'm pretty sure this happend with your RK> patch. RK> Is there a way to speed this up again? I propose a patch which restore much of the previous speed and still passing through all standard checks. I also correct some errors in exam_clifford.cpp. Best wishes, Vladimir -- Vladimir Kisil email: kisilv(a)amsta.leeds.ac.uk www: http://amsta.leeds.ac.uk/~kisilv

2 3

ginac homepage
by Jens Vollinga 16 Nov '05

16 Nov '05

Hi everybody, an idea concerning the ginac homepage: rename the "ToDo List" to something like "Roadmap" and put some more information above the existing text. The new information could be some more or less detailed list of topics certain people are working on. List of things that will be implemented for the next release, etc. The text is supposed to be rather static, so no daily updates intented, and will be refreshed just in case some major changes are imminent. Apart from being more informative to the public, this might also serve as a means to co-ordinate the work of different developers. Is this idea viable? Regards, Jens

3 7

Patch for products of dummy summations
by Vladimir Kisil 12 Nov '05

12 Nov '05

Here is the patch which was described in my previous message (Fri May 13 17:27:25 CEST 2005). -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 1

Patches are in CVS.
by Chris Dams 11 Nov '05

11 Nov '05

Dear all, The patches that I have been submitting on this list lately are now in CVS. Enjoy! Chris

1 0

patch for numeric.cpp
by Chris Dams 10 Nov '05

10 Nov '05

Dear developpers, I found out that 1.has(0) returns true. Iteresting ;-o. A patch is attached. This made me wonder about 2.has(2*I). It returns true. Is this really the idea? Best, Chris

3 2

Re: Function & Power patch
by Vladimir Kisil 09 Nov '05

09 Nov '05

Dear All, I wish to remind on a proposed patch submitted on Mon Sep 26 23:32:43 CEST 2005, to ensure that it is not lost. Best wishes, -- Vladimir Kisil email: kisilv(a)amsta.leeds.ac.uk www: http://amsta.leeds.ac.uk/~kisilv

2 1