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}
(5) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(1) 
2
(1) 
3

4

5
(1) 
6
(2) 
7
(1) 
8
(2) 
9
(3) 
10

11

12
(1) 
13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30


From: Rainer Schöpf <rainer.schoepf@gm...>  20110912 17:07:35

While testing some new code for the main tree, I came upon an odesolve example that no longer works, (ex. 7 from zimmer.tst): In PSL, the whole system crashes with a SIGSEGV. Even after fixing the particular bug causing the crash, the example takes a very long time until memory is exhausted. The reason behind this behaviour is the attempt to try substitutions before running the integrator proper. A simple example of this problem is int(e^(1/x)*sqrt(x2),x); 1/x 5 1/x 3 1/x 2 (2*(105*e *sqrt(x  2)*x + 420*e *sqrt(x  2)*x + 280*e *sqrt(x  2)*x 1/x 1/x + 672*e *sqrt(x  2)*x + 160*e *sqrt(x  2) 1/x 1/x e 4 e 4  320*int(,x)*x  2464*int(,x)*x 6 5 sqrt(x  2)*x sqrt(x  2)*x 1/x e 4 4  3360*int(,x)*x ))/(315*x ) 4 sqrt(x  2)*x Or try this: on combinelogs; int(e^(1/x)*sqrt(x2),x); This result is silly; replacing the original integral by as um of more complicated ones. Running with "on trint;" shows that the substitution code tries all kind of substitutions to simplify the integral, but never comes back to the original integrand when the substitution doesn't give a better result. I'm well aware of the fact that "a better result" is a vague concept and unlikely to be accessible algorithmically. However, the current code can easily iterate until resources are exhausted; try this for a example: on combinelogs; int(e^(1/x)*sqrt(x2)/sqrt(x),x); or int(e^(1/x^3)*sqrt(x2)/sqrt(x),x); I propose to check that a substitution doesn't introduce a new transcendental kernel. Take the last two integrals: In both cases, the substitutions applied are 1. x = y^2+2 2. y = sqrt(2)*sinh(z) which lead to new kernels exp(1/(2*cosh(z)^2)) and exp(1/(8*cosh(z)^6)), respectively. The occurence of these should prevent the substituted integral to be tried. Comments are welcome. Rainer 