- GiNaC-list - ginac.de

What is the status of xloops?
by Vladyslav Shtabovenko 05 Sep '14

05 Sep '14

Dear all, I know that this is the GiNaC mailing list, but since historically GiNaC was very closely connected to xloops, I think that asking this here is appropriate. Judging from the xloops page (http://wwwthep.physik.uni-mainz.de/~xloops/) the project looks pretty abandoned. The links to the CVS tree and to the mailing list archive give you 404 http://down.physik.uni-mainz.de/cgi-bin/viewcvs.cgi/xloops/?cvsroot=ThEP http://thep.physik.uni-mainz.de/pipermail/xloops-list/ http://thep.physik.uni-mainz.de/pipermail/xloops-devel/ http://thep.physik.uni-mainz.de/pipermail/xloops-cvs/ The most recent version seems to be xloops 0.1.3 from 2002 So, is the xloops library still maintained by someone and is there are working repository to checkout the most recent snapshot somewhere? Cheers, Vladyslav

1 0

dirac_spinor?
by Vladyslav Shtabovenko 05 Sep '14

05 Sep '14

Hi, I started looking at GiNaC only recenty, so forgive me if my question is too naive. I'm wondering if it is possible to define Dirac spinors in the context of Clifford objects, such that they can appear in chains of dirac_gammas. The only property I need at the moment is that dirac_spinor and dirac_gamma do not commute, such that for example dirac_gamma(j)*dirac_gamma(j.togglevariance)*dirac_spinor(p1)*dirac_gamma(i)*dirac_gamma(i.togglevariance)*dirac_spinor(p2)*dirac_gamma(j) will get simplified to 16 dirac_spinor(p1)*dirac_spinor(p2)*dirac_gamma(j) Cheers, Vladyslav

2 4

finite fields?
by Ruben Zilibowitz 26 Aug '14

26 Aug '14

Is there any support in GiNaC for factoring polynomials over finite fields or rings? Regards, Ruben

1 0

subs on matrices
by Ruben Zilibowitz 25 Jul '14

25 Jul '14

Is there any reason not to include a subs function on the matrix class? Regards, Ruben

1 0

ex::is_polynomial function
by Ruben Zilibowitz 24 Jul '14

24 Jul '14

The following code is not working as I would expect. The expression ‘m + sqrt(d)’ is surely a polynomial in m. However GiNaC thinks it is not. { symbol m("m"), d("d"); ex e = m + sqrt(d); cout << e << " is polynomial in m " << e.is_polynomial(m) << endl; } Regards, Ruben

2 1

symmetrize function
by Ruben Zilibowitz 22 Jul '14

22 Jul '14

The C++ sample code here http://www.ginac.de/tutorial/Symmetrization.html#Symmetrization is not working for me with the latest GiNaC (version 1.6.2). I get the following error main.cpp:58:27: error: no member named 'symmetrize' in 'GiNaC::indexed' cout << indexed(A, i, j).symmetrize(i,j) << endl; Is the tutorial outdated? Regards, Ruben

2 1

bug in series()
by Mario Prausa 18 Jun '14

18 Jun '14

Hi, there seems to be a bug in the series() implementation. The attached code causes a segfault. As log(-x) doesn't depend on the expansion parameter ep, series() should return log(-x). The bug only occurs, if x is defined as possymbol, so it might have something to do with the branch cut of the logarithm. I reproduced the bug with GiNaC 1.6.2 and the current git version. Regards, Mario

1 0

Re: [GiNaC-list] [PATCH] add configure option to enable deterministic sorting
by Valery Yundin 29 May '14

29 May '14

Hi, On 29 May 2014 07:31, Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> wrote: > I'm terribly sorry, but everything which makes the hash function worse > (slower or produces more collisions) is not acceptable. If you insist on that regardless of how it affects overall performance, it is not a technical problem and cannot be fixed with a patch. In any case, if my previous patches are not acceptable for whatever reasons GiNaC developers might have, I suggest to close this discussion by adding a configure option. So users can decide for themselves if (non-)determinism is worth few per-cent speed difference. Below is the simplest patch one can imagine. By default it keeps things as they are now. If user specifies --enable-determinism then make_hash_seed simply returns 0. Objects with the same calchash() implementation *and* the same contents *but* different types will have a hash collision, which be resolved in base::compare by using typeid_1.before(typeid_2) (on Linux it is a simple strcmp). Since it happens quite rarely (depends on a particular code of course), it is better than always using crc32 as in windows version of your code. In fact it can sometimes be faster than current "fast" hash. Best, Valery

1 0

[PATCH] fix bug/feature causing non-deterministic output
by Valery Yundin 29 May '14

29 May '14

Hi, Please see attached patch which fixes rather peculiar "feature" of GiNaC - non-determinism. One can think of many arguments why non-determinism of CAS is a bad idea. Shortly speaking, it is simply unacceptable. Especially when there is no good reason for it (and I can hardly think of a good reason anyway). At the moment GiNaC relies on OS-assigned memory addresses of type-names to define its term-ordering, which results in different output from the same program. When this bug was brought up in the mailing list (several times) the developers called it a "design decision". Well, it is time to stop the insanity. The attached patch fixes the bug at zero cost to the performance. Here are the results of "/usr/bin/time make check" (second run with pre-warmed caches) unpatched non-deterministic: 132.57 s fixed deterministic: 132.62 s Keep in mind that it wouldn't make GiNaC canonical ordering entirely predictable, since it still depends on the order of symbol declaration and such (btw, fixing that wouldn't be too hard either). But at least for the same program and compiler the result must be identical. PS I added FNV1a hash, one could just keep using crc32 which is already there. It makes no difference since the hash function is now called only once for each type (before it was called for every object). PPS I'm attaching patches against master and release_1-6-2 since I hope that developers recognize it as a bug and update stable releases as well. With best regards, Valery Yundin.

3 5

Re: [GiNaC-list] [PATCH] fix bug/feature causing non-deterministic output
by Valery Yundin 25 May '14

25 May '14

Hi, Updated patch, rev 3. Overloaded gethashseed() in a few classes which I missed before. Also modified gethashseed() to use "fast" hash for derived classes which do not overload it and made it independent of mangling scheme for non-template classes. Removed some debugging output. IMO "fast" hash can be removed entirely and if classes do not overload gethashseed() it will be taken care of by typeid. But since it is relevant only for custom user-defined classes, I don't care much. I kept it because GiNaC developers seem to have sentimental attachment to it. Best, Valery PS patch chunks have only 1 context line, because this list has post limit of 40kB With best regards, Mr. Valery Yundin. On 25 May 2014 18:44, Valery Yundin <yuvalery(a)gmail.com> wrote: > Hi, > > Updated patch, rev 3. > Overloaded gethashseed() in a few classes which I missed before. Also > modified gethashseed() to use "fast" hash for derived classes which do > not overload it and made it independent of mangling scheme for > non-template classes. Removed some debugging output. > > IMO "fast" hash can be removed entirely and if classes do not overload > gethashseed() it will be taken care of by typeid. But since it is > relevant only for custom user-defined classes, I don't care much. I > kept it since GiNaC developers seem to have sentimental attachment to > it. > > Best, > Valery

1 0