Hi everybody,
The issue of the nasty crashes whenever something is thrown internally (as
in .normal(), if the heuristic algorithm failed or in .series() for
functions with poles) came up last week. Finally it is becoming clear
what's happening. series(tgamma(x),x==0,1) crashed reproducibly when
linked dynamically, either in ginsh, ginaccint or elsewhere. Let me
explain what's happening. So I am no longer to blame. :-)
GiNaC 0.6.1 got an updated libtool from FSF (1.3.4 instead of 1.3.3) and
that libtool has changed it's behaviour for linking:
$ libtool --mode=link c++ ...
uses $CC for linking instead of c++, as it used to be. Libtool's
documentation does have something to say about this:
> [...] running the C++ compiler directly may lead to problems related
> with inter-library dependencies.
>
> The conclusion is that libtool is not ready for general use for C++
> libraries.[...]
>
> Furthermore, you'd better find out, at configure time, what are the C++
> Standard libraries that the C++ compiler will link in by default, and
> explicitly list them in the link command line. Hopefully, in the future,
> libtool will be able to do this job by itself.
I am somewhat clueless what those `problems related with inter-library
dependencies' might be (there seems to be a gap in the mailing list
archives). Well, the day before yesterday they have released libtool
1.3.5 but that doesn't change much.
Anyhow, the trouble starts only when you use jurrasic compilers. And
Debian/Slink does precisely this: gcc (used for linking) is 2.7.2.3 while
c++ (used for compiling) is 2.91.60. Makes the solution pretty obvious:
Just exporting CC=egcc prior to configuring solves all problems. Big
deal. Or upgrading to Potato (if they manage to release it some lucky
day).
Happy hacking
-rbk.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Dear ginac-bugs(a)ginac.de,
I tried to install 0.6.0 on my RH6.0 linux system.
I got these errors:
Making install in reference
make[2]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference'
make[3]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference'
make[3]: Nothing to be done for `install-exec-am'.
/bin/sh ../../mkinstalldirs /usr/local/share/doc/GiNaC/reference
/usr/bin/install -c -m 644 ./*.html /usr/local/share/doc/GiNaC/reference/*.html
/usr/bin/install: ./*.html: No such file or directory
make[3]: *** [install-data-local] Error 1
make[3]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/install/GiNaC-0.6.0/doc'
make: *** [install-recursive] Error 1
Also, after `make install' I found that my programs would not
compile because version.h had not been copied to /usr/local/include/ginac.
I had to do this by hand, then my programs would compile.
Also, I have a problem with
cout<<(log(1+2*x)/2).series(x==0,n);
which does not produce its output in ascending order of powers.
Thank you,
Keith
+-------------------------------------------------------------------+
| Dr. Keith M. Briggs, Complexity Research Group, BT Research Labs. |
| Adastral Park admin2 pp5, Martlesham Heath, IP5 3RE, Suffolk, UK |
| Tel. 01473 641 911 Fax. 01473 647 410. Home tel: 01473 625 972 |
| www.bt.com | personal homepage: www.labs.bt.com/people/briggsk2/ |
+-------------------------------------------------------------------+
Good morning everybody!
We loudly present a new release of the GiNaC framework for symbolic
computation within your favorite programming language. Please hurry
up and grab your copy from <http://www.ginac.de/Download.html>. Make
sure you read the file NEWS to see that we did an awful job trying to
break your existing code! Also included in make-target check are some
tests invented by R. Lewis and M. Wester, carefully crafted by skilled
coders to successfully overheat your CPU and bring down your machine
within minutes! Interfacing GiNaC with Cint is also progressing
nicely and if nobody angers the gods of computing the world will soon
see a fully integrated symbolic C++ interpreter!
\begin{SalespersonSpeak}
INCREASE PRODUCTIVITY WITH A PROVEN TOOL
GiNaC 0.6 provides the right set of tools so that you can be more
productive, more effective, and solve more problems. Use GiNaC 0.6 in
all phases of your technical projects. Instead of relying on several
separate and expensive software packages, GiNaC 0.6 provides a single
computing environment for defining and setting up models, analyzing
the results both numerically and graphically, and creating technical
reports for publication, or e-publication.
TRUST THE INNOVATION LEADERS
Countless users all over the world have chosen GiNaC's technology as
their preferred platform for solving, analyzing, and designing models
in their computational projects. Our customers include virtually all
major universities and research institutions, and countless
corporations. These customers understand that the complexities of
modern analytical computation demand the highest levels of
computational excellence. With GiNaC 0.6, we continue to earn the
trust of customers by delivering new and robust technology. GiNaC 0.6
is the result of over a thousand person-days of advanced research and
development. With ignorant quality assurance practices and casual use
of customer feedback through nonexistent beta programs, you can have
confidence that the results from GiNaC 0.6 will be reliable and
accurate.
\end{SalespersonSpeak}
We hope to see you again soon when we release GiNaC 0.7 and rip our
announcement from another major competitor in the field. :-)
Happy hacking
-richy.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Hi,
Since GMP3 has been released we are now in the process to adapt CLN to
make use of that new library. While GMP3 seems to be much faster than
GMP2 (largely because of the support of common new processors like PPro
and also due to some improved algorithms with better asymptotic behaviour)
and CLN does see a large chunk of this improvement I have the impression
that most common symbolic computations don't actually benefit too much
from this.
Just because I was curious, I have made a preliminary statically linked
GiNaC suite of timings, once with the old CLN using GMP2 and once with a
CLN using the new GMP3. The results are interesting in a sense that they
don't show much improvement. I have marked the tests which make heavy use
of the class GiNaC::numeric (and thus are expected to run faster now) with
an asterisk, the others with a dash:
timing commutative expansion and substitution.... passed -
size: 25 50 100 200
w/GMP2: time/s: 0.03 0.16 0.67 2.99
w/GMP3: time/s: 0.04 0.15 0.66 3.01
timing Laurent series expansion of Gamma function.... passed -
order: 10 15 20 25
w/GMP2: time/s: 0.130 0.709 3.26 12.65
w/GMP3: time/s: 0.119 0.719 3.209 12.48
timing determinant of univariate symbolic Vandermonde matrices.... passed -
dim: 4x4 6x6 8x8 10x10
w/GMP2: time/s: 0.002 0.02 0.299 2.91
w/GMP3: time/s: 0.003 0.02 0.299 2.88
timing determinant of polyvariate symbolic Toeplitz matrices.... passed -
dim: 5x5 6x6 7x7 8x8
w/GMP2: time/s: 0.035 0.190 0.959 4.15
w/GMP3: time/s: 0.036 0.179 0.930 4.08
w/GMP2: w/GMP3:
timing Lewis-Wester test A (divide factorials). 0.35 0.35 *
timing Lewis-Wester test B (sum of rational numbers). 0.027 0.027 *
timing Lewis-Wester test C (gcd of big integers). 0.45 0.45 *
timing Lewis-Wester test D (sum of rational fcns). 0.00085 0.00086 -
timing Lewis-Wester test E (sum of rational fcns). 0.00082 0.00081 -
timing Lewis-Wester test F (gcd of 2-var polys). 0.095 0.095 ?
timing Lewis-Wester test G (gcd of 3-var polys). 3.35 3.21 ?
timing Lewis-Wester test H (det of 80x80 Hilbert). 10.88 10.30 *
timing Lewis-Wester test I (invert rank 40 Hilbert). 4.10 3.97 *
timing Lewis-Wester test J (check rank 40 Hilbert). 1.90 1.86 *
timing Lewis-Wester test K (invert rank 70 Hilbert). 26.34 25.29 *
timing Lewis-Wester test L (check rank 70 Hilbert). 10.96 10.70 *
timing Lewis-Wester test M1 (26x26 sparse, det). 0.46 0.46 -
timing Lewis-Wester test O1 (three 15x15 dets, average)... 49.51 49.31 -
timing Lewis-Wester test P (det of sparse rank 101). 5.49 5.49 *
timing Lewis-Wester test P' (det of less sparse rank 101). 10.02 9.69 *
timing Lewis-Wester test Q (charpoly(P)). 145.71 144.10 *
timing Lewis-Wester test Q' (charpoly(P')). 293.92 289.26 *
It's embarassing that the four first tests show a common pattern: the new
library runs slightly faster with large problem sizes and slower with
small once. It's perfectly reproducible. Can anybody suggest a possible
explanation for this?
Cheers
-richy.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>