From kreckel at thep.physik.uni-mainz.de  Thu Jan  1 19:27:18 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Thu, 1 Jan 2004 19:27:18 +0100 (CET)
Subject: CLN 1.1.6
Message-ID: <Pine.LNX.4.33.0401011918490.28438-100000@higgs.physik.uni-mainz.de>

Happy new year to everybody!

CLN release 1.1.6 is sitting at the usual place (*) and will soon
propagate to the other two mirrors.  This release breaks binary
compatiblity in the polynomial sector, so its soname had to be bumped.

It contains fixes to make it work with the prereleases of GCC 3.4.0.
Hopefully, it will still work when that comes out, but the last two months
were quite calm and give reason for optimism.

If you are not using CLN's polynomials (and GiNaC isn't doing that
internally) and you aren't intersted in GCC 3.4.0, then there is no reason
for you to upgrade.

Also, it now compiles on Mac OS X, but rumour goes it doesn't link on that
platform.  Since I don't have access to suitable machines that situation
won't change until some Mac afficcionado out there sends in some patches.
</Hint>.

Regards
    -richy.

(*) <ftp://ftpthep.physik-uni-mainz.de/pub/gnu/cln-1.1.6.tar.bz2>
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From chrisd at sci.kun.nl  Mon Jan  5 18:59:44 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Mon, 5 Jan 2004 17:59:44 +0000 (UTC)
Subject: patch for symbol.
Message-ID: <Pine.LNX.4.44.0401051746590.16216-200000@gamow.sci.kun.nl>


Hi!

May every GiNaC user and developer have a good 2004.

Here's a patch from GiNaC's RSI-prevention department. Reason for the
patch: creating a real symbol is such a common operation that it should be
as simple as possible.

regards,
Chris
-------------- next part --------------
Index: symbol.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/symbol.cpp,v
retrieving revision 1.53
diff -r1.53 symbol.cpp
317a318,327
> //////////
> // utility functions
> //////////
> 
> /** Utility function to make a real symbol. */
> ex real_symbol(const std::string& name)
> {
>    return (new symbol(name, symbol_options::real))->setflag(status_flags::dynallocated);
> }
> 
Index: symbol.h
===================================================================
RCS file: /home/cvs/GiNaC/ginac/symbol.h,v
retrieving revision 1.53
diff -r1.53 symbol.h
112a113,115
> /** Utility function to make a real symbol. */
> ex real_symbol(const std::string& name);
> 

From vollinga at thep.physik.uni-mainz.de  Mon Jan  5 23:19:40 2004
From: vollinga at thep.physik.uni-mainz.de (Jens Vollinga)
Date: Mon, 5 Jan 2004 23:19:40 +0100
Subject: patch for symbol.
In-Reply-To: <Pine.LNX.4.44.0401051746590.16216-200000@gamow.sci.kun.nl>
References: <Pine.LNX.4.44.0401051746590.16216-200000@gamow.sci.kun.nl>
Message-ID: <20040105221940.GA1028@thep.physik.uni-mainz.de>

Hi.

Thanks again for your last complex conjugation patch, Chris. It has
made its way into GiNaC almost unchanged ;-)

On Mon, Jan 05, 2004 at 05:59:44PM +0000, Chris Dams wrote:
> 
> Here's a patch from GiNaC's RSI-prevention department. Reason for the
> patch: creating a real symbol is such a common operation that it should be
> as simple as possible.
> 

Now I am wondering, whether a new GiNaC class realsymbol derived from
symbol would be the best solution? 

(realsymbol will be no registered GiNaC class, but simply inherits
from symbol, realsymbol is a friend of symbol, only ctors have to be
rewritten, therefore all type infos are the same, the domain parameter
is not needed anymore ...)

Then you could simply (still enough stress?) write
realsymbol x("x")
or
ex r = 3 * realsymbol("x");

It looks good to me, but maybe there are important concerns (speed,
style, ...) ?!?
-> rsync "main GiNaC developers"

In case that it is a not so good idea, the new patch you sent seems to 
be the best solution.

Bye,
Jens



From chrisd at sci.kun.nl  Tue Jan  6 19:06:33 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Tue, 6 Jan 2004 18:06:33 +0000 (UTC)
Subject: patch for symbol.
In-Reply-To: <20040105221940.GA1028@thep.physik.uni-mainz.de>
Message-ID: <Pine.LNX.4.44.0401061745360.21522-100000@gamow.sci.kun.nl>


Hello,

On Mon, 5 Jan 2004, Jens Vollinga wrote:

> Then you could simply (still enough stress?) write
> realsymbol x("x")
> or
> ex r = 3 * realsymbol("x");

Could also be done. I do not strongly prefer one possibility over the
other.

> It looks good to me, but maybe there are important concerns (speed,
> style, ...) ?!?
> -> rsync "main GiNaC developers"

If you have that a realsymbol inherits from a symbol and not give it its
own tinfo, is_exactly_a<realsymbol> will be true for complex symbols. IMO
this is counter-intuitive.

Bye,
Chris



From keith.briggs at bt.com  Thu Jan 15 18:21:01 2004
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Thu, 15 Jan 2004 17:21:01 -0000
Subject: http://www.ginac.de/tutorial/tutorial_5.html#SEC49
Message-ID: <0AAF93247C75E3408638B965DEE11A70020D5F0C@i2km41-ukdy.domain1.systemhost.net>

> Numercial 
should be "Numerical".

Keith

	Dr. Keith M. Briggs
	Senior Mathematician, Complexity Research, BT Exact
	http://more.btexact.com/people/briggsk2/ (internet)
	http://research.btexact.com/teralab/keithbriggs.html (BT intranet)
	phone: +44(0)1473  work: 641 911 home: 610 517  fax: 642 161
	mail: Keith Briggs, Polaris 134, Adastral Park, Martlesham, Suffolk IP5 3RE, UK



From vollinga at thep.physik.uni-mainz.de  Thu Jan 22 17:37:08 2004
From: vollinga at thep.physik.uni-mainz.de (Jens Vollinga)
Date: Thu, 22 Jan 2004 17:37:08 +0100
Subject: GiNaC 1.1.6 available!
Message-ID: <20040122163707.GA22046@thep.physik.uni-mainz.de>

Hello!

GiNaC 1.1.6 "Sho Chiku Bai" is now available!
It brings to you dummy functions and several bug fixes.

In detail:
* Added a function option "dummy()" which means "no options". This simplifies
  the implementation of symbolic functions which are not to be further
  evaluated.
* Removed a bug in the numerical evaluation of Li() that caused the system
  to hang for certain parameter combinations.
* Fixed a bug in the calculation of hash values for indices that could lead
  to wrong results or bogus error messages from simplify_indexed().
* Fixed a bug in the evaluation of harmonic polylogarithms for complex
  arguments with positive imaginary part.

So we have GiNaC-Team 3 points, cimex lectularius 0 points.

It's where you expect it to be:

  ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/

Bye,
Jens



From keith.briggs at bt.com  Mon Jan 26 12:34:30 2004
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Mon, 26 Jan 2004 11:34:30 -0000
Subject: http://www.ginac.de/reference/search.php?query=expand
Message-ID: <0AAF93247C75E3408638B965DEE11A70020D5F7E@i2km41-ukdy.domain1.systemhost.net>

http://www.ginac.de/reference/search.php?query=expand
>17. GiNaC::expand_options class Reference <classGiNaC_1_1expand__options>

Dead link :(

Keith

	Dr. Keith M. Briggs
	Senior Mathematician, Complexity Research, BT Exact
	http://more.btexact.com/people/briggsk2/ (internet)
	http://research.btexact.com/teralab/keithbriggs.html (BT intranet)
	phone: +44(0)1473  work: 641 911 home: 610 517  fax: 642 161
	mail: Keith Briggs, Polaris 134, Adastral Park, Martlesham, Suffolk IP5 3RE, UK




From chrisd at sci.kun.nl  Wed Jan 28 13:13:07 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Wed, 28 Jan 2004 12:13:07 +0000 (UTC)
Subject: patch for
Message-ID: <Pine.LNX.4.44.0401281149310.12259-200000@gamow.sci.kun.nl>


Hi,

I found that the code

	ex e=indexed(a+b*(c+d),idx(i,3));
	e=e.expand(expand_options::expand_indexed);
	cout << e << endl;
	cout << e.expand(expand_options::expand_indexed) << endl;

gives the output

	a.i+(d*b+c*b).i
	(c*b).i+a.i+(d*b).i

I would have expected to see the second result twice instead. A patch is
attached.

Bye,
Chris
-------------- next part --------------
Index: indexed.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/indexed.cpp,v
retrieving revision 1.88
diff -r1.88 indexed.cpp
328,333c328,339
< 	if ((options & expand_options::expand_indexed) && is_exactly_a<add>(seq[0])) {
< 
< 		// expand_indexed expands (a+b).i -> a.i + b.i
< 		const ex & base = seq[0];
< 		ex sum = _ex0;
< 		for (size_t i=0; i<base.nops(); i++) {
---
> 	if (options & expand_options::expand_indexed) {
> 		ex newbase=seq[0].expand(options);
> 		if(is_exactly_a<add>(newbase)) {
> 			ex sum = _ex0;
> 			for (size_t i=0; i<newbase.nops(); i++) {
> 				exvector s = seq;
> 				s[0] = newbase.op(i);
> 				sum += thiscontainer(s).expand(options);
> 			}
> 			return sum;
> 		}
> 		if(!are_ex_trivially_equal(newbase, seq[0])) {
335,336c341,342
< 			s[0] = base.op(i);
< 			sum += thiscontainer(s).expand();
---
> 			s[0] = newbase;
> 			return ex_to<indexed>(thiscontainer(s)).inherited::expand(options);
338,341c344,345
< 		return sum;
< 
< 	} else
< 		return inherited::expand(options);
---
> 	}
> 	return inherited::expand(options);

From Christian.Bauer at Uni-Mainz.DE  Wed Jan 28 17:37:05 2004
From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer)
Date: Wed, 28 Jan 2004 17:37:05 +0100
Subject: patch for
In-Reply-To: <Pine.LNX.4.44.0401281149310.12259-200000@gamow.sci.kun.nl>
References: <Pine.LNX.4.44.0401281149310.12259-200000@gamow.sci.kun.nl>
Message-ID: <20040128163704.GE23638@thep.physik.uni-mainz.de>

Hi!

On Wed, Jan 28, 2004 at 12:13:07PM +0000, Chris Dams wrote:
> A patch is attached.

Yup. Thanks! :)

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/


From kreckel at thep.physik.uni-mainz.de  Wed Jan 28 21:53:06 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Wed, 28 Jan 2004 21:53:06 +0100 (CET)
Subject: GiNaC acinclude.m4
In-Reply-To: <200401281722.i0SHMP33007074@squark.physik.uni-mainz.de>
Message-ID: <Pine.LNX.4.33.0401282152540.30004-100000@higgs.physik.uni-mainz.de>

On Wed, 28 Jan 2004, Jens Vollinga wrote:

> Update of /home/cvs/GiNaC
>
> Modified Files:
>       Tag: ginac_1-1
> 	acinclude.m4
> Log Message:
> Proper quoting of macros.
>

-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From kreckel at thep.physik.uni-mainz.de  Wed Jan 28 21:56:52 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Wed, 28 Jan 2004 21:56:52 +0100 (CET)
Subject: GiNaC acinclude.m4
In-Reply-To: <Pine.LNX.4.33.0401282152540.30004-100000@higgs.physik.uni-mainz.de>
Message-ID: <Pine.LNX.4.33.0401282155520.30004-100000@higgs.physik.uni-mainz.de>

On Wed, 28 Jan 2004, Richard B. Kreckel wrote:
[...fullquote...]

Ooooops...  Sorry.



From chrisd at sci.kun.nl  Fri Jan 30 15:25:14 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Fri, 30 Jan 2004 14:25:14 +0000 (UTC)
Subject: patch for clifford.cpp
Message-ID: <Pine.LNX.4.44.0401301421110.15910-200000@gamow.sci.kun.nl>


Hello,

I found that the code

	ex e=dirac_slash(a,4)*dirac_slash(b,4)
		+dirac_slash(b,4)*dirac_slash(a,4);
        cout << e << " has trace " << dirac_trace(e) << endl;
        e=canonicalize_clifford(e);
        cout << e << " has trace " << dirac_trace(e) << endl;

gives the output

	b\*a\+a\*b\ has trace 4*b~symbol5*a.symbol5+4*a.symbol3*b~symbol3
	2*b~symbol9*a.symbol9 has trace 2*b~symbol9*a.symbol9

I think this is wrong and that 2*b~symbol9*a.symbol9 should have been
2*ONE*b~symbol9*a.symbol9. A patch is attached.

Bye,
Chris

-------------- next part --------------
Index: clifford.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/clifford.cpp,v
retrieving revision 1.71
diff -r1.71 clifford.cpp
760c760
< 					it[1] = _ex2;
---
> 					it[1] = v.size()==2 ? _ex2*dirac_ONE(ex_to<clifford>(it[1]).get_representation_label()) : _ex2;

From Christian.Bauer at Uni-Mainz.DE  Fri Jan 30 15:56:31 2004
From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer)
Date: Fri, 30 Jan 2004 15:56:31 +0100
Subject: patch for clifford.cpp
In-Reply-To: <Pine.LNX.4.44.0401301421110.15910-200000@gamow.sci.kun.nl>
References: <Pine.LNX.4.44.0401301421110.15910-200000@gamow.sci.kun.nl>
Message-ID: <20040130145631.GH23638@thep.physik.uni-mainz.de>

Hi!

On Fri, Jan 30, 2004 at 02:25:14PM +0000, Chris Dams wrote:
> I think this is wrong and that 2*b~symbol9*a.symbol9 should have been
> 2*ONE*b~symbol9*a.symbol9. A patch is attached.

Whoa! Yes, of course.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/