You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(2) 

2002 
_{Jan}
(30) 
_{Feb}

_{Mar}
(5) 
_{Apr}
(5) 
_{May}

_{Jun}
(2) 
_{Jul}

_{Aug}
(1) 
_{Sep}
(6) 
_{Oct}

_{Nov}

_{Dec}
(1) 
2003 
_{Jan}
(10) 
_{Feb}
(5) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}
(5) 
_{Jun}
(5) 
_{Jul}
(5) 
_{Aug}

_{Sep}
(6) 
_{Oct}

_{Nov}
(3) 
_{Dec}
(4) 
2004 
_{Jan}
(9) 
_{Feb}
(1) 
_{Mar}
(16) 
_{Apr}
(3) 
_{May}
(2) 
_{Jun}

_{Jul}

_{Aug}
(3) 
_{Sep}

_{Oct}
(3) 
_{Nov}
(3) 
_{Dec}
(3) 
2005 
_{Jan}
(6) 
_{Feb}
(3) 
_{Mar}
(1) 
_{Apr}
(8) 
_{May}
(3) 
_{Jun}
(4) 
_{Jul}
(11) 
_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}

_{Dec}
(1) 
2006 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(6) 
_{Jun}
(6) 
_{Jul}
(4) 
_{Aug}
(3) 
_{Sep}

_{Oct}
(7) 
_{Nov}
(1) 
_{Dec}

2007 
_{Jan}

_{Feb}
(6) 
_{Mar}
(2) 
_{Apr}
(15) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}
(3) 
_{Oct}
(2) 
_{Nov}
(11) 
_{Dec}

2008 
_{Jan}

_{Feb}
(2) 
_{Mar}

_{Apr}
(4) 
_{May}
(1) 
_{Jun}
(2) 
_{Jul}
(1) 
_{Aug}
(2) 
_{Sep}

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

2009 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}

_{Jul}
(5) 
_{Aug}

_{Sep}
(8) 
_{Oct}
(3) 
_{Nov}

_{Dec}

2010 
_{Jan}

_{Feb}
(1) 
_{Mar}
(2) 
_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}
(8) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2011 
_{Jan}

_{Feb}
(2) 
_{Mar}
(6) 
_{Apr}
(6) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6

7

8

9

10

11

12

13
(2) 
14

15

16

17

18
(1) 
19
(2) 
20

21

22

23

24

25

26

27

28

29

30







From: Pierre SCHNIZER <p.schnizer@gs...>  20060419 15:05:51

Dear Benjamin, > I encountered a rather severe memory leak when using > pygsl_rng.dirichlet_lnpdf. I'm using gsl 1.8 via pygsl 0.3.2. > > The following code snippet reproduces the error: > > import pygsl.rng > for i in range(800000): > pygsl.rng.dirichlet_lnpdf([1.1,1.1,1.1,1.1],[[0.25,0.25,0.25,0.25]]) > > When running this you will see the memory consumption increase > monotonously. > > The problem did not occur when I implemented the density function myself > using pygsl.sf.gamma, nor for a C test script that called > gsl_ran_dirichlet_pdf directly. This seems to indicate that the problem > resides somewhere in the pygsl interface to gsl_ran_dirichlet_pdf. > Thanks for the report. Two arrays were not dereferenced and thus started to eat up the memory... A patch is added. I also checked it into CVS but it takes time until one can retrieve it from anonymous cvs. If required I can send you the full file as well. Sincerely yours Pierre 
From: Benjamin Georgi <georgi@mo...>  20060419 14:15:33

Hi, I encountered a rather severe memory leak when using pygsl_rng.dirichlet_lnpdf. I'm using gsl 1.8 via pygsl 0.3.2. The following code snippet reproduces the error: import pygsl.rng for i in range(800000): pygsl.rng.dirichlet_lnpdf([1.1,1.1,1.1,1.1],[[0.25,0.25,0.25,0.25]]) When running this you will see the memory consumption increase monotonously. The problem did not occur when I implemented the density function myself using pygsl.sf.gamma, nor for a C test script that called gsl_ran_dirichlet_pdf directly. This seems to indicate that the problem resides somewhere in the pygsl interface to gsl_ran_dirichlet_pdf. Best, Benjamin 
From: Bruce Nourish <bjan@sp...>  20060418 00:37:51

Hey Everyone, This patch implements linalg.solve_tridiagonal, whose omission was probably a mistake. Below is a patch to CVS pygsl/linalg.py, followed by a test program.  linalg.py.old 20060417 16:10:53.000000000 0700 +++ linalg.py 20060417 16:14:06.000000000 0700 @@ 729,6 +729,22 @@ # Tridiagonal Systems # +def solve_tridiag(diag, e, f, b): + """ + returns x + + This function solves the general NbyN system A x = b where A is + tridiagonal. The form of A for the 4by4 case is shown below, + + A = ( d_0 e_0 ) + ( f_0 d_1 e_1 ) + ( f_1 d_2 e_2 ) + ( f_2 d_3 ) + """ + x = zeros(diag.shape, get_typecode(diag)) + _gslwrap.gsl_linalg_solve_tridiag(diag, e, f, b, x) + return x + def solve_symm_tridiag(diag, e, b): """ returns x #!/usr/bin/python from __future__ import division from pygsl import linalg from pygsl._numobj import * diag = ones((3,), Float) subd = zeros((2,), Float) supd = zeros((2,), Float) rhs = array([1, 2, 3], Float) trivial_1 = linalg.solve_symm_tridiag(diag, subd, rhs) trivial_2 = linalg.solve_tridiag(diag, supd, subd, rhs) print 'This vector should be zero:', (trivial_1  trivial_2) subd[1] = 100 asymm = linalg.solve_tridiag(diag, supd, subd, rhs) print 'This vector shouldn\'t:', (trivial_1  asymm)  Bruce J.A. Nourish <bjan@...> http://sps.la.asu.edu/~bjan/ >>> import this 
From: Pierre SCHNIZER <p.schnizer@gs...>  20060413 15:15:55

Laurent.Perrinet@... wrote: > Hi! > in the documentation, http://pygsl.sourceforge.net/reference/pygsl/node10.html > instead of > print "a teaspoon contains %g ml"%cgs.teaspoon > it should be > print "a teaspoon contains %g ml" %cgsm.teaspoon > so that finally I learn that > a teaspoon contains 4.92892 ml ! > > Thanks for the report. I will correct it soon. Pierre 
From: Laurent.P<errinet@in...>  20060413 11:50:12

Hi! in the documentation, http://pygsl.sourceforge.net/reference/pygsl/node10.html instead of print "a teaspoon contains %g ml"%cgs.teaspoon it should be print "a teaspoon contains %g ml" %cgsm.teaspoon so that finally I learn that a teaspoon contains 4.92892 ml ! thanks, laurent 