From frink at thep.physik.uni-mainz.de Thu May 2 15:54:53 2002 From: frink at thep.physik.uni-mainz.de (Alexander Frink) Date: Thu, 2 May 2002 15:54:53 +0200 (CEST) Subject: Fibonacci Hashing revisted In-Reply-To: Message-ID: On Tue, 30 Apr 2002, Richard B. Kreckel wrote: > suggesting an improvement of a factor 260 or 270. At the same time, > the timings got only very marginally better, indicating that there is > nothing to be gained by better hash functions, even perfect > collision-free ones (if they would exist), since deep traversals caused by > equal objects outweight deep traversals caused by hash collisions of > different objects. Did you also measure the ratio between comparisons which turn out to be equal to those turning out to be different? But there will still a business case for better hash functions, if you plan to revive the hash-based expairseq-combining. Alex -- Alexander Frink E-Mail: Alexander.Frink at Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-3923391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany From kreckel at thep.physik.uni-mainz.de Thu May 2 17:11:23 2002 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Thu, 2 May 2002 17:11:23 +0200 (CEST) Subject: Fibonacci Hashing revisted In-Reply-To: Message-ID: On Thu, 2 May 2002, Alexander Frink wrote: > On Tue, 30 Apr 2002, Richard B. Kreckel wrote: > > suggesting an improvement of a factor 260 or 270. At the same time, > > the timings got only very marginally better, indicating that there is > > nothing to be gained by better hash functions, even perfect > > collision-free ones (if they would exist), since deep traversals caused by > > equal objects outweight deep traversals caused by hash collisions of > > different objects. > > Did you also measure the ratio between comparisons which turn out > to be equal to those turning out to be different? Why does this matter? I mean, sure, the comparisons which turn out to be equal are the ones that dominate. They are about three orders of magnitude more frequent than the ones that turn out to be different. This is why enhancements to the hashing are not going to help any more. Cheers -richy. -- Richard B. Kreckel From chrisd at sci.kun.nl Thu May 23 12:45:56 2002 From: chrisd at sci.kun.nl (Chris Dams) Date: Thu, 23 May 2002 12:45:56 +0200 (MEST) Subject: can't subs(lst) on a function Message-ID: Hello, I use GiNaC version 1.0.8 (and gcc version 3.0.1) and found out that the only subs-method that can be used with an exprseq is ex subs(const lst & ls, const lst & lr, bool no_pattern = false) The consequence seems to be that (since a function is derived from a exprseq) that I am allowed to write ex e=sin(x*y+x); cout << e.subs(lst(x==-2,y==4)) << endl; which gives the expected result sin(-10), but I am not allowed to write cout << sin(x*y+x).subs(lst(x==-2,y==4)) << endl; because this causes the error: test.C: In function `int main(int, char**)': test.C:9: no matching function for call to `GiNaC::function::subs(GiNaC::lst) const' /usr/local/include/ginac/exprseq.h:84: candidates are: virtual GiNaC::ex GiNaC::exprseq::subs(const GiNaC::lst&, const GiNaC::lst&, bool = false) const I think another subs-method should be added to exprseq so that this error no longer occurs. Greetings, Chris Dams From hugo.leclerc at etudes.univ-fcomte.fr Sat May 18 19:18:10 2002 From: hugo.leclerc at etudes.univ-fcomte.fr (Hugo LECLERC) Date: Sat, 18 May 2002 19:18:10 +0200 Subject: can't subs(lst) on a function In-Reply-To: References: Message-ID: <200205181918.10399.hugo.leclerc@etudes.univ-fcomte.fr> Hello Chris, The solution is to cast the function to a ginac ex : cout << ex(sin(x*y+x)).subs(lst(x==-2,y==4)) << endl; Greetings. From chrisd at sci.kun.nl Thu May 23 23:34:35 2002 From: chrisd at sci.kun.nl (Chris Dams) Date: Thu, 23 May 2002 23:34:35 +0200 (MEST) Subject: can't subs(lst) on a function Message-ID: Hello Hugo, I know casting to an ex is a solution (would not call it ``the solution'' though: ``the solution'' is editing the source files and recompiling GiNaC). It is not natural that you can use the method subs(lst) to an expression but not to a function. So, unless it turns out to be some weird compiler error in my gcc-version, I would rather see this fixed in future GiNaC versions than condemning future generations to having to use this cast. Greetings, Chris