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}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(3) 
_{Oct}

_{Nov}

_{Dec}

2016 
_{Jan}

_{Feb}

_{Mar}
(7) 
_{Apr}
(12) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2
(1) 
3

4
(2) 
5
(4) 
6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31





From: Stock, Stuart <Stuart.S<tock@dk...>  20061005 19:47:29

Hello, Yes, I am using numpy and pygsl on a 64 bit machine. I will try the CVS version and let you know how it goes. Regards, Stuart Original Message From: Pierre SCHNIZER [mailto:p.schnizer@...] Sent: Thursday, October 05, 2006 1:15 AM To: Stock, Stuart Subject: Re: [pygsldiscuss] Many tests fail with "expected 4294967295 elements" on 64bit Re dHat AS4 Stock, Stuart wrote: > Hello, > > After successfully compiling and installing pygsl 0.3.2, running the tests > via run_test.py results in many errors, all of them producing a very similar > error message. Excerpts below. > > Our environment is: >  RedHat AS 4 on Opteron >  GCC version 3.4.4 20050721 (Red Hat 3.4.42) >  Python 2.4.2 >  GSL 1.8 >  PyGSL 0.3.2 >  Numpy 1.0b5 > > Any help is very much appreciated. > > Regards, > Stuart > > Are you using numpy and pygsl on a 64 bit machine? This issue is known, however I did not yet find the time for a new release. Please could you try the CVS version if the above is the case? Sincerely yours Pierre 
From: Pierre SCHNIZER <p.schnizer@gs...>  20061005 16:15:30

emueller@... wrote: > Hi All, > > With a few changes, I was able to get PyGSL0.3.numpy_test to build > with numpy1.0rc1 on gentoo linux x86. > >  (for gentoo users) I did not use the numpy in the portage tree, but > installed from source. > >  I linked the numpy include to be in the same place as Numeric+numarray: > ln s /usr/lib/python2.4/sitepackages/numpy/core/include/numpy > /usr/include/python2.4 > >  I made some small changes to a block_helpers_numpy.ic: > > * intp on line 5 to int > * CONTIGUOUS > NPY_CONTIGUOUS > * ALIGNED > NPY_ALIGNED > * WRITABLE > NPY_WRITABLE, etc. > >  similar changes for block_helpers.c > > Thanks for the information. Should be fixed in the CVS version. I think they changed that from version 0.96 to 0.98 As soons as a 1.0 is out a new release should be made. If curious you could also try to compile the CVS version. The code there should be able to cope with arrays with a stride, which is not a pure integer multiple of the basis type. I think such problems can araise when using the more elaborate features of numpy, but I never encountered that particular problem my self. Sincerely yours Pierre 
From: <emueller@ki...>  20061005 09:49:45

Hi All, it seems there's an error in the initial #defines logic of diff_deriv_common.c #define _PYGSL_HAS_DERIV 0 but #ifdef _PYGSL_HAS_DERIV is true! I think it should be changed to: #if _PYGSL_HAS_DERIV==1 etc... Thus it should read: #if (PYGSL_GSL_MAJOR_VERSION == 1) && (PYGSL_GSL_MINOR_VERSION < 5) #define _PYGSL_HAS_DERIV 0 #else #define _PYGSL_HAS_DERIV 1 #endif #include <pygsl/error_helpers.h> #include <pygsl/function_helpers.h> #if _PYGSL_HAS_DERIV==1 #include <gsl/gsl_deriv.h> #endif #ifdef PyGSL_DERIV_MODULE #if _PYGSL_HAS_DERIV==0 #error "The deriv module was only introduced by GSL 1.5. You seem to compile against an older verion!" #endif #endif /* PyGSL_DERIV_MODULE */ With these changes, PyGSL builds for me with GSL 1.3 ... cheers, e. 
From: <emueller@ki...>  20061005 09:05:29

Hi All, With a few changes, I was able to get PyGSL0.3.numpy_test to build with numpy1.0rc1 on gentoo linux x86.  (for gentoo users) I did not use the numpy in the portage tree, but installed from source.  I linked the numpy include to be in the same place as Numeric+numarray: ln s /usr/lib/python2.4/sitepackages/numpy/core/include/numpy /usr/include/python2.4  I made some small changes to a block_helpers_numpy.ic: * intp on line 5 to int * CONTIGUOUS > NPY_CONTIGUOUS * ALIGNED > NPY_ALIGNED * WRITABLE > NPY_WRITABLE, etc.  similar changes for block_helpers.c then I ran: python setup.py build arrayobject=numpy Then: In [1]: import pygsl In [2]: pygsl.version Out[2]: '0.3.2' ... In [4]: from pygsl import rng In [5]: myrng = rng.rng() ... In [7]: a = myrng.exponential(0.1,1000) In [8]: type(a) Out[8]: <type 'numpy.ndarray'> looks good. cheers, e. 
From: Stock, Stuart <Stuart.S<tock@dk...>  20061004 21:08:41

Hello, After successfully compiling and installing pygsl 0.3.2, running the tests via run_test.py results in many errors, all of them producing a very similar error message. Excerpts below. Our environment is:  RedHat AS 4 on Opteron  GCC version 3.4.4 20050721 (Red Hat 3.4.42)  Python 2.4.2  GSL 1.8  PyGSL 0.3.2  Numpy 1.0b5 Any help is very much appreciated. Regards, Stuart ====================================================================== ERROR: testSin (__main__.testcomplexforward64)  Traceback (most recent call last): File "/home/shstock/downloads/temp/pygsl0.3.2/tests/fft_test.py", line 87, in testSin self.SinOne(x,i) File "/home/shstock/downloads/temp/pygsl0.3.2/tests/fft_test.py", line 75, in SinOne f = self.transform(*((tmp,) + args)) File "src/transform/transformmodule.c", line 71, in PyGSL_transform_fft_complex_forward File "src/transform/transformmodule.c", line 320, in PyGSL_transform_ File "src/init/block_helpers.c", line 45, in PyGSL_PyArray_prepare_gsl_vector_view File "src/init/block_helpers.c", line 102, in PyGSL_PyArray_Check gsl_BadLength: matrix/vector sizes are not conformant: The size of argument 1 did not match the expected size for the 0 dimension. I got 64 elements but expected 4294967295 elements! ====================================================================== ERROR: test_eval_deriv2_e (__main__.spline_linear)  Traceback (most recent call last): File "/home/shstock/downloads/temp/pygsl0.3.2/tests/interpolation_test.py", line 13, in setUp self.interp.init(x,y) File "/qt/3rd64/python2.4.264/lib/python2.4/sitepackages/pygsl/spline.py", line 55, in init self._init(self._ptr, (xa,ya)) File "/qt/3rd64/python2.4.264/lib/python2.4/sitepackages/pygsl/spline.py", line 37, in _init def _init (self, *args): return gslwrap.gsl_spline_init(*args) File "/qt/3rd64/python2.4.264/lib/python2.4/sitepackages/pygsl/gslwrap.py", line 1362, in gsl_spline_init return _gslwrap.gsl_spline_init(*args, **kwargs) File "src/init/block_helpers.c", line 45, in PyGSL_PyArray_prepare_gsl_vector_view File "src/init/block_helpers.c", line 102, in PyGSL_PyArray_Check gsl_BadLength: matrix/vector sizes are not conformant: The size of argument 2 did not match the expected size for the 0 dimension. I got 100 elements but expected 4294967295 elements! ====================================================================== ERROR: test_mean_short (__main__.statistics_test)  Traceback (most recent call last): File "/home/user/downloads/temp/pygsl0.3.2/tests/statistics_test.py", line 65, in test_mean_short self.failIf(short.mean([1,2,3]) != 2) File "src/init/block_helpers.c", line 45, in PyGSL_PyArray_prepare_gsl_vector_view File "src/init/block_helpers.c", line 102, in PyGSL_PyArray_Check gsl_BadLength: matrix/vector sizes are not conformant: The size of argument 1 did not match the expected size for the 0 dimension. I got 3 elements but expected 4294967295 elements!  Stuart Stock 
From: Pierre SCHNIZER <p.schnizer@gs...>  20061004 07:29:48

I attached an "translation" of your code (wavelet2.py) for the numerical part. It is supposed to do no transforms to the arrays for the wavelet transform. This is only done for the real / halfcomplex fourier transform so that the arrays are of complex or real type and the data is reordered to make it more pythonic. As far as I understand wavelets are real to real transforms. So the wrapper is only checking if lengthes are valid, and if a workspace is required to be allocated. In CVS was again a bug for a precompile statement. (Which is fixed now). If you use pygsl 0.3.2 I assume that this bug does not exist. If so, try the CVS version. If you get an GSL_SANITY error, please put the attached file core.c to src/transform/core.c. It would be nice if you could extend the attached example to a real one, (perhaps generate a test signal and transform it, so that one can see what the wavelets are doing). Hoping to hear from you! Sincerely yours Pierre > basically what I need to do is apply the wavelet transform (this is > obtain the wavelet coefficients) to a discrete signal obtained from a > sampled vibration signal, the results of this transformation will be > applied to an algorithm for the compute of the energies of the bands of > frecuency and then obtain a codebook that will be used to obtain a group > of secuencies to be applied to an artificial intelligence software, but > that is another story. I already calculated the wavelet transform of my > vibration signal, I use the following program > > #include <stdio.h> > #include <math.h> > #include <gsl/gsl_wavelet.h> > > int main (int argc, char **argv) > { > int i, n = 512; > double *data = malloc(n * sizeof(double)); > > FILE *f = fopen(argv[1],"r"); > for (i=0; i<n; i++) > { > fscanf(f, "%lg", &data[i]); > } > fclose (f); > > { > gsl_wavelet *w = gsl_wavelet_alloc(gsl_wavelet_daubechies, 4); > gsl_wavelet_workspace *work = gsl_wavelet_workspace_alloc(n); > gsl_wavelet_transform_forward(w,data,1,n,work); > } > > FILE *g = fopen("wavcoef.dat","w"); > for (i=0; i<n; i++) > { > fprintf(g, "%g\n", data[i]); > } > fclose (g); > > return 0; > > , as you can see this is very simple, I just need to know if I can do > this with PyGSL and if the output of the python library is the same as > the GSL C code, I mean the output array with the wavelet coeficcients > has the same order, I think that I can use the example that you include > with PyGSL, if this works everything is ok. > > I had no check the Python code yet but I have to do in this days. So if > your have some other advice I will really thank you. > > Thank you very much. > > On 10/2/06, * Pierre SCHNIZER* <p.schnizer@... > <mailto:p.schnizer@...>> wrote: > > Fernando Vargas wrote: > 
From: Pierre SCHNIZER <p.schnizer@gs...>  20061002 09:58:48

Fernando Vargas wrote: > hi, > > First at all i want to congratulate for your work with PYGSL, this is > very userful. My name is Fernando Vargas, I'm working on a predictive > maintenance system for laboratory tools, this application uses wavelts > as part of the process I'm working with pyhon for the development of > this application and I need to know if you have some documentation or > API about the objets and classes that you use in your wrapper, examples > are very clear about this but some extra documents could be very useful. > > Thanks for your praise. Wavelets are implemented, but I do not know anything about the mathematics behind them. There interface is as for the FFT routines. If you could send me some simple example or a sketch of a use of wavelets, I could show you the different possible optimizations. Basically it is transformed Some documentation exists as __doc__ strings, which python help does not necessarly detect. So if there is no documentation at all try: print foo.__doc__ Sometimes it is necessary to construct an obeject before one can see the associated methods: $ r = pygsl.rng.rng() $ help(r) $ print r.__doc__ $ print dir(r) We tried to follow GSL API as close as possible, but still leaving it pythonic. Unfortunately I have not found the time to write a proper documentation, but would support anybody starting it. Hope that make things more clear. I also just noted that the wavelet transform had a bug if called without arguments. That is now fixed in CVS. If you have questions just mail me, I will try to answer. Sincerely yours Pierre 