From vollinga at physik.uni-wuppertal.de Tue Nov 8 17:15:17 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 08 Nov 2005 17:15:17 +0100 Subject: [GiNaC-devel] more patch In-Reply-To: References: Message-ID: <4370CF15.2010800@physik.uni-wuppertal.de> Hi Chris, Chris Dams wrote: > Actually, I am not really entirely certain if this subs_option is the > right way to go. On the one hand, the fact that constructing powers of > I would appreciate some input on this issue. is the new subs_option only to conserve compability with unknown user programs (sorry, I didn't dig into the patch code yet) ? > expressions with summed indices automatically yields renamed results, > suggest that we really want to consider index renaming as something that > happens automatically without the user having to know anything about it. Yes. > On the other hand, this may break existing code that wants to rename dummy > indices. The problem is probably quite rare, though. One needs something I don't know of any existing code that would break. Anyhow, I would vote for breaking compatability in this case. Regards, Jens From Chris.Dams at mi.infn.it Tue Nov 8 18:27:24 2005 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Tue, 8 Nov 2005 18:27:24 +0100 (CET) Subject: [GiNaC-devel] more patch In-Reply-To: <4370CF15.2010800@physik.uni-wuppertal.de> Message-ID: Dear Jens, On Tue, 8 Nov 2005, Jens Vollinga wrote: > Chris Dams wrote: > > Actually, I am not really entirely certain if this subs_option is the > > right way to go. On the one hand, the fact that constructing powers of > > > I would appreciate some input on this issue. > > is the new subs_option only to conserve compability with unknown user > programs (sorry, I didn't dig into the patch code yet) ? Also with GiNaCs own symmetrization over dummy indices (as done by simplify_indexed). Clearly it is wrong to rename the dummy indices in this case. Best, Chris From kisilv at maths.leeds.ac.uk Wed Nov 9 11:51:00 2005 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Wed, 9 Nov 2005 10:51:00 +0000 (GMT) Subject: [GiNaC-devel] Re: Function & Power patch Message-ID: 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 at amsta.leeds.ac.uk www: http://amsta.leeds.ac.uk/~kisilv From vollinga at physik.uni-wuppertal.de Wed Nov 9 14:49:50 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 09 Nov 2005 14:49:50 +0100 Subject: [GiNaC-devel] Re: Function & Power patch In-Reply-To: References: Message-ID: <4371FE7E.60803@physik.uni-wuppertal.de> Dear Vladimir, Vladimir Kisil wrote: > 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. thanks for reminding ... your patch has now been applied. Regards, Jens From Chris.Dams at mi.infn.it Wed Nov 9 15:53:31 2005 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 9 Nov 2005 15:53:31 +0100 (CET) Subject: [GiNaC-devel] patch for numeric.cpp Message-ID: 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 -------------- next part -------------- Index: numeric.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/numeric.cpp,v retrieving revision 1.114 diff -u -r1.114 numeric.cpp --- numeric.cpp 29 Jun 2005 14:09:24 -0000 1.114 +++ numeric.cpp 9 Nov 2005 14:46:29 -0000 @@ -631,9 +631,15 @@ const numeric &o = ex_to(other); if (this->is_equal(o) || this->is_equal(-o)) return true; - if (o.imag().is_zero()) // e.g. scan for 3 in -3*I - return (this->real().is_equal(o) || this->imag().is_equal(o) || - this->real().is_equal(-o) || this->imag().is_equal(-o)); + if (o.imag().is_zero()) { // e.g. scan for 3 in -3*I + if(!this->real().is_equal(*_num0_p)) + if(this->real().is_equal(o) || this->real().is_equal(-o)) + return true; + if(!this->imag().is_equal(*_num0_p)) + if(this->imag().is_equal(o) || this->imag().is_equal(-o)) + return true; + return false; + } else { if (o.is_equal(I)) // e.g scan for I in 42*I return !this->is_real(); From vollinga at physik.uni-wuppertal.de Wed Nov 9 16:46:51 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 09 Nov 2005 16:46:51 +0100 Subject: [GiNaC-devel] patch for numeric.cpp In-Reply-To: References: Message-ID: <437219EB.2090201@physik.uni-wuppertal.de> Hi Chris, Chris Dams wrote: > 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? I am not sure, but I don't think so. I modified your patch slighty to cover that case too (and put it into CVS). Regards, Jens From vollinga at physik.uni-wuppertal.de Thu Nov 10 15:47:34 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Thu, 10 Nov 2005 15:47:34 +0100 Subject: [GiNaC-devel] tinfo Message-ID: <43735D86.4020809@physik.uni-wuppertal.de> 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 From vollinga at physik.uni-wuppertal.de Thu Nov 10 16:08:06 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Thu, 10 Nov 2005 16:08:06 +0100 Subject: [GiNaC-devel] ginac homepage Message-ID: <43736256.5010908@physik.uni-wuppertal.de> 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 From Chris.Dams at mi.infn.it Thu Nov 10 16:45:32 2005 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Thu, 10 Nov 2005 16:45:32 +0100 (CET) Subject: [GiNaC-devel] tinfo In-Reply-To: <43735D86.4020809@physik.uni-wuppertal.de> Message-ID: Dear Jens, On Thu, 10 Nov 2005, Jens Vollinga wrote: > 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. Sounds like something that could work. You could try it. But please run "make check" before you put it in CVS ;-). > Is the conversion a problem (what about 64bit machines)? One should of course use the right type and on AMD 64 that would not be unsigned int because it is 32 bits, while pointers are 64 bits. Is there anything wrong with the SOMECLASS::tinfo being of type char*? That way you would need only one variable that you could typedef to something more descriptive (e.g. tinfo_t). Best, Chris From Chris.Dams at mi.infn.it Thu Nov 10 16:50:50 2005 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Thu, 10 Nov 2005 16:50:50 +0100 (CET) Subject: [GiNaC-devel] tinfo In-Reply-To: <43735D86.4020809@physik.uni-wuppertal.de> Message-ID: Dear Jens, On Thu, 10 Nov 2005, Jens Vollinga wrote: > 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; On second thought, is it not a problem that these members are non-virtual in the sense that SOMECLASS x; basic*bp = &x; cout << bp->tinfo_name << endl; is always going to print "basic"? Best, Chris From vollinga at physik.uni-wuppertal.de Thu Nov 10 17:01:22 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Thu, 10 Nov 2005 17:01:22 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: References: Message-ID: <43736ED2.6090005@physik.uni-wuppertal.de> Dear Chris, Chris Dams wrote: > On second thought, is it not a problem that these members are non-virtual > in the sense that > > SOMECLASS x; > basic*bp = &x; > cout << bp->tinfo_name << endl; > > is always going to print "basic"? yes, arrrgh, stupid me! Thanks, Jens From vollinga at physik.uni-wuppertal.de Thu Nov 10 17:09:23 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Thu, 10 Nov 2005 17:09:23 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: References: Message-ID: <437370B3.8010200@physik.uni-wuppertal.de> Dear Chris, maybe I am obsessed ... but what about the following variant (I had this version first but then decided to put a more *polished* version on the list...): class SOMECLASS { public: const static char* tinfo_name; const static unsigned tinfo; virtual const unsigned int id() { return (unsigned int)SOMECLASS::tinfo_name; } }; const char* SOMECLASS::tinfo_name = "SOMECLASS"; const unsigned SOMECLASS::tinfo = (unsigned)SOMECLASS::tinfo_name; Well, the unsigned tinfo variable is maybe not necessary. And if tinfo() in every ginac class would return char* no casting would be necessary from the start. Regards, Jens From vollinga at physik.uni-wuppertal.de Thu Nov 10 17:15:20 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Thu, 10 Nov 2005 17:15:20 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: <437370B3.8010200@physik.uni-wuppertal.de> References: <437370B3.8010200@physik.uni-wuppertal.de> Message-ID: <43737218.8050800@physik.uni-wuppertal.de> Hi, sorry for flooding the list... > virtual const unsigned int id() was meant to be > virtual const unsigned int tinfo() Now, I recognize a first disadvantage of this mechanism: it is slower than just comparing member variables ... Regards, Jens From cb at cebix.net Thu Nov 10 18:11:54 2005 From: cb at cebix.net (Christian Bauer) Date: Thu, 10 Nov 2005 18:11:54 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: <43737218.8050800@physik.uni-wuppertal.de> References: <437370B3.8010200@physik.uni-wuppertal.de> <43737218.8050800@physik.uni-wuppertal.de> Message-ID: <43737F5A.8010003@cebix.net> Hi! 1) You can't have virtual static members. 2) The main reason behind the TINFO mechanism was to avoid a virtual function call. This and some other optimizations sped up GiNaC by a factor of two. 3) If you're planning to re-introduce virtual functions to GiNaC's RTTI, you might as well use typeid() (maybe it works better now than it did five years ago). 4) structure implements a dynamic TINFO assignment, if you want to look at one. Bye, Christian -- / Physics is an algorithm \/ www.cebix.net From kreckel at ginac.de Thu Nov 10 23:02:31 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Thu, 10 Nov 2005 23:02:31 +0100 Subject: [GiNaC-devel] patch for numeric.cpp In-Reply-To: <437219EB.2090201@physik.uni-wuppertal.de> References: <437219EB.2090201@physik.uni-wuppertal.de> Message-ID: <4373C377.2070405@ginac.de> Jens Vollinga wrote: > Chris Dams wrote: > >> 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? > > > I am not sure, but I don't think so. Definitely not. > I modified your patch slighty to cover that case too (and put it into > CVS). That patch appears to meet up with the comment whereas the original code didn't. ;-) Great! -richy. -- Richard B. Kreckel From kreckel at ginac.de Thu Nov 10 23:48:27 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Thu, 10 Nov 2005 23:48:27 +0100 Subject: [GiNaC-devel] ginac homepage In-Reply-To: <43736256.5010908@physik.uni-wuppertal.de> References: <43736256.5010908@physik.uni-wuppertal.de> Message-ID: <4373CE3B.8030208@ginac.de> Jens Vollinga wrote: > 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. Why not? I could, for instance, explain what the difficulties were with Sasaki-Murao for somebody interested to pick up the work. Or, implementation ideas could be layed out. Wait! This sounds more and more like a Wiki, doesn't it? Or maybe this is going too far. What do other people think? -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Fri Nov 11 12:00:39 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Fri, 11 Nov 2005 12:00:39 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: <43737F5A.8010003@cebix.net> References: <437370B3.8010200@physik.uni-wuppertal.de> <43737218.8050800@physik.uni-wuppertal.de> <43737F5A.8010003@cebix.net> Message-ID: <437479D7.7010706@physik.uni-wuppertal.de> Hi, Christian Bauer wrote: > 2) The main reason behind the TINFO mechanism was to avoid a virtual > function call. This and some other optimizations sped up GiNaC by a > factor of two. That's interesting information! Then of course, the proposed mechanism is no longer acceptable. But, "Never give up, never surrender" (Galaxy Quest), what about the folling code. There is no such overhead involved: class SOMECLASS { public: const static char* tinfo_name; unsigned tinfo; SOMECLASS() { tinfo = (unsigned)tinfo_name; } }; const char* SOMECLASS::tinfo_name= "SOMECLASS"; class daughter : public SOMECLASS { public: const static char* tinfo_name; daughter() { tinfo = (unsigned)tinfo_name; } }; const char* daughter::tinfo_name= "daughter"; Regards, Jens From Chris.Dams at mi.infn.it Fri Nov 11 12:15:54 2005 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Fri, 11 Nov 2005 12:15:54 +0100 (CET) Subject: [GiNaC-devel] ginac homepage In-Reply-To: <4373CE3B.8030208@ginac.de> Message-ID: Dear all, On Thu, 10 Nov 2005, Richard B. Kreckel wrote: > Why not? I could, for instance, explain what the difficulties were with > Sasaki-Murao for somebody interested to pick up the work. Or, > implementation ideas could be layed out. > > Wait! This sounds more and more like a Wiki, doesn't it? Or maybe this > is going too far. What do other people think? A Wiki could certainly be interesting as it could be a very low-threshold way of discussing things. I sometimes come at http://senseis.xmp.net and the nice thing is that there are both sections that contain reference material and section where free discussion is going on. I certainly think that some ideas that now only exist in my head would be more readily discussed on a wiki than on the mailing list. Besides that, nobody is likely to look at mailing list discussions anymore if they are a bit old. It could be sort of like the coffee-machine discussions that would occur if the GiNaC community was not scattered all over the world. On the other hand, it could well be that the GiNaC community is a bit small to support a Wiki. I don't know. Best, Chris From Chris.Dams at mi.infn.it Fri Nov 11 13:33:47 2005 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Fri, 11 Nov 2005 13:33:47 +0100 (CET) Subject: [GiNaC-devel] Patches are in CVS. Message-ID: Dear all, The patches that I have been submitting on this list lately are now in CVS. Enjoy! Chris From kreckel at ginac.de Sat Nov 12 00:58:32 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Sat, 12 Nov 2005 00:58:32 +0100 Subject: [GiNaC-devel] Patch for products of dummy summations In-Reply-To: References: Message-ID: <43753028.3090904@ginac.de> Vladimir, On 2005-05-13, you wrote: > Here is the patch which was described in my previous message > (Fri May 13 17:27:25 CEST 2005). > > Several days ago, Christian found out that the speed of computation of our symbolic determinants seems to have deteriorated recently. Indeed, times like Lewis-Wester O1 have dropped by about 50%. I'm pretty sure this happend with your patch. In particular, the two calls to rename_dummy_indices_uniquely from within mul::expand appear to be quite expensive. By defining GINAC_COMPARE_STATISTICS in basic.h I found that it increases the number of calls to ex::is_equal by about an order of magnitude. Is there a way to speed this up again? Regards -richy. -- Richard B. Kreckel From kreckel at ginac.de Sat Nov 12 01:22:05 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Sat, 12 Nov 2005 01:22:05 +0100 Subject: [GiNaC-devel] ginac homepage In-Reply-To: References: Message-ID: <437535AD.3030005@ginac.de> Chris Dams wrote: >On the other hand, it could well be that the GiNaC community is a bit >small to support a Wiki. I don't know. > > True. But it just occurs to me: we could also wikfiy the FAQ which would bump a Wiki well above 10 or so pages! :) Regards -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Mon Nov 14 10:59:14 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Mon, 14 Nov 2005 10:59:14 +0100 Subject: [GiNaC-devel] ginac homepage In-Reply-To: References: Message-ID: <43785FF2.40707@physik.uni-wuppertal.de> Hello everybody, I am bit skeptical about using a full-blown wiki for a "small" project like ginac. I really prefer having discussions on a mailing list rather than in a forum, because I like the fact, that you have an instant notification about responses. All the information that could be collected on the web site, like FAQ, release plans, on-going development, open problems, design issues, developers manual/guide, knowledge base, etc. ..., could in principle be put there in the old-fashioned way by editing HTML. On the other hand, a really small content management system (Wiki?) could be nice way to put the aforementioned topics on-line in a well structured way. So, with no forum and no excessive interface it would be okay with me. Do such systems exist? Regards, Jens From kreckel at ginac.de Tue Nov 15 21:22:17 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Tue, 15 Nov 2005 21:22:17 +0100 Subject: [GiNaC-devel] ginac homepage In-Reply-To: <43785FF2.40707@physik.uni-wuppertal.de> References: <43785FF2.40707@physik.uni-wuppertal.de> Message-ID: <437A4379.8010309@ginac.de> Hi! Jens Vollinga wrote: > I am bit skeptical about using a full-blown wiki for a "small" project > like ginac. > > I really prefer having discussions on a mailing list rather than in a > forum, because I like the fact, that you have an instant notification > about responses. There are RSS or Atom feeds for that purpose, though I admit that I have no experience with such media. > All the information that could be collected on the web site, like FAQ, > release plans, on-going development, open problems, design issues, > developers manual/guide, knowledge base, etc. ..., could in principle > be put there in the old-fashioned way by editing HTML. I use to view Wikis as a sort of more easily editable web-pages with the added bonus of version history. > On the other hand, a really small content management system (Wiki?) > could be nice way to put the aforementioned topics on-line in a well > structured way. So, with no forum and no excessive interface it would > be okay with me. Do such systems exist? What do you mean with forum? Cheers -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Wed Nov 16 14:44:31 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 16 Nov 2005 14:44:31 +0100 Subject: [GiNaC-devel] ginac homepage In-Reply-To: <437A4379.8010309@ginac.de> References: <43785FF2.40707@physik.uni-wuppertal.de> <437A4379.8010309@ginac.de> Message-ID: <437B37BF.8080905@physik.uni-wuppertal.de> Hi, Richard B. Kreckel wrote: > I use to view Wikis as a sort of more easily editable web-pages with the > added bonus of version history. Such a wiki could be a nice thing to have. But how would it integrate with the rest of the ginac.de homepage? Make just one link (currently the ToDO link) point to a wiki page, or transform the whole ginac.de page into a wiki? I have no experience with the installation and maintainance of wikis. How much work is it to get it started? > What do you mean with forum? Something where people post messages like on a mailing-list. The continuous dialogue between different people is then available as a web page. I don't need this. Mailing lists are fine with me as long as the developer group is small. Regards, Jens From kisilv at maths.leeds.ac.uk Wed Nov 16 19:44:19 2005 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Wed, 16 Nov 2005 18:44:19 +0000 (GMT) Subject: [GiNaC-devel] Patch for products of dummy summations Message-ID: >>>>> "RK" == Richard B Kreckel 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 at amsta.leeds.ac.uk www: http://amsta.leeds.ac.uk/~kisilv -------------- next part -------------- Index: ginac/mul.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/mul.cpp,v retrieving revision 1.90 diff -r1.90 mul.cpp 897a898,912 > exvector add1_dummy_indices, add2_dummy_indices, add_indices; > > for (epvector::const_iterator i=add1begin; i!=add1end; ++i) { > add_indices = get_all_dummy_indices(i->rest); > add1_dummy_indices.insert(add1_dummy_indices.end(), add_indices.begin(), add_indices.end()); > } > for (epvector::const_iterator i=add2begin; i!=add2end; ++i) { > add_indices = get_all_dummy_indices(i->rest); > add2_dummy_indices.insert(add2_dummy_indices.end(), add_indices.begin(), add_indices.end()); > } > > sort(add1_dummy_indices.begin(), add1_dummy_indices.end(), ex_is_less()); > sort(add2_dummy_indices.begin(), add2_dummy_indices.end(), ex_is_less()); > lst dummy_subs = rename_dummy_indices_uniquely(add1_dummy_indices, add2_dummy_indices); > 899c914 < for (epvector::const_iterator i1=add1begin; i1!=add1end; ++i1) { --- > for (epvector::const_iterator i2=add2begin; i2!=add2end; ++i2) { 904c919,921 < for (epvector::const_iterator i2=add2begin; i2!=add2end; ++i2) { --- > ex i2_new = (dummy_subs.op(0).nops()>0? > i2->rest.subs((lst)dummy_subs.op(0), (lst)dummy_subs.op(1), subs_options::no_pattern) : i2->rest); > for (epvector::const_iterator i1=add1begin; i1!=add1end; ++i1) { 907c924 < const ex rest = (new mul(i1->rest, rename_dummy_indices_uniquely(i1->rest, i2->rest)))->setflag(status_flags::dynallocated); --- > const ex rest = (new mul(i1->rest, i2_new))->setflag(status_flags::dynallocated); 934a952,953 > exvector va = get_all_dummy_indices(mul(non_adds)); > sort(va.begin(), va.end(), ex_is_less()); 938c957 < factors.push_back(split_ex_to_pair(rename_dummy_indices_uniquely(mul(non_adds), last_expanded.op(i)))); --- > factors.push_back(split_ex_to_pair(rename_dummy_indices_uniquely(va, last_expanded.op(i)))); Index: ginac/ncmul.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/ncmul.cpp,v retrieving revision 1.57 diff -r1.57 ncmul.cpp 173,174c173,175 < size_t j = 0; < size_t i; --- > size_t j = 0, i; > exvector va; > 180c181 < expanded_seq_mod.push_back(rename_dummy_indices_uniquely(ncmul(expanded_seq_mod), expanded_seq[i])); --- > expanded_seq_mod.push_back(rename_dummy_indices_uniquely(va, expanded_seq[i], true)); 187c188 < term[positions_of_adds[i]] = rename_dummy_indices_uniquely(ncmul(term), expanded_seq[positions_of_adds[i]].op(k[i])); --- > term[positions_of_adds[i]] = rename_dummy_indices_uniquely(va, expanded_seq[positions_of_adds[i]].op(k[i]), true); Index: ginac/power.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/power.cpp,v retrieving revision 1.102 diff -r1.102 power.cpp 866a867,869 > exvector va = get_all_dummy_indices(m); > sort(va.begin(), va.end(), ex_is_less()); > 868c871 < result *= rename_dummy_indices_uniquely(m,m); --- > result *= rename_dummy_indices_uniquely(va, m); Index: ginac/indexed.h =================================================================== RCS file: /home/cvs/GiNaC/ginac/indexed.h,v retrieving revision 1.53 diff -r1.53 indexed.h 256a257,260 > /** Returns b with all dummy indices, which are listed in va, renamed > * if modify_va is set to TRUE all dummy indices of b will be appended to va */ > ex rename_dummy_indices_uniquely(exvector & va, const ex & b, bool modify_va = false); > 262a267,270 > /** Similar to above, where va and vb are the same and the return value is a list of two lists > * for substitution in b */ > lst rename_dummy_indices_uniquely(const exvector & va, const exvector & vb); > Index: ginac/indexed.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/indexed.cpp,v retrieving revision 1.97 diff -r1.97 indexed.cpp 1377c1377 < ex rename_dummy_indices_uniquely(const exvector & va, const exvector & vb, const ex & b) --- > lst rename_dummy_indices_uniquely(const exvector & va, const exvector & vb) 1382c1382 < return b; --- > return lst(lst(), lst()); 1411c1411 < return b.subs(lst(old_indices.begin(), old_indices.end()), lst(new_indices.begin(), new_indices.end()), subs_options::no_pattern); --- > return lst(lst(old_indices.begin(), old_indices.end()), lst(new_indices.begin(), new_indices.end())); 1414a1415,1420 > ex rename_dummy_indices_uniquely(const exvector & va, const exvector & vb, const ex & b) > { > lst indices_subs = rename_dummy_indices_uniquely(va, vb); > return (indices_subs.op(0).nops()>0 ? b.subs((lst)indices_subs.op(0), (lst)indices_subs.op(1), subs_options::no_pattern) : b); > } > 1418,1421c1424,1461 < exvector vb = get_all_dummy_indices(b); < sort(va.begin(), va.end(), ex_is_less()); < sort(vb.begin(), vb.end(), ex_is_less()); < return rename_dummy_indices_uniquely(va, vb, b); --- > if (va.size() > 0) { > exvector vb = get_all_dummy_indices(b); > if (vb.size() > 0) { > sort(va.begin(), va.end(), ex_is_less()); > sort(vb.begin(), vb.end(), ex_is_less()); > lst indices_subs = rename_dummy_indices_uniquely(va, vb); > if (indices_subs.op(0).nops() > 0) > return b.subs((lst)indices_subs.op(0), (lst)indices_subs.op(1), subs_options::no_pattern); > } > } > return b; > } > > ex rename_dummy_indices_uniquely(exvector & va, const ex & b, bool modify_va) > { > if (va.size() > 0) { > exvector vb = get_all_dummy_indices(b); > if (vb.size() > 0) { > sort(vb.begin(), vb.end(), ex_is_less()); > lst indices_subs = rename_dummy_indices_uniquely(va, vb); > if (indices_subs.op(0).nops() > 0) { > if (modify_va) { > for (lst::const_iterator i = ex_to(indices_subs.op(1)).begin(); i != ex_to(indices_subs.op(1)).end(); ++i) > va.push_back(*i); > exvector uncommon_indices; > set_difference(vb.begin(), vb.end(), indices_subs.op(0).begin(), indices_subs.op(0).end(), std::back_insert_iterator(uncommon_indices), ex_is_less()); > exvector::const_iterator ip = uncommon_indices.begin(), ipend = uncommon_indices.end(); > while (ip != ipend) { > va.push_back(*ip); > ++ip; > } > sort(va.begin(), va.end(), ex_is_less()); > } > return b.subs((lst)indices_subs.op(0), (lst)indices_subs.op(1), subs_options::no_pattern); > } > } > } > return b; Index: check/exam_clifford.cpp =================================================================== RCS file: /home/cvs/GiNaC/check/exam_clifford.cpp,v retrieving revision 1.27 diff -r1.27 exam_clifford.cpp 51c51 < for(int i = 0; i++; i < e1.nops()) { --- > for (unsigned int i = 0; i < e1.nops(); i++) { 53c53 < if (!e.is_zero()) { --- > if (!e.normal().is_zero()) { 317c317 < --- > 415c415 < result += check_equal_lst((e*e1).simplify_indexed(), dirac_ONE(1)); --- > result += check_equal((e*e1).simplify_indexed(), dirac_ONE(1)); From kreckel at ginac.de Wed Nov 16 22:29:19 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Wed, 16 Nov 2005 22:29:19 +0100 Subject: [GiNaC-devel] ginac homepage In-Reply-To: <437B37BF.8080905@physik.uni-wuppertal.de> References: <43785FF2.40707@physik.uni-wuppertal.de> <437A4379.8010309@ginac.de> <437B37BF.8080905@physik.uni-wuppertal.de> Message-ID: <437BA4AF.8030309@ginac.de> Hi, Jens Vollinga wrote: > Such a wiki could be a nice thing to have. But how would it integrate > with the rest of the ginac.de homepage? Make just one link (currently > the ToDO link) point to a wiki page, or transform the whole ginac.de > page into a wiki? I wasn't considering transforming the whole website. That does not make sense for generated documentation, for instance. > I have no experience with the installation and maintainance of wikis. > How much work is it to get it started? Probably not much, since the necessary wikimedia-infrastructure is all installed on the machine. But setting one up is new for me, too. Christian? >> What do you mean with forum? > > > Something where people post messages like on a mailing-list. The > continuous dialogue between different people is then available as a > web page. > I don't need this. > Mailing lists are fine with me as long as the developer group is small. Full ACK. -richy. -- Richard B. Kreckel From kreckel at ginac.de Wed Nov 16 22:42:59 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Wed, 16 Nov 2005 22:42:59 +0100 Subject: [GiNaC-devel] Patch for products of dummy summations In-Reply-To: References: Message-ID: <437BA7E3.20905@ginac.de> Vladimir Kisil wrote: > 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. Was that patch for the 1.3 branch or for HEAD? In any case: When I try applying it to any of the two, some hunks fail. Could you please make sure your working tree is up-to-date and maybe add some lines of context to your patch, e.g. with diff -u? Regards -richy. -- Richard B. Kreckel From kisilv at maths.leeds.ac.uk Wed Nov 16 22:55:19 2005 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Wed, 16 Nov 2005 21:55:19 +0000 (GMT) Subject: [GiNaC-devel] Patch for products of dummy summations In-Reply-To: <437BA7E3.20905@ginac.de> References: <437BA7E3.20905@ginac.de> Message-ID: > Was that patch for the 1.3 branch or for HEAD? In any case: When I try > applying it to any of the two, some hunks fail. I tried my patch on HEAD, but it may work with 1.3 branch as well. I did syncronisation of CVS today and am attaching "diff -u" version of this patch to this message. Hope it will work now. Best wishes, Vladimir -- Vladimir Kisil email: kisilv at amsta.leeds.ac.uk www: http://amsta.leeds.ac.uk/~kisilv -------------- next part -------------- Index: ginac/mul.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/mul.cpp,v retrieving revision 1.90 diff -u -r1.90 mul.cpp --- ginac/mul.cpp 24 Jul 2005 21:02:39 -0000 1.90 +++ ginac/mul.cpp 16 Nov 2005 21:50:30 -0000 @@ -895,16 +895,33 @@ // Compute the new overall coefficient and put it together: ex tmp_accu = (new add(distrseq, add1.overall_coeff*add2.overall_coeff))->setflag(status_flags::dynallocated); + exvector add1_dummy_indices, add2_dummy_indices, add_indices; + + for (epvector::const_iterator i=add1begin; i!=add1end; ++i) { + add_indices = get_all_dummy_indices(i->rest); + add1_dummy_indices.insert(add1_dummy_indices.end(), add_indices.begin(), add_indices.end()); + } + for (epvector::const_iterator i=add2begin; i!=add2end; ++i) { + add_indices = get_all_dummy_indices(i->rest); + add2_dummy_indices.insert(add2_dummy_indices.end(), add_indices.begin(), add_indices.end()); + } + + sort(add1_dummy_indices.begin(), add1_dummy_indices.end(), ex_is_less()); + sort(add2_dummy_indices.begin(), add2_dummy_indices.end(), ex_is_less()); + lst dummy_subs = rename_dummy_indices_uniquely(add1_dummy_indices, add2_dummy_indices); + // Multiply explicitly all non-numeric terms of add1 and add2: - for (epvector::const_iterator i1=add1begin; i1!=add1end; ++i1) { + for (epvector::const_iterator i2=add2begin; i2!=add2end; ++i2) { // We really have to combine terms here in order to compactify // the result. Otherwise it would become waayy tooo bigg. numeric oc; distrseq.clear(); - for (epvector::const_iterator i2=add2begin; i2!=add2end; ++i2) { + ex i2_new = (dummy_subs.op(0).nops()>0? + i2->rest.subs((lst)dummy_subs.op(0), (lst)dummy_subs.op(1), subs_options::no_pattern) : i2->rest); + for (epvector::const_iterator i1=add1begin; i1!=add1end; ++i1) { // Don't push_back expairs which might have a rest that evaluates to a numeric, // since that would violate an invariant of expairseq: - const ex rest = (new mul(i1->rest, rename_dummy_indices_uniquely(i1->rest, i2->rest)))->setflag(status_flags::dynallocated); + const ex rest = (new mul(i1->rest, i2_new))->setflag(status_flags::dynallocated); if (is_exactly_a(rest)) { oc += ex_to(rest).mul(ex_to(i1->coeff).mul(ex_to(i2->coeff))); } else { @@ -932,10 +949,12 @@ size_t n = last_expanded.nops(); exvector distrseq; distrseq.reserve(n); + exvector va = get_all_dummy_indices(mul(non_adds)); + sort(va.begin(), va.end(), ex_is_less()); for (size_t i=0; isetflag(status_flags::dynallocated); if (can_be_further_expanded(term)) { distrseq.push_back(term.expand()); Index: ginac/ncmul.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/ncmul.cpp,v retrieving revision 1.57 diff -u -r1.57 ncmul.cpp --- ginac/ncmul.cpp 19 May 2005 14:10:40 -0000 1.57 +++ ginac/ncmul.cpp 16 Nov 2005 21:50:30 -0000 @@ -170,21 +170,22 @@ /* Rename indices in the static members of the product */ exvector expanded_seq_mod; - size_t j = 0; - size_t i; + size_t j = 0, i; + exvector va; + for (i=0; i Index: ginac/power.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/power.cpp,v retrieving revision 1.102 diff -u -r1.102 power.cpp --- ginac/power.cpp 9 Nov 2005 13:47:00 -0000 1.102 +++ ginac/power.cpp 16 Nov 2005 21:50:30 -0000 @@ -864,8 +864,11 @@ // Leave it to multiplication since dummy indices have to be renamed if (get_all_dummy_indices(m).size() > 0 && n.is_positive()) { ex result = m; + exvector va = get_all_dummy_indices(m); + sort(va.begin(), va.end(), ex_is_less()); + for (int i=1; i < n.to_int(); i++) - result *= rename_dummy_indices_uniquely(m,m); + result *= rename_dummy_indices_uniquely(va, m); return result; } Index: ginac/indexed.h =================================================================== RCS file: /home/cvs/GiNaC/ginac/indexed.h,v retrieving revision 1.53 diff -u -r1.53 indexed.h --- ginac/indexed.h 11 Nov 2005 12:05:24 -0000 1.53 +++ ginac/indexed.h 16 Nov 2005 21:50:30 -0000 @@ -254,12 +254,20 @@ /** Returns all dummy indices from the expression */ exvector get_all_dummy_indices(const ex & e); +/** Returns b with all dummy indices, which are listed in va, renamed + * if modify_va is set to TRUE all dummy indices of b will be appended to va */ +ex rename_dummy_indices_uniquely(exvector & va, const ex & b, bool modify_va = false); + /** Returns b with all dummy indices, which are common with a, renamed */ ex rename_dummy_indices_uniquely(const ex & a, const ex & b); /** Same as above, where va and vb contain the indices of a and b and are sorted */ ex rename_dummy_indices_uniquely(const exvector & va, const exvector & vb, const ex & b); +/** Similar to above, where va and vb are the same and the return value is a list of two lists + * for substitution in b */ +lst rename_dummy_indices_uniquely(const exvector & va, const exvector & vb); + /** This function returns the given expression with expanded sums * for all dummy index summations, where the dimensionality of * the dummy index is numeric. Index: ginac/indexed.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/indexed.cpp,v retrieving revision 1.97 diff -u -r1.97 indexed.cpp --- ginac/indexed.cpp 11 Nov 2005 12:05:24 -0000 1.97 +++ ginac/indexed.cpp 16 Nov 2005 21:50:30 -0000 @@ -1374,12 +1374,12 @@ return v; } -ex rename_dummy_indices_uniquely(const exvector & va, const exvector & vb, const ex & b) +lst rename_dummy_indices_uniquely(const exvector & va, const exvector & vb) { exvector common_indices; set_intersection(va.begin(), va.end(), vb.begin(), vb.end(), std::back_insert_iterator(common_indices), ex_is_less()); if (common_indices.empty()) { - return b; + return lst(lst(), lst()); } else { exvector new_indices, old_indices; old_indices.reserve(2*common_indices.size()); @@ -1408,17 +1408,57 @@ } ++ip; } - return b.subs(lst(old_indices.begin(), old_indices.end()), lst(new_indices.begin(), new_indices.end()), subs_options::no_pattern); + return lst(lst(old_indices.begin(), old_indices.end()), lst(new_indices.begin(), new_indices.end())); } } +ex rename_dummy_indices_uniquely(const exvector & va, const exvector & vb, const ex & b) +{ + lst indices_subs = rename_dummy_indices_uniquely(va, vb); + return (indices_subs.op(0).nops()>0 ? b.subs((lst)indices_subs.op(0), (lst)indices_subs.op(1), subs_options::no_pattern) : b); +} + ex rename_dummy_indices_uniquely(const ex & a, const ex & b) { exvector va = get_all_dummy_indices(a); - exvector vb = get_all_dummy_indices(b); - sort(va.begin(), va.end(), ex_is_less()); - sort(vb.begin(), vb.end(), ex_is_less()); - return rename_dummy_indices_uniquely(va, vb, b); + if (va.size() > 0) { + exvector vb = get_all_dummy_indices(b); + if (vb.size() > 0) { + sort(va.begin(), va.end(), ex_is_less()); + sort(vb.begin(), vb.end(), ex_is_less()); + lst indices_subs = rename_dummy_indices_uniquely(va, vb); + if (indices_subs.op(0).nops() > 0) + return b.subs((lst)indices_subs.op(0), (lst)indices_subs.op(1), subs_options::no_pattern); + } + } + return b; +} + +ex rename_dummy_indices_uniquely(exvector & va, const ex & b, bool modify_va) +{ + if (va.size() > 0) { + exvector vb = get_all_dummy_indices(b); + if (vb.size() > 0) { + sort(vb.begin(), vb.end(), ex_is_less()); + lst indices_subs = rename_dummy_indices_uniquely(va, vb); + if (indices_subs.op(0).nops() > 0) { + if (modify_va) { + for (lst::const_iterator i = ex_to(indices_subs.op(1)).begin(); i != ex_to(indices_subs.op(1)).end(); ++i) + va.push_back(*i); + exvector uncommon_indices; + set_difference(vb.begin(), vb.end(), indices_subs.op(0).begin(), indices_subs.op(0).end(), std::back_insert_iterator(uncommon_indices), ex_is_less()); + exvector::const_iterator ip = uncommon_indices.begin(), ipend = uncommon_indices.end(); + while (ip != ipend) { + va.push_back(*ip); + ++ip; + } + sort(va.begin(), va.end(), ex_is_less()); + } + return b.subs((lst)indices_subs.op(0), (lst)indices_subs.op(1), subs_options::no_pattern); + } + } + } + return b; } ex expand_dummy_sum(const ex & e, bool subs_idx) Index: check/exam_clifford.cpp =================================================================== RCS file: /home/cvs/GiNaC/check/exam_clifford.cpp,v retrieving revision 1.27 diff -u -r1.27 exam_clifford.cpp --- check/exam_clifford.cpp 12 Jul 2005 17:56:29 -0000 1.27 +++ check/exam_clifford.cpp 16 Nov 2005 21:50:30 -0000 @@ -48,9 +48,9 @@ static unsigned check_equal_lst(const ex & e1, const ex & e2) { - for(int i = 0; i++; i < e1.nops()) { + for (unsigned int i = 0; i < e1.nops(); i++) { ex e = e1.op(i) - e2.op(i); - if (!e.is_zero()) { + if (!e.normal().is_zero()) { clog << "(" << e1 << ") - (" << e2 << ") erroneously returned " << e << " instead of 0 (in the entry " << i << ")" << endl; return 1; @@ -314,7 +314,7 @@ matrix A_symm(4,4), A2(4, 4); A_symm = A.add(A.transpose()).mul(half); A2 = A_symm.mul(A_symm); - + ex e, e1; bool anticommuting = ex_to(clifford_unit(nu, A)).is_anticommuting(); int result = 0; @@ -412,7 +412,7 @@ ex c = clifford_unit(nu, A, 1); e = lst_to_clifford(lst(t, x, y, z), mu, A, 1) * lst_to_clifford(lst(1, 2, 3, 4), c); e1 = clifford_inverse(e); - result += check_equal_lst((e*e1).simplify_indexed(), dirac_ONE(1)); + result += check_equal((e*e1).simplify_indexed(), dirac_ONE(1)); // Moebius map (both forms) checks for symmetric metrics only matrix M1(2, 2), M2(2, 2); From kreckel at ginac.de Thu Nov 17 23:29:49 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Thu, 17 Nov 2005 23:29:49 +0100 Subject: [GiNaC-devel] Patch for products of dummy summations In-Reply-To: References: <437BA7E3.20905@ginac.de> Message-ID: <437D045D.7080503@ginac.de> Vladimir Kisil wrote: > >> Was that patch for the 1.3 branch or for HEAD? In any case: When I >> try applying it to any of the two, some hunks fail. > > > I tried my patch on HEAD, but it may work with 1.3 branch as well. > I did syncronisation of CVS today and am attaching "diff -u" version > of this patch to this message. Hope it will work now. Thank you. It works now and it indeed restores the speed we lost on the 1.3 branch. I've applied your patch to HEAD. Best wishes -richy. PS: It's probably a good idea to provide some lines of context in each patch. It makes them more readable, both for reviewing and for troubleshooting in case something goes wrong. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Fri Nov 18 12:22:32 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Fri, 18 Nov 2005 12:22:32 +0100 Subject: [GiNaC-devel] new tinfos Message-ID: <437DB978.1040804@physik.uni-wuppertal.de> 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 From cb at cebix.net Fri Nov 18 18:25:49 2005 From: cb at cebix.net (Christian Bauer) Date: Fri, 18 Nov 2005 18:25:49 +0100 (CET) Subject: [GiNaC-devel] tinfo In-Reply-To: <437479D7.7010706@physik.uni-wuppertal.de> Message-ID: On 11/11/2005, "Jens Vollinga" wrote: > tinfo = (unsigned)tinfo_name; How do you guarantee that TINFOs are unique if sizeof(char *) > sizeof(unsigned)? Bye, Christian From kreckel at ginac.de Sat Nov 19 21:42:11 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Sat, 19 Nov 2005 21:42:11 +0100 Subject: [GiNaC-devel] new tinfos In-Reply-To: <437DB978.1040804@physik.uni-wuppertal.de> References: <437DB978.1040804@physik.uni-wuppertal.de> Message-ID: <437F8E23.5000506@ginac.de> Hi! Jens Vollinga wrote: > 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? Failures that can be traced to changes in the actual hash values are not serious. This is the same issue that was brought up by Jonathan Brandmeyer recently, where he wondered why the PyGiNaC testsuite failed sometimes: . The same can happen when the serial numbers of symbols change because an additional symbol is created earlier on in the program. Or one symbol less. This has nothing to do with your tinfo-ideas: I would suggest to change these exams in the testsuite by calling expand(), normal() or doing additional index contraction, respectively. The way they are written right now is not good, especially from a didactical point of view. People should learn not to rely on random behavior. > 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. I made an attempt in that direction several years ago. It didn't go too well: . But then, maybe you're up to something different. Could you elaborate a little on your ideas? Cheers -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Mon Nov 21 17:41:57 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Mon, 21 Nov 2005 17:41:57 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: References: Message-ID: <4381F8D5.9050107@physik.uni-wuppertal.de> Hi, Christian Bauer wrote: > On 11/11/2005, "Jens Vollinga" wrote: >> tinfo = (unsigned)tinfo_name; > > How do you guarantee that TINFOs are unique if sizeof(char *) > > sizeof(unsigned)? No guarantee, I guess. But tinfo could become a char*, couldn't it? Jens From vollinga at physik.uni-wuppertal.de Mon Nov 21 17:56:13 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Mon, 21 Nov 2005 17:56:13 +0100 Subject: [GiNaC-devel] new tinfos In-Reply-To: <437F8E23.5000506@ginac.de> References: <437DB978.1040804@physik.uni-wuppertal.de> <437F8E23.5000506@ginac.de> Message-ID: <4381FC2D.7090602@physik.uni-wuppertal.de> Hi, Richard B. Kreckel wrote: >> 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 same can happen when the serial numbers of symbols change because an > additional symbol is created earlier on in the program. Or one symbol > less. This has nothing to do with your tinfo-ideas: I would suggest to > change these exams in the testsuite by calling expand(), normal() or > doing additional index contraction, respectively. The way they are > written right now is not good, especially from a didactical point of > view. People should learn not to rely on random behavior. Good. Then I only have to re-examine the canonicalize_clifford difference. >> 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. > > I made an attempt in that direction several years ago. It didn't go too > well: > . But > then, maybe you're up to something different. Could you elaborate a > little on your ideas? I am just starting to think about it. Arguments like 'no advantage' and 'no hierarchy' aren't valid anymore, I think. Whether the complexity to define such a class-function is lower, equal or higher than the current one has to be evaluated. I haven't figured out the exact way how such a class-function could be implemented, though. Stupid question: what are the numeric SOMEFUNC(const numeric& ...) functions good for? Is it performance? Is it a way to try to separate cln stuff from ginac stuff? I don't know how to solve the problem of namespace collision/ambiguity with built-in function like sin,cos,... yet. But even in the current implementation a get an ambiguity for stuff like cout << sin(1) << endl; when both cmath and GiNaC are included and all their namespace members are us'ing'ed. Regards, Jens From vollinga at physik.uni-wuppertal.de Mon Nov 21 18:28:56 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Mon, 21 Nov 2005 18:28:56 +0100 Subject: [GiNaC-devel] new tinfos In-Reply-To: <4381FC2D.7090602@physik.uni-wuppertal.de> References: <437DB978.1040804@physik.uni-wuppertal.de> <437F8E23.5000506@ginac.de> <4381FC2D.7090602@physik.uni-wuppertal.de> Message-ID: <438203D8.4060206@physik.uni-wuppertal.de> Hi, Jens Vollinga wrote: > I don't know how to solve the problem of namespace collision/ambiguity > with built-in function like sin,cos,... yet. But even in the current > implementation a get an ambiguity for stuff like > cout << sin(1) << endl; > when both cmath and GiNaC are included and all their namespace members > are us'ing'ed. just to fill the void: 1. We could rename the functions: tan->Tan,... etc. (I don't like this. It's cowardice.) 2. We could write some pre-processor definitions like #define sin GiNaC::sin ... (Well, maybe. These definition could be packed in a convenience header for the user like #include . But better not to include this header multiple times ...) 3. Don't avoid the ambiguities and force the user to explicitly write the namespace for such functions (and make lots of comments about it in the manual/tutorial). (Yes, use the force! Maybe give the user some extra header like in 2. to ease the situation). Regards, Jens From kreckel at ginac.de Mon Nov 21 21:40:43 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Mon, 21 Nov 2005 21:40:43 +0100 Subject: [GiNaC-devel] new tinfos In-Reply-To: <4381FC2D.7090602@physik.uni-wuppertal.de> References: <437DB978.1040804@physik.uni-wuppertal.de> <437F8E23.5000506@ginac.de> <4381FC2D.7090602@physik.uni-wuppertal.de> Message-ID: <438230CB.90208@ginac.de> Hi! Jens Vollinga wrote: > I am just starting to think about it. Arguments like 'no advantage' > and 'no hierarchy' aren't valid anymore, I think. Well, is there a useful type-hiearchy one could build out of functions? And: what could be the advantage of such an approach? Please show us! The wrapper functions are there because you cannot define classes of name sin, cos, etc. without running into tons of resolution problems. You would have to call the classes differently and add convenient functions that return those classes. That's what we already have, except they always return the same type. > Whether the complexity to define such a class-function is lower, equal > or higher than the current one has to be evaluated. I haven't figured > out the exact way how such a class-function could be implemented, though. > > Stupid question: what are the > numeric SOMEFUNC(const numeric& ...) > functions good for? Is it performance? Is it a way to try to separate > cln stuff from ginac stuff? Oh, that is only a more direct evaluation when only numeric evaluation is called for. It's got nothing to do with CLN. Rather, performance. And maybe it's not terribly useful. But isn't this the same question: what is numeric operator+(const numeric&, const numeric&) good for? > I don't know how to solve the problem of namespace collision/ambiguity > with built-in function like sin,cos,... yet. But even in the current > implementation a get an ambiguity for stuff like > cout << sin(1) << endl; > when both cmath and GiNaC are included and all their namespace members > are us'ing'ed. But that is just a problem with our implementation of ginac/function.h! CLN has no such problem, even with newer versions of GCC. If that is really a concern, I suggest simply adding disambiguating explicit signatures to the templates that DECLARE_FUNCTION_nP expand to. It cannot be done for all and every combination of them because that would be too much code. But then, we really only need it for DECLARE_FUNCTION_1P and DECLARE_FUNCTION_2P, right? Regards -richy. -- Richard B. Kreckel From kreckel at ginac.de Mon Nov 21 21:55:27 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Mon, 21 Nov 2005 21:55:27 +0100 Subject: [GiNaC-devel] new tinfos In-Reply-To: <438203D8.4060206@physik.uni-wuppertal.de> References: <437DB978.1040804@physik.uni-wuppertal.de> <437F8E23.5000506@ginac.de> <4381FC2D.7090602@physik.uni-wuppertal.de> <438203D8.4060206@physik.uni-wuppertal.de> Message-ID: <4382343F.9070204@ginac.de> Hi! Jens Vollinga wrote: >> I don't know how to solve the problem of namespace >> collision/ambiguity with built-in function like sin,cos,... yet. But >> even in the current implementation a get an ambiguity for stuff like >> cout << sin(1) << endl; >> when both cmath and GiNaC are included and all their namespace >> members are us'ing'ed. > > > just to fill the void: > > 1. > We could rename the functions: tan->Tan,... etc. > (I don't like this. It's cowardice.) > > 2. > We could write some pre-processor definitions like > #define sin GiNaC::sin > ... > (Well, maybe. These definition could be packed in a convenience header > for the user like #include . But better not to > include this header multiple times ...) I fear this will cause even more problems. > 3. > Don't avoid the ambiguities and force the user to explicitly write the > namespace for such functions (and make lots of comments about it in > the manual/tutorial). > (Yes, use the force! Maybe give the user some extra header like in 2. > to ease the situation). This is a patch to the wrong location, since function.h is generated. But doesn't it resolve the worst ambiguities where there is a conflict with cmath's template typename __enable_if::__value>::__type sin(_Tp)? --- function.h.old 2005-11-21 21:43:16.063691034 +0100 +++ function.h 2005-11-21 21:42:19.964061214 +0100 @@ -39,6 +39,15 @@ #define DECLARE_FUNCTION_1P(NAME) \ class NAME##_SERIAL { public: static unsigned serial; }; \ const unsigned NAME##_NPARAMS = 1; \ +const GiNaC::function NAME(const ex & p1) { \ + return GiNaC::function(NAME##_SERIAL::serial, p1); \ +} \ +const GiNaC::function NAME(int p1) { \ + return GiNaC::function(NAME##_SERIAL::serial, GiNaC::ex(p1)); \ +} \ template const GiNaC::function NAME(const T1 & p1) { \ return GiNaC::function(NAME##_SERIAL::serial, GiNaC::ex(p1)); \ } Cheers -richy. -- Richard B. Kreckel From cb at cebix.net Tue Nov 22 09:47:25 2005 From: cb at cebix.net (Christian Bauer) Date: Tue, 22 Nov 2005 09:47:25 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: <4381F8D5.9050107@physik.uni-wuppertal.de> References: <4381F8D5.9050107@physik.uni-wuppertal.de> Message-ID: <4382DB1D.1030509@cebix.net> Jens Vollinga wrote: > But tinfo could become a char*, couldn't it? How about: typedef const void * tinfo_t; struct tinfo_static_t {}; class SOMECLASS { public: static const tinfo_static_t tinfo_static; SOMECLASS() : tinfo_key(&tinfo_static) {} SOMECLASS(tinfo_t ti) : tinfo_key(ti) {} tinfo_t tinfo() const { return tinfo_key; } protected: tinfo_t tinfo_key; }; const tinfo_static_t SOMECLASS::tinfo_static = {}; template inline bool is_exactly_a(const SOMECLASS & obj) { return obj.tinfo() == &T::tinfo_static; } This looks promising. No explicit specializations of is_exactly_a<> are needed any more. Bye, Christian -- / Physics is an algorithm \/ www.cebix.net From vollinga at physik.uni-wuppertal.de Tue Nov 22 16:25:15 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 22 Nov 2005 16:25:15 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: <4382DB1D.1030509@cebix.net> References: <4381F8D5.9050107@physik.uni-wuppertal.de> <4382DB1D.1030509@cebix.net> Message-ID: <4383385B.4070707@physik.uni-wuppertal.de> Hi, Christian Bauer wrote: > How about: > > typedef const void * tinfo_t; > struct tinfo_static_t {}; > > class SOMECLASS { > public: > static const tinfo_static_t tinfo_static; > > SOMECLASS() : tinfo_key(&tinfo_static) {} > SOMECLASS(tinfo_t ti) : tinfo_key(ti) {} > > tinfo_t tinfo() const { return tinfo_key; } > > protected: > tinfo_t tinfo_key; > }; > > const tinfo_static_t SOMECLASS::tinfo_static = {}; > > template > inline bool is_exactly_a(const SOMECLASS & obj) > { > return obj.tinfo() == &T::tinfo_static; > } > > This looks promising. No explicit specializations of is_exactly_a<> are > needed any more. Why don't you want to use char* as a static source of address? Is it just a matter of taste? (If the class name is moved out of registered_class_options there is no duplication.) Or is something more involved I don't see? Is it guaranteed that no smart optimizer will merge all static tinfo_static_t into one (there are all the same, aren't they?) with the effect that all tinfo_keys will be the same? The char* version again (I just wrote it from memory. I hope I didn't make some silly mistakes): typedef const char* tinfo_t; class SOMECLASS { public: static tinfo_t tinfo_name; SOMECLASS() : tinfo_key(tinfo_name) {} SOMECLASS(tinfo_t ti) : tinfo_key(ti) {} tinfo_t tinfo() const { return tinfo_key; } protected: tinfo_t tinfo_key; }; const tinfo_t SOMECLASS::tinfo_name = "SOMECLASS"; template inline bool is_exactly_a(const SOMECLASS & obj) { return obj.tinfo() == T::tinfo_name; } BTW, maybe some disadvantage of both of the new ways: in order to avoid as much as possible hash clashes, which are costly, the seed for the hash calculation should be unique. With the new tinfos the bit pattern for them in most cases has just changing least significant bits. With a seed setup like tinfo^serial (serial a small number) for symbols as an example, one is likely to get more hash clashes, I guess. So the seed setup has to be changed for some classes as well, I think. Regards, Jens From vollinga at physik.uni-wuppertal.de Tue Nov 22 16:53:27 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 22 Nov 2005 16:53:27 +0100 Subject: [GiNaC-devel] new tinfos In-Reply-To: <4382343F.9070204@ginac.de> References: <437DB978.1040804@physik.uni-wuppertal.de> <437F8E23.5000506@ginac.de> <4381FC2D.7090602@physik.uni-wuppertal.de> <438203D8.4060206@physik.uni-wuppertal.de> <4382343F.9070204@ginac.de> Message-ID: <43833EF7.6030807@physik.uni-wuppertal.de> Hi, Richard B. Kreckel wrote: >> 3. >> Don't avoid the ambiguities and force the user to explicitly write the >> namespace for such functions (and make lots of comments about it in >> the manual/tutorial). >> (Yes, use the force! Maybe give the user some extra header like in 2. >> to ease the situation). > > This is a patch to the wrong location, since function.h is generated. > But doesn't it resolve the worst ambiguities where there is a conflict > with cmath's template typename __enable_if 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 . Enjoy! -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Fri Nov 25 15:25:25 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Fri, 25 Nov 2005 15:25:25 +0100 Subject: [GiNaC-devel] new function system Message-ID: <43871ED5.8040704@physik.uni-wuppertal.de> 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(e)) { std::string name = ex_to(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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fclass.cpp URL: From kreckel at ginac.de Fri Nov 25 23:32:26 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Fri, 25 Nov 2005 23:32:26 +0100 Subject: [GiNaC-devel] new function system In-Reply-To: <43871ED5.8040704@physik.uni-wuppertal.de> References: <43871ED5.8040704@physik.uni-wuppertal.de> Message-ID: <438790FA.8020500@ginac.de> Hi Jens! Jens Vollinga wrote: > 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(e)) { > std::string name = ex_to(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 Basically, I begin to appreciate (well, again) the idea of having symbolic functions as objects of different classes, one for each mathematical function. But the idea of _not_ being able to write sin(something), when I want a sine of something is not very appealing, I think. What about this alternative: Name the classes sin_t, log_t, tgamma_t (or some other uniform scheme) and provide functions sin, log, tgamma that return objects of these classes. The advantages are that people a) don't have to rewrite too much code and b) we don't bother our users with yet another convention for naming mathematical functions. Does that sound reasonable? Though, I totally agree with your earlier sentiment that in the general case we shouldn't worry too much about name clashes and instead we should put the burden of disambiguation on the user. But in special cases where there are conflicts with functions of built-in integral type, I think it is just fine to disambiguate in favor of the GiNaC functions by adding an explicit signature. This way, sin(1) stays what it is: sin(1) (well, sin_t(1) or function(42,1) or whatever) and does not become 0.84147... I remember that when we first hit the problem of what sin(1) is supposed to be, I had tons of explicit overloads but quickly found that the template was a more clever idea. Well, if it clashes again because GCC's cmath has become just as clever, good for GCC and maybe bad for us. Going back to some (not all!) explicit overloads sounds elegant, if it solves the problems at hand, doesn't it? Cheers -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Sat Nov 26 10:03:54 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Sat, 26 Nov 2005 10:03:54 +0100 Subject: [GiNaC-devel] new function system In-Reply-To: <438790FA.8020500@ginac.de> References: <43871ED5.8040704@physik.uni-wuppertal.de> <438790FA.8020500@ginac.de> Message-ID: <438824FA.4090200@physik.uni-wuppertal.de> Hi, Richard B. Kreckel wrote: > What about this alternative: > > Name the classes sin_t, log_t, tgamma_t (or some other uniform scheme) > and provide functions sin, log, tgamma that return objects of these > classes. The advantages are that people a) don't have to rewrite too > much code and b) we don't bother our users with yet another convention > for naming mathematical functions. Does that sound reasonable? > > Though, I totally agree with your earlier sentiment that in the general > case we shouldn't worry too much about name clashes and instead we > should put the burden of disambiguation on the user. But in special > cases where there are conflicts with functions of built-in integral > type, I think it is just fine to disambiguate in favor of the GiNaC > functions by adding an explicit signature. This way, sin(1) stays what > it is: sin(1) (well, sin_t(1) or function(42,1) or whatever) and does > not become 0.84147... sorry, I don't fully understand your proposal, yet. Why should the user have to learn another convention (as stated above under b)) if all the classes have the same name as the current functions? Why is it fine to disambiguate just in case of integral types (see question below)? sin(1) doesn't disambiguate currently when one includes cmath!! Does it really make sense to have sin(1) or zeta(2) evaled on creation (by means of a special function)? I remember having to 'tweak' zeta a little bit to not throw an exception when the argument is 1. And with the polylogs I often have to use a lot of .holds() just because I don't want the automatic evaluation in intermediate expressions. And isn't there an issue with 1/tgamma(-n) ...? Maybe a solution to this is easier without the automatic evaluation on creation. To have automatic evaluation just on assignment might (I am not sure though, please teach me!) be more clear, powerful, ... Regards, Jens From kreckel at ginac.de Sat Nov 26 23:15:23 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Sat, 26 Nov 2005 23:15:23 +0100 Subject: [GiNaC-devel] new function system In-Reply-To: <438824FA.4090200@physik.uni-wuppertal.de> References: <43871ED5.8040704@physik.uni-wuppertal.de> <438790FA.8020500@ginac.de> <438824FA.4090200@physik.uni-wuppertal.de> Message-ID: <4388DE7B.7070107@ginac.de> Hi Jens, Jens Vollinga wrote: > > Why should the user have to learn another convention (as stated above > under b)) if all the classes have the same name as the current functions? Oh, you aren't proposing logGamma, etc. any more? Good. (And, please excuse my misunderstanding you.) > > Why is it fine to disambiguate just in case of integral types (see > question below)? sin(1) doesn't disambiguate currently when one > includes cmath!! Well, I was just suggesting to disambiguate the common cases like ex sin(int) in order to reduce the number of surprises. What else could one override? ex sin(double)? No! That would really conflict with cmath's declaration. (Note that CLN has sin(own types), as have many other such libraries). > > Does it really make sense to have sin(1) or zeta(2) evaled on creation > (by means of a special function)? I remember having to 'tweak' zeta a > little bit to not throw an exception when the argument is 1. You mean: to actually _throw_ an exception, I suppose? > And with the polylogs I often have to use a lot of .holds() just > because I don't want the automatic evaluation in intermediate > expressions. And isn't there an issue with 1/tgamma(-n) ...? What issue? Limits are quite another story, aren't they? > Maybe a solution to this is easier without the automatic evaluation on > creation. > To have automatic evaluation just on assignment might (I am not sure > though, please teach me!) be more clear, powerful, ... I don't understand: Each class has two evaluations: ctor and eval. The ctor cannot do everything because it is contrained to a specific class. The eval member functions, in contrast, have more leeway with the general ex they return. The intent was to do as much term rewriting as possible in the ctors, and do as much term rewriting as reasonable in the eval member functions. Maybe that is questionable, I don't know. However, all this doesn't hold for our functions, does it? We have sin(ex) invoking the ctor function::function(unsigned ser, const ex & param1) which doesn't do anything intersting. (This also accounts for the behavior described in .) Cheers -richy. -- Richard B. Kreckel From vollinga at physik.uni-wuppertal.de Mon Nov 28 14:49:01 2005 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Mon, 28 Nov 2005 14:49:01 +0100 Subject: [GiNaC-devel] new function system In-Reply-To: <4388DE7B.7070107@ginac.de> References: <43871ED5.8040704@physik.uni-wuppertal.de> <438790FA.8020500@ginac.de> <438824FA.4090200@physik.uni-wuppertal.de> <4388DE7B.7070107@ginac.de> Message-ID: <438B0ACD.1080404@physik.uni-wuppertal.de> Hi, Richard B. Kreckel wrote: > Oh, you aren't proposing logGamma, etc. any more? Good. (And, please > excuse my misunderstanding you.) Well, I wouldn't be unhappy if tgamma would be renamed to gamma, but I don't care too much. So, I don't propose it (anymore). > Well, I was just suggesting to disambiguate the common cases like ex > sin(int) in order to reduce the number of surprises. What else could > one override? ex sin(double)? No! That would really conflict with > cmath's declaration. (Note that CLN has sin(own types), as have many > other such libraries). Just to understand it: This disambiguation is not in GiNaC right now, but you propose it to be done like in your email posting from 2001? This probably got me confused and therefore I mentioned sin(1) etc... >> Does it really make sense to have sin(1) or zeta(2) evaled on creation >> (by means of a special function)? I remember having to 'tweak' zeta a >> little bit to not throw an exception when the argument is 1. > > You mean: to actually _throw_ an exception, I suppose? Forget about the eval on creation stuff I wrote. I got confused there, too. But, to NOT throw an exception in the case of arg=1 was a correct statement. >> expressions. And isn't there an issue with 1/tgamma(-n) ...? > > What issue? Limits are quite another story, aren't they? No, I meant 1/tgamma(-2) for example. Should be zero, I guess. But GiNaC doesn't like it and throws up ... > I don't understand: Each class has two evaluations: ctor and eval. The > ctor cannot do everything because it is contrained to a specific class. > The eval member functions, in contrast, have more leeway with the > general ex they return. The intent was to do as much term rewriting as > possible in the ctors, and do as much term rewriting as reasonable in > the eval member functions. Maybe that is questionable, I don't know. > However, all this doesn't hold for our functions, does it? We have > sin(ex) invoking the ctor function::function(unsigned ser, const ex & > param1) which doesn't do anything intersting. (This also accounts for > the behavior described in .) As stated above, I got a little confused %^) The new class-functions would not change anything here, or would they? So the point we are arguing about it whether more specializations in order to prevent ambiguities should be added? Regards, Jens From kreckel at ginac.de Tue Nov 29 21:43:34 2005 From: kreckel at ginac.de (Richard B. Kreckel) Date: Tue, 29 Nov 2005 21:43:34 +0100 Subject: [GiNaC-devel] new function system In-Reply-To: <438B0ACD.1080404@physik.uni-wuppertal.de> References: <43871ED5.8040704@physik.uni-wuppertal.de> <438790FA.8020500@ginac.de> <438824FA.4090200@physik.uni-wuppertal.de> <4388DE7B.7070107@ginac.de> <438B0ACD.1080404@physik.uni-wuppertal.de> Message-ID: <438CBD76.7080108@ginac.de> Hi! Jens Vollinga wrote: > > Well, I wouldn't be unhappy if tgamma would be renamed to gamma, but I > don't care too much. So, I don't propose it (anymore). Whatever. The name was chosen in anticipation of a future revision of the C++ standard. All we had back then was the C99 standard which named the two functions tgamma and lgamma. It appeard natural to assume that C++0x would eventually follow. Also gamma(x) was deemed to be a conflict with the derivatives of Riemann's zeta function. > >> Well, I was just suggesting to disambiguate the common cases like ex >> sin(int) in order to reduce the number of surprises. What else could >> one override? ex sin(double)? No! That would really conflict with >> cmath's declaration. (Note that CLN has sin(own types), as have many >> other such libraries). > > > Just to understand it: This disambiguation is not in GiNaC right now, > but you propose it to be done like in your email posting from 2001? > This probably got me confused and therefore I mentioned sin(1) etc... All I propose is to add a few additional signatures for ex GiNaC::sin() such that it is preferred over the definition in the header file when there would otherwise be a conflict. I suppose this is independent of whether the thing is a true ctor or a helper function returning an object representing a function in a symbolic way. (E.g. sin(ex) returning a sin_t object, maybe.) > >>> Does it really make sense to have sin(1) or zeta(2) evaled on >>> creation (by means of a special function)? I remember having to >>> 'tweak' zeta a little bit to not throw an exception when the >>> argument is 1. >> >> >> You mean: to actually _throw_ an exception, I suppose? > > > Forget about the eval on creation stuff I wrote. I got confused there, > too. But, to NOT throw an exception in the case of arg=1 was a correct > statement. But why? The zeta function has a simple pole at x==1 that goes like 1/x. With the same reasoning we should get rid of the exception thrown by tan(Pi/2) and all other pole_errors. Now, series((x-1)*zeta(x),x==1,2) returns zeta(1)*(x-1)+Order((x-1)^2). This is less helpful than 1+Order((x-1)^2). > >>> expressions. And isn't there an issue with 1/tgamma(-n) ...? >> >> >> What issue? Limits are quite another story, aren't they? > > > No, I meant 1/tgamma(-2) for example. Should be zero, I guess. But > GiNaC doesn't like it and throws up ... But this is precisely the issue of limits! Why should it be zero? After all, there is a simple pole in the denomiator. It makes perfect sense to stuff it into a Laurent series expansion, though. Indeed, series(1/tgamma(eps-2),eps==0,1) correctly returns Order(eps). If we had a limit command, then limit(1/tgamma(x),x==-2) should return 0, all right. Until then, Laurent series expansion must hold as a substitute for limits. Whether the approach to base the series expansion on limits is more fruitful than the other way round, I don't know. I think both ways work. If we want to deal with the Riemann sphere instead of just the complex numbers, then 1/tgamma(-2) should indeed be zero. But then we would have to add ComplexInfinity to our constants and make the corresponding adjustments to add, mul, etc. in order to avoid errors that would follow from rewriting ComplexInfinity-ComplexInfinity as 0. That is certainly possible. > >> I don't understand: Each class has two evaluations: ctor and eval. >> The ctor cannot do everything because it is contrained to a specific >> class. The eval member functions, in contrast, have more leeway with >> the general ex they return. The intent was to do as much term >> rewriting as possible in the ctors, and do as much term rewriting as >> reasonable in the eval member functions. Maybe that is questionable, >> I don't know. However, all this doesn't hold for our functions, does >> it? We have sin(ex) invoking the ctor function::function(unsigned >> ser, const ex & param1) which doesn't do anything intersting. (This >> also accounts for the behavior described in >> .) > > > As stated above, I got a little confused %^) The new class-functions > would not change anything here, or would they? Right. Cheers -richy. -- Richard B. Kreckel From cb at cebix.net Wed Nov 30 19:12:08 2005 From: cb at cebix.net (Christian Bauer) Date: Wed, 30 Nov 2005 19:12:08 +0100 Subject: [GiNaC-devel] tinfo In-Reply-To: <4383385B.4070707@physik.uni-wuppertal.de> References: <4381F8D5.9050107@physik.uni-wuppertal.de> <4382DB1D.1030509@cebix.net> <4383385B.4070707@physik.uni-wuppertal.de> Message-ID: <438DEB78.7050606@cebix.net> Jens Vollinga wrote: > Is it guaranteed that no smart optimizer will merge all static > tinfo_static_t into one (there are all the same, aren't they?) with the > effect that all tinfo_keys will be the same? Empty structs/classes have a guaranteed sizeof() > 0 so they won't end up at the same address if they are array or struct members, so I guess we're a little safer here. I do know, however, that compilers will merge string literals (which shouldn't matter since the class names are all different...). In any case, if the pointees are non-const, the compiler can't possibly merge the objects since a library user could (in theory) change the object through the pointer returned by tinfo(). Bye, Christian -- / Physics is an algorithm \/ www.cebix.net