Compiling on AMD64/openSUSE 10.3
For the INSTALL file, you may want to update the compile time(s): make 596.33s user 22.68s system 99% cpu 10:22.74 total make check 465.83s user 11.77s system 99% cpu 8:01.45 total this is on model name : AMD Athlon(tm) 64 Processor 3400+ cpu MHz : 2200.000 cache size : 512 KB (Athlon/800MHz is a bit old-ish by now) Add the AMD64 architecture here: ------------------------------------ Known to work with: - Linux on x86, Alpha and Sparc using GCC 3.x and 4.0. ------------------------------------ after make install ginsh fails with ginsh: error while loading shared libraries: \ libginac-1.4.so.0: cannot open shared object file: No such file or directory running ldconfig fixes the problem. So mention that in the INSTALL file: ------------------------------------ To install from a source .tar.bz2 distribution: $ ./configure $ make [become root if necessary] # make install # ldconfig <--= line added ------------------------------------ ... or trigger ldconfig with the install target cheers, jj
Hello! On Mon, Feb 04, 2008 at 09:10:24AM +1100, Joerg Arndt wrote:
For the INSTALL file, you may want to update the compile time(s):
make 596.33s user 22.68s system 99% cpu 10:22.74 total make check 465.83s user 11.77s system 99% cpu 8:01.45 total
this is on model name : AMD Athlon(tm) 64 Processor 3400+ cpu MHz : 2200.000 cache size : 512 KB
What about the compiler version and options?
(Athlon/800MHz is a bit old-ish by now)
Sadly, the compile time on a modern system seems to be (almost) the same.
Add the AMD64 architecture here: ------------------------------------ Known to work with: - Linux on x86, Alpha and Sparc using GCC 3.x and 4.0. ------------------------------------
I admit the platforms list is neither accurate nor up to date, but AMD64 \in x86.
after make install ginsh fails with ginsh: error while loading shared libraries: \ libginac-1.4.so.0: cannot open shared object file: No such file or directory
running ldconfig fixes the problem.
libtool used to run ldconfig when installing a (shared) library, so I wonder how do you get into this state. Best regards, Alexei -- All science is either physics or stamp collecting.
Hi, I think I have found a bug in lsolve. I have tested the following program under ginac 1.3.9 and 1.4.1, and I obtain an incorrect result in both cases: the linear system contains the equation lambda28=0, but I obtain lambda28==lambda28 in the solution. code: #include "ginac/ginac.h" #include <iostream> using namespace std; using namespace GiNaC; int main() { symbol lambda1("lambda1"),lambda2("lambda2"),lambda3("lambda3"),lambda4("lambda4"),lambda5("lambda5"), lambda6("lambda6"),lambda7("lambda7"), lambda8("lambda8"),lambda9("lambda9"),lambda10("lambda10"),lambda11("lambda11"),lambda12("lambda12"),lambda13("lambda13"), lambda14("lambda14"), lambda15("lambda15"),lambda16("lambda16"),lambda17("lambda17"),lambda18("lambda18"),lambda19("lambda19"),lambda20("lambda20"),lambda21("lambda21"), lambda22("lambda22"),lambda23("lambda23"),lambda24("lambda24"),lambda25("lambda25"),lambda26("lambda26"), lambda27("lambda27"),lambda28("lambda28"),lambda29("lambda29"); ex sqrt3=sqrt(ex(3)); lst syms; syms=lambda1,lambda2,lambda3,lambda4,lambda5,lambda6,lambda7,lambda8,lambda9,lambda10,lambda11, lambda12,lambda13,lambda14,lambda15,lambda16,lambda17,lambda18,lambda19,lambda20,lambda21,lambda22,lambda23,lambda24, lambda25,lambda26,lambda27,lambda28,lambda29; lst eqns; eqns.append(-lambda20+lambda24-lambda2-lambda25*sqrt3==0); eqns.append(-sqrt3*lambda23-lambda22==0); eqns.append(lambda15-lambda9-sqrt3*lambda7-lambda6==0); eqns.append(lambda23+lambda1-2*lambda21==0); eqns.append(lambda15-lambda9-lambda6==0); eqns.append(-2*lambda28==0); eqns.append(sqrt3*lambda12-lambda13==0); eqns.append(lambda26-sqrt3*lambda27+lambda19+lambda8==0); eqns.append(-lambda28==0); eqns.append(-sqrt3*lambda19+lambda27+sqrt3*lambda8==0); eqns.append(sqrt3*lambda17+lambda18==0); eqns.append(lambda4-2*lambda17-lambda11==0); eqns.append(lambda20+2*lambda24+lambda2==0); eqns.append(-lambda16+lambda3+2*lambda12==0); eqns.append(-sqrt3*lambda22-lambda23-lambda1-lambda21==0); eqns.append(lambda9*sqrt3-lambda7+lambda15*sqrt3==0); eqns.append(-sqrt3*lambda3-lambda13==0); eqns.append(-lambda15+lambda9-sqrt3*lambda7+lambda6==0); eqns.append(lambda25-sqrt3*lambda24==0); eqns.append(-lambda5-lambda10-lambda14==0); eqns.append(2*lambda20+lambda24-lambda2==0); cout<<GiNaC::lsolve(eqns,syms)<<endl; } output: {lambda1==lambda23,lambda2==-1/3*sqrt(3)*lambda25,lambda3==-lambda16,lambda4==-2/3*sqrt(3)*lambda18+lambda11,lambda5==-lambda14-lambda10,lambda6==2*lambda15,lambda7==0,lambda8==-1/2*lambda26+1/3*sqrt(3)*lambda27,lambda9==-lambda15,lambda10==lambda10,lambda11==lambda11,lambda12==lambda16,lambda13==sqrt(3)*lambda16,lambda14==lambda14,lambda15==lambda15,lambda16==lambda16,lambda17==-1/3*sqrt(3)*lambda18,lambda18==lambda18,lambda19==-1/6*(sqrt(3)*lambda26-4*lambda27)*sqrt(3),lambda20==-1/3*sqrt(3)*lambda25,lambda21==lambda23,lambda22==-lambda23*sqrt(3),lambda23==lambda23,lambda24==1/3*sqrt(3)*lambda25,lambda25==lambda25,lambda26==lambda26,lambda27==lambda27,lambda28==lambda28,lambda29==lambda29} I suspect the problem is the sqrt(3), since replacing it with an integer the result appears to be correct. Or am I doing something wrong? Diego
Hello! On Fri, Feb 15, 2008 at 03:53:48PM +0100, Diego Conti wrote:
I think I have found a bug in lsolve. I have tested the following program under ginac 1.3.9 and 1.4.1, and I obtain an incorrect result in both cases: the linear system contains the equation lambda28=0, but I obtain lambda28==lambda28 in the solution.
[snipped]
I suspect the problem is the sqrt(3),
Yes, that's the problem. The coefficients are assumed to be either rational expressions or numbers. And sqrt(3) is neither a rational expression nor a number.
since replacing it with an integer the result appears to be correct.
Replacing it with symbol("a") gives correct result too. Best regards, Alexei -- All science is either physics or stamp collecting.
Hi! Diego Conti wrote:
I think I have found a bug in lsolve. I have tested the following program under ginac 1.3.9 and 1.4.1, and I obtain an incorrect result in both cases: the linear system contains the equation lambda28=0, but I obtain lambda28==lambda28 in the solution.
code:
#include "ginac/ginac.h" #include <iostream> using namespace std; using namespace GiNaC;
int main() { symbol lambda1("lambda1"),lambda2("lambda2"),lambda3("lambda3"),lambda4("lambda4"),lambda5("lambda5"), lambda6("lambda6"),lambda7("lambda7"), lambda8("lambda8"),lambda9("lambda9"),lambda10("lambda10"),lambda11("lambda11"),lambda12("lambda12"),lambda13("lambda13"), lambda14("lambda14"), lambda15("lambda15"),lambda16("lambda16"),lambda17("lambda17"),lambda18("lambda18"),lambda19("lambda19"),lambda20("lambda20"),lambda21("lambda21"), lambda22("lambda22"),lambda23("lambda23"),lambda24("lambda24"),lambda25("lambda25"),lambda26("lambda26"), lambda27("lambda27"),lambda28("lambda28"),lambda29("lambda29"); ex sqrt3=sqrt(ex(3)); lst syms; syms=lambda1,lambda2,lambda3,lambda4,lambda5,lambda6,lambda7,lambda8,lambda9,lambda10,lambda11, lambda12,lambda13,lambda14,lambda15,lambda16,lambda17,lambda18,lambda19,lambda20,lambda21,lambda22,lambda23,lambda24, lambda25,lambda26,lambda27,lambda28,lambda29;
lst eqns; eqns.append(-lambda20+lambda24-lambda2-lambda25*sqrt3==0); eqns.append(-sqrt3*lambda23-lambda22==0); eqns.append(lambda15-lambda9-sqrt3*lambda7-lambda6==0); eqns.append(lambda23+lambda1-2*lambda21==0); eqns.append(lambda15-lambda9-lambda6==0); eqns.append(-2*lambda28==0); eqns.append(sqrt3*lambda12-lambda13==0); eqns.append(lambda26-sqrt3*lambda27+lambda19+lambda8==0); eqns.append(-lambda28==0); eqns.append(-sqrt3*lambda19+lambda27+sqrt3*lambda8==0); eqns.append(sqrt3*lambda17+lambda18==0); eqns.append(lambda4-2*lambda17-lambda11==0); eqns.append(lambda20+2*lambda24+lambda2==0); eqns.append(-lambda16+lambda3+2*lambda12==0); eqns.append(-sqrt3*lambda22-lambda23-lambda1-lambda21==0); eqns.append(lambda9*sqrt3-lambda7+lambda15*sqrt3==0); eqns.append(-sqrt3*lambda3-lambda13==0); eqns.append(-lambda15+lambda9-sqrt3*lambda7+lambda6==0); eqns.append(lambda25-sqrt3*lambda24==0); eqns.append(-lambda5-lambda10-lambda14==0); eqns.append(2*lambda20+lambda24-lambda2==0); cout<<GiNaC::lsolve(eqns,syms)<<endl; }
output: {lambda1==lambda23,lambda2==-1/3*sqrt(3)*lambda25,lambda3==-lambda16,lambda4==-2/3*sqrt(3)*lambda18+lambda11,lambda5==-lambda14-lambda10,lambda6==2*lambda15,lambda7==0,lambda8==-1/2*lambda26+1/3*sqrt(3)*lambda27,lambda9==-lambda15,lambda10==lambda10,lambda11==lambda11,lambda12==lambda16,lambda13==sqrt(3)*lambda16,lambda14==lambda14,lambda15==lambda15,lambda16==lambda16,lambda17==-1/3*sqrt(3)*lambda18,lambda18==lambda18,lambda19==-1/6*(sqrt(3)*lambda26-4*lambda27)*sqrt(3),lambda20==-1/3*sqrt(3)*lambda25,lambda21==lambda23,lambda22==-lambda23*sqrt(3),lambda23==lambda23,lambda24==1/3*sqrt(3)*lambda25,lambda25==lambda25,lambda26==lambda26,lambda27==lambda27,lambda28==lambda28,lambda29==lambda29}
I suspect the problem is the sqrt(3), since replacing it with an integer the result appears to be correct. Or am I doing something wrong?
An interesting problem. It is due to the division free elimination algorithm replacing sqrt(3) with a temporary symbol s (see call of .to_rational(srl).numer_denom() in function matrix::fraction_free_elimination(bool), file matrix.cpp). Later on, that symbol appears in expanded polynomials like s^2-3. It's not immediately apparent for the program that this is zero. The program does this replacement because the divide function expects polynomials over the rationals as numerator and denominator. Calling lsolve(eqns,syms,solve_algo::divfree) or lsolve(eqns,syms,solve_algo::gauss) will switch to alternative algorithms which are by construction not susceptible to this kind of problem. They may, however, turn out to be too slow for more densely populated systems of equations. You should give them a try. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, thanks for your reply.
I think I have found a bug in lsolve. I have tested the following program under ginac 1.3.9 and 1.4.1, and I obtain an incorrect result in both cases: the linear system contains the equation lambda28=0, but I obtain lambda28==lambda28 in the solution.
<snip> An interesting problem. It is due to the division free elimination algorithm replacing sqrt(3) with a temporary symbol s (see call of .to_rational(srl).numer_denom() in function matrix::fraction_free_elimination(bool), file matrix.cpp). Later on, that symbol appears in expanded polynomials like s^2-3. It's not immediately apparent for the program that this is zero. The program does this replacement because the divide function expects polynomials over the rationals as numerator and denominator.
Calling lsolve(eqns,syms,solve_algo::divfree) or lsolve(eqns,syms,solve_algo::gauss) will switch to alternative algorithms which are by construction not susceptible to this kind of problem. They may, however, turn out to be too slow for more densely populated systems of equations. You should give them a try.
Cheers -richy.
OK, now I understand. The alternative algorithms work fine. But then, wouldn't it be natural to reorganize the code so that power::to_rational throws an exception when it is called as a result of the call to to_rational in fraction_free_elimination? Then one could have matrix::solve catch the exception and switch automatically to a different algorithm, ensuring the correct result is returned. Thanks again Diego
Hello! On Mon, Feb 18, 2008 at 02:32:45PM +0100, Diego Conti wrote:
But then, wouldn't it be natural to reorganize the code so that power::to_rational throws an exception when it is called as a result of the call to to_rational in fraction_free_elimination?
This approach sounds a bit wrong (to put it very mildly). First of all, power::to_rational does its work just fine, there's no need to change it. It's fraction_free_elimination which is buggy and needs to be fixed. Secondly, this would reject many valid expressions, i.e. #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(int argc, char** argv) { symbol a("A"),b("B"),c("C"),d("D"),x("X"); lst syms; syms = a,b; lst eqns; eqns = sqrt(1-pow(x,2))*a + x*b == c, -x*a + sqrt(1-pow(x,2))*b == d; ex sol = lsolve(eqns, syms, solve_algo::bareiss); cout << "System: " << eqns << endl << "Solution: " << sol << endl; return 0; }
Then one could have matrix::solve catch the exception and switch automatically to a different algorithm,
The problem is not that simple (see the example above). Best regards, Alexei -- All science is either physics or stamp collecting.
Hi! Alexei Sheplyakov wrote:
On Mon, Feb 18, 2008 at 02:32:45PM +0100, Diego Conti wrote:
But then, wouldn't it be natural to reorganize the code so that power::to_rational throws an exception when it is called as a result of the call to to_rational in fraction_free_elimination?
This approach sounds a bit wrong (to put it very mildly).
One of the reasons why this fix is bad is because it would only be acceptable for the case solve_algo::automatic. But there are several other ways of calling fraction_free_elimination more directly.
First of all, power::to_rational does its work just fine, there's no need to change it. It's fraction_free_elimination which is buggy and needs to be fixed.
Secondly, this would reject many valid expressions, i.e.
#include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC;
int main(int argc, char** argv) { symbol a("A"),b("B"),c("C"),d("D"),x("X"); lst syms; syms = a,b; lst eqns; eqns = sqrt(1-pow(x,2))*a + x*b == c, -x*a + sqrt(1-pow(x,2))*b == d; ex sol = lsolve(eqns, syms, solve_algo::bareiss); cout << "System: " << eqns << endl << "Solution: " << sol << endl; return 0; }
Right. This is one way of calling fraction_free_elimination more directly.
Then one could have matrix::solve catch the exception and switch automatically to a different algorithm,
The problem is not that simple (see the example above).
Clearly, calling .expand() on the numerator and denominator in the elimination step is the culprit. It fails to simplify s^2-3 to zero. On the other hand, I believe one must not try to be more clever in the elimination step proper: it could lead to a situation where m[k-1](k-1,k-1) fails to divide m[k+1](r,c) because the latter has been simplified too much. And that division to work without having to embark on a GCD computation is the crucial point about Bareiss' fraction free elimination. I am having a guts feeling that the problem is only that a zero pivot element like s^2-3 with s==sqrt(3) is being chosen. This is bad in its own right because a pivot should be non-zero by definition. If this is correct, the attached patch would solve all these problems without incurring much overhead. Maybe it can be written more elegantly? It passes our testsuite without noticeable benchmark penalties and it solves Diego's problem. But I haven't done much more thinking and testing. Diego, can you please try if this works as expected for whatever you are doing there? Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, thanks for the patch.
But then, wouldn't it be natural to reorganize the code so that power::to_rational throws an exception when it is called as a result of the call to to_rational in fraction_free_elimination?
This approach sounds a bit wrong (to put it very mildly).
One of the reasons why this fix is bad is because it would only be acceptable for the case solve_algo::automatic. But there are several other ways of calling fraction_free_elimination more directly.
I see.
<snip> It passes our testsuite without noticeable benchmark penalties and it solves Diego's problem. But I haven't done much more thinking and testing. Diego, can you please try if this works as expected for whatever you are doing there?
Yes, as far as I can tell your patch corrects the problem. The code I sent earlier is part of a list of computations I have been doing on the group SU(3); the sqrt(3) appears in the structure constants. I have repeated the calculations after applying your patch, and I have obtained consistent results. Best regards, Diego
Hi! Diego Conti wrote:
Yes, as far as I can tell your patch corrects the problem. The code I sent earlier is part of a list of computations I have been doing on the group SU(3); the sqrt(3) appears in the structure constants. I have repeated the calculations after applying your patch, and I have obtained consistent results.
I've just committed a slightly enhanced version of that patch. I should point out that it doesn't give you any guarantee that systems of equations containing roots as coefficients can be solved adequately by any of the elimination algorithms. Consider this: #include "ginac/ginac.h" #include <iostream> using namespace std; using namespace GiNaC; int main() { symbol a("a"), b("b"); lst eqns, syms; eqns.append(8*b+sqrt(ex(24))*a==0); eqns.append(sqrt(ex(3))*a+b*sqrt(ex(8))==1); syms = a, b; cout << lsolve(eqns,syms,solve_algo::gauss) << endl; cout << lsolve(eqns,syms,solve_algo::divfree) << endl; cout << lsolve(eqns,syms,solve_algo::bareiss) << endl; } All three elimination algorithms will construct solutions of a and b that are, in fact, divergent. This is all due to the difficulty of deciding whether an expression is zero or not. In the example above, GiNaC doesn't recognize that sqrt(24)*sqrt(3)-3*sqrt(8) is just a blown-up zero. If GiNaC were able to this, it wouldn't take long until we hit the next barrier: Richardson's theorem. However, if sqrt(3) is the only non-numeric term showing up, as I assume is the case in Diego's SU(3) computations, all goes well. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (4)
-
Alexei Sheplyakov
-
Diego Conti
-
Joerg Arndt
-
Richard B. Kreckel