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/>
Hello all,
For those interested in factorization over finite fields, Victor Shoup's
library NTL (which is used as a module for some "world records"
established by MuPAD (if you can call it "established" (MuPAD as a mere
frontend))) has just been released by the author under the GPL license.
Of course, it is still a long way from there to factorization of
multivariate polynomials over ZZ but it may be start.
Regards
-rbk.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Dear ginac-bugs(a)ginac.de,
Installing GiNaC-0.5.4 on my redhat 6.0 system fails at the doc step:
make[3]: Entering directory `/home/kbriggs/GiNaC-0.5.4/doc/tutorial'
Running /usr/X11R6/bin/fig2dev -L eps -m 0.9 classhierarchy.fig classhierarchy.eps...
Unknown graphics language eps
Known languages are:
acad box epic eepic eepicemu gif ibmgl jpeg latex mf pcx pic pictex png ppm ps pstex pstex_t textyl tiff tk tpic xbm xpm
I upgraded my transfig package to the latest from redhat 6.1
(Release 3.2 Patchlevel 1), but it has the same problem.
Actually, changing the command to
fig2dev -L ps -m 0.9 classhierarchy.fig classhierarchy.eps
gives a perfectly good tutorial.ps.
Maybe the configure script should check whether the fig2dev version
installed knows about eps?
Best wishes,
Keith
--
+-------------------------------------------------------------------+
| Dr. Keith M. Briggs, Complexity Research Group, BT Research Labs. |
| Snail mail: Adastral Park adm2 pp5, Martlesham Heath, IP5 3RE, UK |
| Tel. 01473 641 911, Fax. 01473 647 410. Home: 10 Saddler's Place, |
| Martlesham Heath, Suffolk IP5 3SS. Home telephone: 01473 625 972 |
| NEW! personal homepage: http://www.labs.bt.com/people/briggsk2/ |
+-------------------------------------------------------------------+
Since people here have been pondering about this issue lately: the design
document <http://www.sgi.com/Technology/STL/thread_safety.html> applies to
GCC's templates as well. IIUC this looks rather sound, the worst thing
thus being our refcounting. How do I do a portable spin-lock?
Regards
-rbk.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Hi folks,
I have just checked with Martin v. Löwis about that issue. Martin is
quite C-standard-literal. The question arouse how to call the (already
present) Gamma function in GiNaC once and for all. The standard ISO/IEC
9899:1999, frequently dubbed as C99, states:
> 7.12.8.3 The lgamma functions
> Synopsis
> #include <math.h>
> double lgamma(double x);
> float lgammaf(float x);
> long double lgammal(long double x);
>
> Description
>
> The lgamma functions compute the natural logarithm of the absolute
> value of gamma of x: log-e | G(x) |. A range error occurs if x is too
> large or if x is a negative.
>
> Returns
>
> The lgamma functions return the value of the natural logarithm of the
> absolute value of gamma of x.
>
> 7.12.8.4 The tgamma functions
>
> Synopsis
> #include <math.h>
> double tgamma(double x);
> float tgammaf(float x);
> long double tgammal(long double x);
>
> Description
>
> The tgamma functions compute the gamma function of x: G(x). A domain
> error occurs if x is a negative integer or zero. A range error may
> occur if the magnitude of x is too large or too small.
>
> Returns
>
> The tgamma functions return the gamma function value.
The next revision of ISO/IEC 14882:1998 (the C++ standard) will follow
this definition from the C standard. Since it is kind of a policy not to
work against the language C++ I vote for forgetting about esthetic
qualms and adopting this behaviour and call it ex tgamma(ex) in GiNaC
0.x.y | x>5. A function ex lgamma(ex) may be introduced as well to make
the distinction clear.
Any serious objections?
-richy.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
...means "Just another Release of GiNaC". Version 0.5.4 has just been
uploaded to the usual places. See the file NEWS to learn about what has
changed.
Enjoy!
-rbk.
PS: No, I didn't forget to tag...
PPS: ...and no, config.h.in is not empty. ;-)
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
...don't commute. But there is more:
squark:~$ ginsh
ginsh - GiNaC Interactive Shell (GiNaC V0.5.3)
__, _______ Copyright (C) 1999-2000 Johannes Gutenberg University Mainz,
(__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY.
._) i N a C | You are welcome to redistribute it under certain conditions;
<-------------' see the file COPYING for details.
Type ?? for a list of help topics.
> series(gamma(x),x,0,2);
-EulerGamma+Order(x^2)+(1/12*Pi^2+1/2*EulerGamma^2)*x+x^(-1)
> collect(",x);
-EulerGamma+Order(x^2)+(1/12*Pi^2+1/2*EulerGamma^2)*x+x^(-1)
> evalf(");
-0.5772156649015328606L0+(0.98905599532797255544L0)*x+Order(x^(2.0L0))+x^(-1.0L0)
> quit;
squark:~$ ginsh
ginsh - GiNaC Interactive Shell (GiNaC V0.5.3)
__, _______ Copyright (C) 1999-2000 Johannes Gutenberg University Mainz,
(__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY.
._) i N a C | You are welcome to redistribute it under certain conditions;
<-------------' see the file COPYING for details.
Type ?? for a list of help topics.
> series(gamma(x),x,0,2);
-EulerGamma+Order(x^2)+(1/12*Pi^2+1/2*EulerGamma^2)*x+x^(-1)
> evalf(");
-0.5772156649015328606L0+(0.98905599532797255544L0)*x+Order(x^(2.0L0))+x^(-1.0L0)
> collect(",x);
Not a 32-bit integer: -9223372028264841217
squark:~$
In any case, exponents should remain integer and even rational.
Cheers
-rbk.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
You should have a link from the main page stating the license of your
software. I could not find it.
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
i.e. on <ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/>. There has been a
bug in the last version where .normal() was returning wrong results for
certain rational functions like 1/(5-4*a)*(-5-2*a-(3+2*a)*(2-5*a)/(-2+a))
which is now fixed. Also, this version features an improved and more
flexible scheme for registering functions which makes extensions easier
and also allows writing remembering functions in a clean way. See
<http://www.ginac.de/reference/class_remember_table.html>. GiNaC-cint is
making slow progress---we have it running with the current cint 5.14.31
now.
Sex and drugs and Unix
-rbk.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>