From Chris.Dams at mi.infn.it  Thu Mar  9 17:19:08 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Thu, 09 Mar 2006 17:19:08 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
Message-ID: <1141921148.26238.4.camel@pcnason2.mi.infn.it>

Dear all,

I added the step function to GiNaCs repertoire of built-in functions. It
is the real function step(x)=1 for x>0 and step(x)=0 for x<0.
Considering the fact that numerical evaluation may yield a small
imaginary part due to rounding errors, a possible imaginary part of a
numerical argument is ignored. Furthermore step(0)=1/2. This, however,
should not be taken too seriously as there is also the automatic
evaluation step(x)^2 -> step(x). In the sense of distributions it does
not matter what the value of step(0) is.

Best,
Chris



From kisilv at maths.leeds.ac.uk  Thu Mar  9 17:31:13 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Thu, 09 Mar 2006 16:31:13 +0000
Subject: [GiNaC-devel] New in GiNaC: step function 
In-Reply-To: Your message of "Thu, 09 Mar 2006 17:19:08 +0100."
	<1141921148.26238.4.camel@pcnason2.mi.infn.it> 
Message-ID: <4135.1141921873@localhost>

>>>>> "CD" == Chris Dams <Chris.Dams at mi.infn.it> writes:
    CD> ignored. Furthermore step(0)=1/2. This, however, should not be
    CD> taken too seriously as there is also the automatic evaluation
    CD> step(x)^2 -> step(x). 

	For a bigger consistency I would prefer to have either step(0)=0 or
  step(0)=1. Such a small features which is easy to overlook sometimes
  takes hours to realise. 
  
  If three-values are really needed we may have another function
  sign(x)=1, x>0
  sign(x)=0, x=0
  sign(x)=-1, x<0
  
  with the property sign(x)^3 -> sign(x). The current step(x) is then
  (sign(x)+1)/2.

  Best wishes,
  Vladimir
-- 
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From Chris.Dams at mi.infn.it  Thu Mar  9 18:10:51 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Thu, 09 Mar 2006 18:10:51 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
In-Reply-To: <4135.1141921873@localhost>
References: <4135.1141921873@localhost>
Message-ID: <1141924251.27281.7.camel@pcnason2.mi.infn.it>

Dear Vladimir,

On Thu, 2006-03-09 at 16:31 +0000, Vladimir Kisil wrote:
> >>>>> "CD" == Chris Dams <Chris.Dams at mi.infn.it> writes:
>     CD> ignored. Furthermore step(0)=1/2. This, however, should not be
>     CD> taken too seriously as there is also the automatic evaluation
>     CD> step(x)^2 -> step(x). 
> 
> 	For a bigger consistency I would prefer to have either step(0)=0 or
>   step(0)=1. Such a small features which is easy to overlook sometimes
>   takes hours to realise. 

Yes, that is a good point. I made step(0) equal to 1.

>   If three-values are really needed we may have another function
>   sign(x)=1, x>0
>   sign(x)=0, x=0
>   sign(x)=-1, x<0

That function already more or less exists as csgn(x). The reason that it
is useful to have both functions is that the combination (csgn(x)+1)/2
is kept together even when expanding and so on if one writes it as
step(x). When looking at output it is more easy to see that step(P)*Q
does not contribute if one knows that P happens to be negative then it
is when it is to be canceled by another term equal to Q.

Best wishes,
Chris



From kisilv at maths.leeds.ac.uk  Thu Mar  9 18:31:50 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Thu, 09 Mar 2006 17:31:50 +0000
Subject: [GiNaC-devel] New in GiNaC: step function 
In-Reply-To: Your message of "Thu, 09 Mar 2006 18:10:51 +0100."
	<1141924251.27281.7.camel@pcnason2.mi.infn.it> 
Message-ID: <8439.1141925510@localhost>

>>>>> "CD" == Chris Dams <Chris.Dams at mi.infn.it> writes:
    CD> That function already more or less exists as csgn(x).

	I missed it. Should we add its power property like that: 

static ex csgn_power(const ex & arg, const ex & exp)
{
	if (is_a<numeric>(exp) && exp.info(info_flags::positive)) {
		if (ex_to<numeric>(exp).is_odd())
			return csgn(arg);
		else
			return power(csgn(arg), _ex2).hold();
	} else
		return power(csgn(arg), exp).hold();
}

	
    CD>  The reason that it is useful to have both functions

	Yes, I agree. So far I used home-brewed definition in
  http://arxiv.org/abs/cs.MS/0512073, now I can switch to the "official" one. ;-)

    CD> (csgn(x)+1)/2 is kept together even when expanding and so on if
    CD> one writes it as step(x). When looking at output it is more easy

	I agree again. My comment was intended only for the case, when the
  intermediate value is important. 

  Best wishes,
  Vladimir 
-- 
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From kreckel at ginac.de  Thu Mar  9 22:44:03 2006
From: kreckel at ginac.de (Richard B. Kreckel)
Date: Thu, 09 Mar 2006 22:44:03 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
In-Reply-To: <8439.1141925510@localhost>
References: <8439.1141925510@localhost>
Message-ID: <4410A1A3.4090100@ginac.de>

Hi!

Vladimir Kisil wrote:

>    CD> That function already more or less exists as csgn(x).
>
>	I missed it. Should we add its power property like that: 
>
>static ex csgn_power(const ex & arg, const ex & exp)
>{
>	if (is_a<numeric>(exp) && exp.info(info_flags::positive)) {
>		if (ex_to<numeric>(exp).is_odd())
>			return csgn(arg);
>		else
>			return power(csgn(arg), _ex2).hold();
>	} else
>		return power(csgn(arg), exp).hold();
>}
>  
>

But that appears to be missing the possibiliby of fractional powers.

>	
>    CD>  The reason that it is useful to have both functions
>
>	Yes, I agree. So far I used home-brewed definition in
>  http://arxiv.org/abs/cs.MS/0512073, now I can switch to the "official" one. ;-)
>
>    CD> (csgn(x)+1)/2 is kept together even when expanding and so on if
>    CD> one writes it as step(x). When looking at output it is more easy
>
>	I agree again. My comment was intended only for the case, when the
>  intermediate value is important. 
>  
>

I'm not totally convinced.  Just one experience: I once was collecting 
lots of such theta functions in computations where they were falling out 
as constraints from complex residue integrations: Is the contour around 
the pole (parametrized as f(x)) or isn't it? The Laurent series of the 
integrand at the poles was known to have only odd negative powers which 
allows one to elegantly take care of the situation where the contour 
crosses the pole: just add Pi*I times the residue (instead of 2*Pi*I).  
Here, it was clearly an advantage to lump them all together with the 
weight theta(f(x))=(1+csgn(f(x)))/2. Some of the term-rewriting rules 
wouldn't work without the intermediate value.

I don't want to argue one way or the other.  It's quite possible that 
what I was doing was exotic.  But I would recommend that if step(x) 
cannot be expressed in terms of csgn(x), then it should be prominently 
documented so.

Regards
  -richy.

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



From Chris.Dams at mi.infn.it  Fri Mar 10 11:12:10 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Fri, 10 Mar 2006 11:12:10 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
In-Reply-To: <4410A1A3.4090100@ginac.de>
References: <8439.1141925510@localhost>  <4410A1A3.4090100@ginac.de>
Message-ID: <1141985530.4628.6.camel@pcnason2.mi.infn.it>

Dear Richy and Vladimir,

On Thu, 2006-03-09 at 22:44 +0100, Richard B. Kreckel wrote:
> Hi!
> 
> Vladimir Kisil wrote:
> 
> >    CD> That function already more or less exists as csgn(x).
> >
> >	I missed it. Should we add its power property like that: 
> >
> >static ex csgn_power(const ex & arg, const ex & exp)
> >{
> >	if (is_a<numeric>(exp) && exp.info(info_flags::positive)) {
> >		if (ex_to<numeric>(exp).is_odd())
> >			return csgn(arg);
> >		else
> >			return power(csgn(arg), _ex2).hold();
> >	} else
> >		return power(csgn(arg), exp).hold();
> >}
> >  
> >
> 
> But that appears to be missing the possibiliby of fractional powers.
> 
> >	
> >    CD>  The reason that it is useful to have both functions
> >
> >	Yes, I agree. So far I used home-brewed definition in
> >  http://arxiv.org/abs/cs.MS/0512073, now I can switch to the "official" one. ;-)
> >
> >    CD> (csgn(x)+1)/2 is kept together even when expanding and so on if
> >    CD> one writes it as step(x). When looking at output it is more easy
> >
> >	I agree again. My comment was intended only for the case, when the
> >  intermediate value is important. 
> >  
> >
> 
> I'm not totally convinced.  Just one experience: I once was collecting 
> lots of such theta functions in computations where they were falling out 
> as constraints from complex residue integrations: Is the contour around 
> the pole (parametrized as f(x)) or isn't it? The Laurent series of the 
> integrand at the poles was known to have only odd negative powers which 
> allows one to elegantly take care of the situation where the contour 
> crosses the pole: just add Pi*I times the residue (instead of 2*Pi*I).  
> Here, it was clearly an advantage to lump them all together with the 
> weight theta(f(x))=(1+csgn(f(x)))/2. Some of the term-rewriting rules 
> wouldn't work without the intermediate value.

Yes, one would, for instance, have
integral(x,-infty,infty, exp(I*k*x)/(x+I*epsilon)) = -2*Pi*I*step(k).
This would give precisely the same right result also at k=0 if
step(0)=1/2. For cases like this it seems that 1/2 is the best value. So
maybe the best thing to do would be to have step(0)=1/2 and not to do a
simplification step(x)^2 -> step(x). After all, if desired, such a
simplification could also be done by the user. (S)he could do
.subs(step(wild())*step(wild())==step(wild()), subs_options::algebraic).

Can everybody live with that?

Best,
Chris



From kisilv at maths.leeds.ac.uk  Fri Mar 10 11:33:17 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Fri, 10 Mar 2006 10:33:17 +0000
Subject: [GiNaC-devel] New in GiNaC: step function 
In-Reply-To: Your message of "Fri, 10 Mar 2006 11:12:10 +0100."
	<1141985530.4628.6.camel@pcnason2.mi.infn.it> 
Message-ID: <E1FHevt-0005eW-35@localhost>


CD> Yes, one would, for instance, have
CD> integral(x,-infty,infty, exp(I*k*x)/(x+I*epsilon)) = -2*Pi*I*step(k).
CD> This would give precisely the same right result also at k=0 if
CD> step(0)=1/2. For cases like this it seems that 1/2 is the best value.

Yes, this is an important case, which needs such a function.

CD> maybe the best thing to do would be to have step(0)=1/2 and not to do a
CD> simplification step(x)^2 -> step(x). 
CD> Can everybody live with that?

Since it is consistent no reasons to object.  

CD> After all, if desired, such a
CD> simplification could also be done by the user. (S)he could do
CD> .subs(step(wild())*step(wild())==step(wild()), subs_options::algebraic).

In heavy calculations it is important that some simplifications are made
automatically on intermediate cases. To this end we may have (in the
core GiNaC or user-defined) another function (say "jump") which have the
property jump^2(t) -> jump(t).

RC> > 	 I missed it. Should we add its power property like that:
RC> >
RC> >static ex csgn_power(const ex & arg, const ex & exp)
RC> >{
RC> >}
RC> 
RC> But that appears to be missing the possibiliby of fractional powers.

I am not sure what fractional powers of a negative values should be...

Best wishes,
Vladimir
--
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From Chris.Dams at mi.infn.it  Fri Mar 10 17:29:33 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Fri, 10 Mar 2006 17:29:33 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
In-Reply-To: <E1FHevt-0005eW-35@localhost>
References: <E1FHevt-0005eW-35@localhost>
Message-ID: <1142008173.7802.9.camel@pcnason2.mi.infn.it>

Dear Vladimir,

On Fri, 2006-03-10 at 10:33 +0000, Vladimir Kisil wrote:

> CD> maybe the best thing to do would be to have step(0)=1/2 and not to do a
> CD> simplification step(x)^2 -> step(x). 
> CD> Can everybody live with that?
> 
> Since it is consistent no reasons to object.  

OK.

> CD> After all, if desired, such a
> CD> simplification could also be done by the user. (S)he could do
> CD> .subs(step(wild())*step(wild())==step(wild()), subs_options::algebraic).
> 
> In heavy calculations it is important that some simplifications are made
> automatically on intermediate cases. To this end we may have (in the
> core GiNaC or user-defined) another function (say "jump") which have the
> property jump^2(t) -> jump(t).

I would prefer not to have such a function in GiNaC itself. The
difference between "jump" and "step" would be too small to justify
introducing another object IMO. I did not follow the discussion on the
new function system that Jens seems to be building, but what would be
ideal is if the user could implement "jump" by deriving from "step" and
simply add the automatic simplification jump^2 -> jump. I would think
that the number of users that needs this simplification to be done in
the midst of a calculation is not so large as to justify adding the
function "jump" to the library.

Best,
Chris



From kisilv at maths.leeds.ac.uk  Fri Mar 10 17:43:05 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Fri, 10 Mar 2006 16:43:05 +0000
Subject: [GiNaC-devel] New in GiNaC: step function 
In-Reply-To: Your message of "Fri, 10 Mar 2006 17:29:33 +0100."
	<1142008173.7802.9.camel@pcnason2.mi.infn.it> 
Message-ID: <E1FHkhl-0005uv-EO@localhost>


> I did not follow the discussion on the
> new function system that Jens seems to be building, but what would be
> ideal is if the user could implement "jump" by deriving from "step" and
> simply add the automatic simplification jump^2 -> jump

Anyway it is not difficult to cut&past the entire definition of step to
user's code, rename and make few desirable alterations.
--
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From kreckel at ginac.de  Fri Mar 10 22:24:36 2006
From: kreckel at ginac.de (Richard B. Kreckel)
Date: Fri, 10 Mar 2006 22:24:36 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
In-Reply-To: <E1FHevt-0005eW-35@localhost>
References: <E1FHevt-0005eW-35@localhost>
Message-ID: <4411EE94.8040500@ginac.de>

Hi, Vladimir

Vladimir Kisil wrote:

>RC> But that appears to be missing the possibiliby of fractional powers.
>
>I am not sure what fractional powers of a negative values should be...
>  
>

For example csgn(x)^(1/2) where it later turns out that x==-1.  It seems 
to me that the rewriting rule you suggested would get that wrong.

Cheers
  -richy.

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



From kisilv at maths.leeds.ac.uk  Fri Mar 10 22:43:02 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Fri, 10 Mar 2006 21:43:02 +0000
Subject: [GiNaC-devel] New in GiNaC: step function 
In-Reply-To: Your message of "Fri, 10 Mar 2006 22:24:36 +0100."
	<4411EE94.8040500@ginac.de> 
Message-ID: <E1FHpO2-00064K-Cn@localhost>

> For example csgn(x)^(1/2) where it later turns out that x==-1.  

Now I see the ommision, this one should be better:

static ex csgn_power(const ex & arg, const ex & exp)
{
	if (is_a<numeric>(exp) && exp.info(info_flags::positive) && ex_to<numeric>(exp).is_integer()) {
		if (ex_to<numeric>(exp).is_odd())
			return csgn(arg);
		else
			return power(csgn(arg), _ex2).hold();
	} else
		return power(csgn(arg), exp).hold();
}

Best,
Vladimir
--
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From Chris.Dams at mi.infn.it  Mon Mar 13 15:22:40 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Mon, 13 Mar 2006 15:22:40 +0100
Subject: [GiNaC-devel] New in GiNaC: step function
In-Reply-To: <E1FHpO2-00064K-Cn@localhost>
References: <E1FHpO2-00064K-Cn@localhost>
Message-ID: <1142259760.4211.1.camel@pcnason2.mi.infn.it>

Dear all,

step(0)=1/2 again and power_step was removed.

Best,
Chris



From kisilv at maths.leeds.ac.uk  Mon Mar 13 16:59:20 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Mon, 13 Mar 2006 15:59:20 +0000
Subject: [GiNaC-devel] csgn patch
Message-ID: <24585.1142265560@localhost>

		Dear all,

		Here is the full patch for the power property of csgn()
  function. Its effect can be seen in the following  ginsh output:

> csgn(x)^3;
csgn(x)
> csgn(x)^5;
csgn(x)
> csgn(x)^2;
csgn(x)^2
> csgn(x)^(2/5);
csgn(x)^(2/5)
> csgn(x)^(6/2);
csgn(x)
> csgn(x)^(-2);
csgn(x)^(-2)
> csgn(x)^(-3);
csgn(x)^(-3)
> csgn(x)^(-3/3);
csgn(x)^(-1)
> csgn(x)^(-3/2);
csgn(x)^(-3/2)

Best wishes,
	 Vladimir
-- 
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/

Index: ginac/inifcns.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/inifcns.cpp,v
retrieving revision 1.87
diff -u -r1.87 inifcns.cpp
--- ginac/inifcns.cpp	13 Mar 2006 14:21:47 -0000	1.87
+++ ginac/inifcns.cpp	13 Mar 2006 15:56:20 -0000
@@ -252,10 +252,23 @@
 	return csgn(arg);
 }
 
+static ex csgn_power(const ex & arg, const ex & exp)
+{
+	if (is_a<numeric>(exp) && exp.info(info_flags::positive) && ex_to<numeric>(exp).is_integer()) {
+		if (ex_to<numeric>(exp).is_odd())
+			return csgn(arg);
+		else
+			return power(csgn(arg), _ex2).hold();
+	} else
+		return power(csgn(arg), exp).hold();
+}
+
+
 REGISTER_FUNCTION(csgn, eval_func(csgn_eval).
                         evalf_func(csgn_evalf).
                         series_func(csgn_series).
-                        conjugate_func(csgn_conjugate));
+                        conjugate_func(csgn_conjugate).
+                        power_func(csgn_power));
 
 
 //////////


From Chris.Dams at mi.infn.it  Tue Mar 14 16:54:31 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Tue, 14 Mar 2006 16:54:31 +0100
Subject: [GiNaC-devel] csgn patch
In-Reply-To: <24585.1142265560@localhost>
References: <24585.1142265560@localhost>
Message-ID: <1142351671.18575.0.camel@pcnason2.mi.infn.it>

Dear Vladimir

On Mon, 2006-03-13 at 15:59 +0000, Vladimir Kisil wrote:

>   Here is the full patch for the power property of csgn()
>   function. Its effect can be seen in the following  ginsh output:

The patch has been applied.

Best,
Chris



From Chris.Dams at mi.infn.it  Mon Mar 27 17:18:48 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Mon, 27 Mar 2006 17:18:48 +0200 (CEST)
Subject: [GiNaC-devel] New .is_polynomial() method.
Message-ID: <Pine.LNX.4.44.0603271715290.13937-100000@lxmi.mi.infn.it>


Dear all,

I have added a method .is_polynomial() to GiNaC. Using 
.info(info_flags::polynomial) is not sufficient because in that case one 
cannot distinguish an expression that may be a polynomial in a variable 
but nog in another. Example: x*y*sin(y) is a polynomial in x but not in y.
Hence (x*y*sin(y)).is_polynomial(x) returns true but 
(x*y*sin(y)).is_polynomial(lst(x,y)) returns false. I also patched the 
tutorial.

Best,
Chris



From christian.fleck at fdm.uni-freiburg.de  Thu Mar 30 12:34:58 2006
From: christian.fleck at fdm.uni-freiburg.de (Christian Fleck)
Date: Thu, 30 Mar 2006 12:34:58 +0200
Subject: [GiNaC-devel] Problems in compiling ginac on a iMac (Intel)
Message-ID: <B70C845E-6AAF-4B32-BE78-F33581358C35@fdm.uni-freiburg.de>

Hello,

I tried to compile ginac version 1.3.3 with gcc 4.0.0 (Apple version)  
on a Intel iMac running OS X 10.4.5. My version of libread is 5.1. I  
append the config.log.

The first error is that the configure script can still not find the  
correct version of cln, although it should be installed correctly.
I tried to play a bit, but was not able to fix it. Running 'configure  
--disable-clntest --enable-shared=no'  and typing 'make' produces:
...
ginsh_parser.yy:47:6: error: missing binary operator before token  
"wrapper"
ginsh_parser.yy:53:6: error: missing binary operator before token  
"wrapper"
ginsh_parser.yy:845:6: error: missing binary operator before token  
"wrapper"
ginsh_parser.yy:855:6: error: missing binary operator before token  
"wrapper"

I edited the file config.h changing the lines
/* Major version of installed readline library. */
#define GINAC_RL_VERSION_MAJOR EditLine wrapper

/* Minor version of installed readline library. */
#define GINAC_RL_VERSION_MINOR EditLine wrapper

into

/* Major version of installed readline library. */
#define GINAC_RL_VERSION_MAJOR 1

/* Minor version of installed readline library. */
#define GINAC_RL_VERSION_MINOR 3

But running 'make' then produced:
...
Making all in ginsh
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac - 
DIN_GINAC  -I/usr/local/include  -g -O2 -MT ginsh_parser.o -MD -MP - 
MF ".deps/ginsh_parser.Tpo" -c -o ginsh_parser.o ginsh_parser.cc; \
then mv -f ".deps/ginsh_parser.Tpo" ".deps/ginsh_parser.Po"; else rm - 
f ".deps/ginsh_parser.Tpo"; exit 1; fi
ginsh_parser.yy: In function 'char** fcn_completion(const char*, int,  
int)':
ginsh_parser.yy:844: error: invalid conversion from 'const char*' to  
'char*'
ginsh_parser.yy:846: error: 'filename_completion_function' was not  
declared in this scope
ginsh_parser.yy:846: error: 'completion_matches' was not declared in  
this scope
ginsh_parser.yy:854: error: invalid conversion from 'const char*' to  
'char*'
ginsh_parser.yy:856: error: 'completion_matches' was not declared in  
this scope
ginsh_parser.yy: In function 'int main(int, char**)':
ginsh_parser.yy:908: error: invalid conversion from 'char** (*)(...)'  
to 'char** (*)(const char*, int, int)'
ginsh_parser.yy:913: error: invalid conversion from 'const char*' to  
'char*'
make[2]: *** [ginsh_parser.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Does anyone has an idea what is going wrong and how to fix it?

Thanks,

Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log.zip
Type: application/zip
Size: 10495 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20060330/f48529aa/attachment.zip>
-------------- next part --------------