Request for "gamma" distribution

[gsever]

Hello,

Is there any plan to add some other distributions mentioned in:

http://hg.sagemath.org/sage-main/file/21efb0b3fc47/sage/gsl/probability_distribution.pyx

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?

[Gokhan Sever]

On Jan 23, 3:04 pm, gsever <gokhanse...@gmail.com> 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 the http://hg.sagemath.org/sage-main/file/21efb0b3fc47/sage/gsl/probability_distribution.pyx
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

[Gokhan Sever]

On Jan 30, 2:11 am, Gokhan Sever <gokhanse...@gmail.com> wrote:
> On Jan 23, 3:04 pm, gsever <gokhanse...@gmail.com> 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?

[William Stein]

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 Washington
http://wstein.org

[Gokhan Sever]

I get it working through a local installation (Fedora 12). Only some
tests fail in tests/block_test.py when I run python run_test.py

I will see if I can install it from within the Sage.

[Gokhan Sever]

Peh,

I hit the same error using Sage v4.3.3 on Fedora 12
(2.6.31.9-174.fc12.i686.PAE)

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)
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)

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/gsever/Desktop/python-
repo/sage-4.3.3/local/include -IInclude -I. -I/home/gsever/Desktop/
python-repo/sage-4.3.3/local/lib/python2.6/site-packages/numpy/core/
include -I/home/gsever/Desktop/python-repo/sage-4.3.3/local/include/
python2.6 -c testing/src/sf/sfmodule_testing.c -o build/temp.linux-
i686-2.6/testing/src/sf/sfmodule_testing.o" failed with exit status 1

Will compiling the package in this fashion mean its ready for
integration with Sage? I was thinking instead of having a separate
package that achieves the same thing have efforts combined in one
place. You mentioned about the slowness, however PyGSL guy was telling
about the advantage of their wrapping method over Cython's. It would
be nice to get some more feedback from both side.

[François Bissey]

> 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.

Just for kicks how do you benchmarks the performance in question?
As a matter of fact since now sage-on-gentoo uses python provided by
the system I can import any python packages installed system wide.
So I imported pygsl that I happen to have installed for another package.

So how do you want to measure performance?

Francois

[schnizer]

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 <wst...@gmail.com> wrote:

[Gokhan Sever]

On Mar 30, 10:15 am, schnizer <p.schni...@gsi.de> wrote:
> 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 onhttp://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

I have made it build after making that change. Using .../sage-4.3.3/
sage -python setup.py build

[Pierre SCHNIZER]

So it means, that the function gsl_exprel_Cn_ is not defined in the gsl
header files ...

Thanks for the info, I will remove it also upstream as it is not listed
in the gsl reference
document.

Sincerely yours
Pierre