Hello, I am one of the pygsl authors. If there is interest, I am sure that one can get this module up and running. As I see the module fails in the last module. Apparently the function is not defined in the header files; this particular function is not listed in the reference doc.
I upload a tar file on http://pygsl.sourceforge.net/pygsl_sf_testing.tar.gz So if you want participate in identifiying the error please: 1. extract pygsl-0.9.5.tar.gz 2. change into this directory pygsl-0.9.5 3. extract the tar achieve pygsl_sf_testing.tar.gz The 3d step will replace the files without the offending error. Please send the ouput so that I can see what is going wrong ... Sincerely yours Pierre On 26 Mrz., 18:07, William Stein <[email protected]> wrote: > On Fri, Mar 26, 2010 at 8:35 AM, Gokhan Sever <[email protected]> wrote: > > > On Jan 30, 2:11 am, Gokhan Sever <[email protected]> wrote: > >> On Jan 23, 3:04 pm, gsever <[email protected]> wrote: > > >> > Hello, > > >> > Is there any plan to add some other distributions mentioned in: > > >> >http://hg.sagemath.org/sage-main/file/21efb0b3fc47/sage/gsl/probabili... > > >> > 50 #TODO: Add more distributions available in gsl > >> > 51 #available but not currently wrapped are exponential, laplace, > >> > cauchy, landau, gamma, > >> > 52 #gamma, beta logistic. > > >> > particularly, the "gamma" one? > > >> I have been working on > >> thehttp://hg.sagemath.org/sage-main/file/21efb0b3fc47/sage/gsl/probabili... > >> file for a few days. I have completed the TODO list except the > >> doctests. However while looking at the GSL manual (http://www.gnu.org/ > >> software/gsl/manual/html_node/Random-Number-Distributions.html) I have > >> realized that some functionality is missing in this wrapper. > >> (Particulary CDF's for Q and inverse CDF Q's) I am not sure why these > >> are skipped in the wrapper. > > >> Moreover while browsing for the other language bindings I have come > >> across almost a full binding from Perl guys using SWIG > >> -...@http://search.cpan.org/~leto/Math-GSL/ > >> They are approach is different what is currently implemented for the > >> SAGE's. They automate the binding process throughout the templates. > >> Could someone enlighten me why SAGE takes the manual approach? (No > >> need for that sophisticated wrapping or lack or man-power / time type > >> of deal?) > > >> Once these questions of mine answered I would continue working where I > >> have left the code. I also sent an e-mail asking PyGSL guys to improve > >> the GSL-SAGE integration further. > > >> Thanks for your time. > > >> Gökhan > > > Is there any input for this matter? > > > PyGSL (http://sourceforge.net/projects/pygsl/) developer have > > contacted me back. He says SAGE's and his approach to wrap the C code > > is different, and his way provides more elegant Pythonic API. As far > > as I know he wraps a greater portion of the GSL. > > > What do you think? Would these ways get advantage from each other? Or > > could paths be simplified into a combined path? > > I just tried PyGSL -- I downloaded the tarball, change into the > pygsl-0.9.5 directory, and typed > > sage -python setup.py > > Unfortunately, the build fails for me under OS X and Ubuntu 8.10 Linux > with Sage-4.3.4: > > In file included from testing/src/sf/sfmodule_testing.c:49: > testing/src/sf/sf__data.c:779: error: ‘gsl_sf_exprel_n_CF_e’ > undeclared here (not in a function) > testing/src/sf/sfmodule_testing.c:102: warning: initialization from > incompatible pointer type > testing/src/sf/sfmodule_testing.c:102: warning: initialization from > incompatible pointer type > testing/src/sf/sfmodule_testing.c:145: warning: initialization from > incompatible pointer type > testing/src/sf/sfmodule_testing.c:145: warning: initialization from > incompatible pointer type > testing/src/sf/sfmodule_testing.c: In function ‘init_ufuncs’: > testing/src/sf/sfmodule_testing.c:167: warning: cast from pointer to > integer of different size > error: Command "gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes -fPIC -DSWIG_COBJECT_TYPES=1 -DGSL_RANGE_CHECK=1 > -DDEBUG=1 -DNUMERIC=0 -DPYGSL_GSL_MAJOR_VERSION=1 > -DPYGSL_GSL_MINOR_VERSION=10 -UNDEBUG > -I/home/wstein/build/production/sage/local/include -IInclude -I. > -I/home/wstein/build/production/sage/local/lib/python2.6/site-packages/numpy/core/include > -I/home/wstein/build/production/sage/local/include/python2.6 -c > testing/src/sf/sfmodule_testing.c -o > build/temp.linux-x86_64-2.6/testing/src/sf/sfmodule_testing.o" failed > with exit status 1 > > --- > > If somebody gets PyGSL to work, that would be very good (it would be > great to have an optional spkg!). Please note one issue though, which > is that SWIG wrappers (PyGSL is a swig wrapper) have a significant > *performance* penalty. > > -- William > > -- > William Stein > Associate Professor of Mathematics > University of Washingtonhttp://wstein.org -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
