You can subscribe to this list here.
2009 
_{Jan}
(2) 
_{Feb}
(5) 
_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(8) 
_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(6) 
_{Dec}


2010 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(2) 
_{Jul}
(18) 
_{Aug}
(13) 
_{Sep}
(7) 
_{Oct}

_{Nov}

_{Dec}
(2) 
2011 
_{Jan}

_{Feb}
(11) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(1) 
_{Jul}
(18) 
_{Aug}
(16) 
_{Sep}
(12) 
_{Oct}
(12) 
_{Nov}
(19) 
_{Dec}
(42) 
2012 
_{Jan}
(16) 
_{Feb}
(3) 
_{Mar}
(8) 
_{Apr}
(14) 
_{May}
(30) 
_{Jun}
(5) 
_{Jul}
(7) 
_{Aug}
(3) 
_{Sep}
(10) 
_{Oct}
(4) 
_{Nov}
(10) 
_{Dec}
(1) 
2013 
_{Jan}
(14) 
_{Feb}
(8) 
_{Mar}
(5) 
_{Apr}
(3) 
_{May}
(9) 
_{Jun}
(19) 
_{Jul}

_{Aug}
(27) 
_{Sep}
(5) 
_{Oct}
(18) 
_{Nov}
(12) 
_{Dec}
(8) 
2014 
_{Jan}
(5) 
_{Feb}
(8) 
_{Mar}
(20) 
_{Apr}
(22) 
_{May}
(28) 
_{Jun}
(9) 
_{Jul}
(6) 
_{Aug}
(46) 
_{Sep}
(40) 
_{Oct}
(15) 
_{Nov}
(8) 
_{Dec}
(34) 
2015 
_{Jan}
(20) 
_{Feb}
(15) 
_{Mar}
(18) 
_{Apr}
(20) 
_{May}
(3) 
_{Jun}
(13) 
_{Jul}
(10) 
_{Aug}
(19) 
_{Sep}
(8) 
_{Oct}
(31) 
_{Nov}
(26) 
_{Dec}
(13) 
2016 
_{Jan}
(13) 
_{Feb}
(4) 
_{Mar}
(14) 
_{Apr}
(28) 
_{May}
(19) 
_{Jun}
(7) 
_{Jul}
(1) 
_{Aug}

_{Sep}
(19) 
_{Oct}
(5) 
_{Nov}
(4) 
_{Dec}
(9) 
2017 
_{Jan}
(4) 
_{Feb}
(30) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1

2

3

4
(5) 
5

6

7
(1) 
8

9
(1) 
10

11

12
(1) 
13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28



From: Rainer Schöpf <rainer.schoepf@gm...>  20130212 08:51:46

On Sat, 9 Feb 2013 at 10:52 0000, Alan Barnes wrote: > Regarding the 'feature' when the operator abs is applied to ps domain > elements, I agree with Rainer that taking the sign of the coefficient of > the lowest order term would be a quick fix when the coefficient is > numeric. When the coefficient is algebraic, abs could simply return abs > of its argument as it does for 'normal' algebraic expressions . The problem is that the current code for computing the absolute value of a domain element uses the only interface the domain mode code offers: a function returning t when a domain element is positive, nil otherwise. This approach doesn't really work for nonconstant domain elements. So, yes, the quick fix works for the case in question, but it requires already a couple of changes to the tps code to make that one example work. I'm not sure what other places in the code there are that might be affected. > Alternatively abs could simply return abs of its argument; correct but > not very useful! Yes, but what can one do in general? The more I think about this, the more I believe that "abs" is another special case that needs its own (optional) domain mode function, like for "expt". It is then the responsibility of the specific domain element code to compute the absolute value of a domain element. It might even be a good idea to have a "constant/nonconstant" flag for a domain mode. To give one reason: the function constant_exprp returns t for an integer argument, but nil for a constant domaion element like (!:rd!: . 1.0) . Rainer 
From: Alan Barnes <barnesa@as...>  20130209 11:07:55

Regarding the 'feature' when the operator abs is applied to ps domain elements, I agree with Rainer that taking the sign of the coefficient of the lowest order term would be a quick fix when the coefficient is numeric. When the coefficient is algebraic, abs could simply return abs of its argument as it does for 'normal' algebraic expressions . Alternatively abs could simply return abs of its argument; correct but not very useful! The first approach would have the desirable property that abs(ps1*ps2) = abs(ps1)*abs(ps2) but, of course, evaluations of the resulting power series at even 'small' values of the expansion variable would not necessarily be positive. When the ps package was written (was it really 26 years ago?), the ideas of representing power series by domain elements and using simulated lazy evaluation (so that the series were extendible) were experimental. Prior to that domain elements were always constant. The experiment was, I think, only moderately successful and if I were writing the package now, I would use some other representation (but retain the lazy evaluation approach). Although the ps code works reasonably well when the underlying domain is constant (rational, complex, complex rational etc), the idea of representing a bivariate power series as a univariate power series over a univariate power series domain (etc.) opened a 'can of worms' as there is no support in Reduce for parameterised domains. Alan Barnes On 07/02/2013 21:23, Rainer Schöpf wrote: > The recent bug report > > https://sourceforge.net/p/reducealgebra/bugs/44/ > > unconvered a problem with the abs operator: Applying the abs operator to certain > domain elements yields inconsistent results, e.g. for domain mode ps or atensor. > >  > 1: load atensor; > 2: tensor a2; > > 3: a2(k,k); > > a2(k,k) > > 4: abs(ws); > > a2(k,k) > > 5: abs(ws); > >  a2(k,k) >  > > The reason: all domain elements of type ps or atensor are considered positive > (by virtue of the corresponding "minusp" function), so that abs always returns > its argument. > > For ps, taking the sign of the constant term of a power series as "sign" of the > whole series might be a solution. > > In general, the only solution I can think of is to add an optional "abs" > property to a domain mode, pointing to a function that returns a sensible result > (or an error). > > Rainer > >  > Free NextGen Firewall Hardware Offer > Buy your Sophos nextgen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophosd2dfeb > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > 
From: Rainer Schöpf <rainer.schoepf@gm...>  20130207 21:23:55

The recent bug report https://sourceforge.net/p/reducealgebra/bugs/44/ unconvered a problem with the abs operator: Applying the abs operator to certain domain elements yields inconsistent results, e.g. for domain mode ps or atensor.  1: load atensor; 2: tensor a2; 3: a2(k,k); a2(k,k) 4: abs(ws); a2(k,k) 5: abs(ws);  a2(k,k)  The reason: all domain elements of type ps or atensor are considered positive (by virtue of the corresponding "minusp" function), so that abs always returns its argument. For ps, taking the sign of the constant term of a power series as "sign" of the whole series might be a solution. In general, the only solution I can think of is to add an optional "abs" property to a domain mode, pointing to a function that returns a sensible result (or an error). Rainer 
From: Rainer Schöpf <rainer.schoepf@gm...>  20130204 17:56:47

On Mon, 4 Feb 2013 at 14:59 0200, joaquin murgade wrote: > I have built reduce deb packages on ubuntu 10.10 today and > > found the following (with redcsl) > > int(sin(x)*x,x,1,1) produces 2(cos(1)+sin(1)) > > int(x*sin(x),x,1,1) produces 0 > > Any idea what's going on ? I've just committed a temporary fix for this bug. I'm afraid that the definite integration package needs a thorough code review. Regards, Rainer 
From: joaquin murgade <releese@gm...>  20130204 16:59:16

Hello, I have built reduce deb packages on ubuntu 10.10 today and found the following (with redcsl) int(sin(x)*x,x,1,1) produces 2(cos(1)+sin(1)) int(x*sin(x),x,1,1) produces 0 Any idea what's going on ? Regards Joaquin 
From: Rainer Schöpf <rainer.schoepf@gm...>  20130204 10:28:56

Hello all, I believe that I have now a new Win32 Version of PSL, with  correct handling of long filenames  proper trap handling (especially floating point traps)  a number of minor corrections and improvements As a first step I will commit a lot of shortotlong filename changes in the psl source tree, to bring it in sync with the rest of psl. This should not influence the Reduce build process. Afterwards, I will modify the Reduce build process to copy the compiled lisp files from the PSL tree instead of downloading them from ZIB. I do not intend to break anything, but one never knows. I'll announce this shortly before I do the second step, so please bear with me for a couple days then. Rainer 
From: Rainer Schöpf <rainer.schoepf@gm...>  20130204 10:22:19

On Mon, 4 Feb 2013, Arthur Norman wrote: > Another glitch, noted here so it is on the record... > > 1: load_package specfn; > > 2: zeta_function(2, a + b*x); > > 50000000000000*abs(sqrt(  a  b*x + 1)  1)  1 > *****  invalid as number > 100000000000000 > > > and actually all sorts of second arguments to zeta_function(2,...) seem to > cause trouble... for instance I seem to find zeta_function(2,1) just > falling into a CPU sink. The documentation mentions both "zeta_function" and "JacobiZeta" for the Jacobi Zeta function. I guess the former is an unfinished attempt that works only for numerical second argument. Rainer 
From: Arthur Norman <acn1@ca...>  20130204 09:32:11

Another glitch, noted here so it is on the record... 1: load_package specfn; 2: zeta_function(2, a + b*x); 50000000000000*abs(sqrt(  a  b*x + 1)  1)  1 *****  invalid as number 100000000000000 and actually all sorts of second arguments to zeta_function(2,...) seem to cause trouble... for instance I seem to find zeta_function(2,1) just falling into a CPU sink. I have not yet looked into this at all. Arthur 