headers
Ralf Gommers | 1 Jan 04:11
Gravatar

Re: cephes docstrings editable?


On Fri, Jan 1, 2010 at 12:04 AM, <josef.pktd <at> gmail.com> wrote:
is it possible to edit the cephes doc strings in scipy.special?

for example:
http://docs.scipy.org/scipy/docs/scipy.special._cephes.chdtr/#scipy-special-chdtr

The doc editor allows editing, but doesn't show the source. Are edits
propagated back to wherever the generated (?) doc strings are hiding?



The patch generation indeed has a problem, so it would need some manual work when merging the wiki edit. But don't let that stop you from editing that docstring, the edits will land in svn at some point anyway.

There's already an edit made to cephes.erf http://docs.scipy.org/scipy/docs/scipy.special._cephes.erf/ , which will result in the patch below at the moment.

Cheers,
Ralf


ERROR: scipy.special._cephes.erf: source location for docstring is not known

--- unknown-source-location/scipy.special._cephes.erf.py.old
+++ unknown-source-location/scipy.special._cephes.erf.py
<at> <at> -1,3 +1,39 <at> <at>
# scipy.special._cephes.erf: Source location for docstring not known
def erf():
+ """
+ erf(x[, out])
+
+ Returns the error function of complex argument.
+
+ It is defined as :
+
+ ..math:: 2/\\sqrt(\\pi)*\\int_{t=0..x}(\\exp(-t^2))
+
+ Parameters
+ ----------
+ x : ndarray
+ the error function is computed for each item of x
+
+ Returns
+ -------
+ res : ndarray
+ the values of the error function at the given points x.
+
+ Notes
+ -----
+ The cumulative of the unit normal distribution is given by:
+
+ ..math:: \\Phi(z) = \\frac{1}{2}[1 + erf(\\frac{z}{\\sqrt{2}})]
+
+ References
+ ----------
+ .. [1] http://en.wikipedia.org/wiki/Error_function
+ .. [2] Milton Abramowitz and Irene A. Stegun, eds.
+ Handbook of Mathematical Functions with Formulas,
+ Graphs, and Mathematical Tables. New York: Dover,
+ 1972. http://www.math.sfu.ca/~cbm/aands/page_297.htm
+
+ See : erfc, erfinv, erfcinv
+
+ """
pass

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 0 comments |
headers
Gael Varoquaux | 2 Jan 08:58
Favicon
Gravatar

Re: [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
> [snip]
>   - supporting different variants of the same package in the
> dependency graph at install time

> [snip]

> The second issue is more challenging. It complicates the dependency
> handling quite a bit, and may cause difficult situations to happen at
> dependency resolution time. This becomes particularly messy if you mix
> packages you build yourself with packages grabbed from a repository. I
> wonder if there is a simpler solution which would give a similar
> feature set.

AFAICT, in Debian, the same feature is given via virtual packages: you
would have:

python-matplotlib
python-matplotlib-basemap

for instance.

It is interesting to note that the same source package may be used to
generate both binary, end-user, packages.

And happy new year!

Gaël
Permalink | Reply | 3 comments |
headers
David Warde-Farley | 3 Jan 10:14
Picon
Favicon
Gravatar

Re: [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

On 29-Dec-09, at 9:22 AM, David Cournapeau wrote:

> I think Pypi is mostly useless. The lack of enforced metadata is a big
> no-no IMHO. The fact that Pypi is miles beyond CRAN for example is
> quite significant. I want CRAN for scientific python, and I don't see
> Pypi becoming it in the near future.

Agreed. The amount of times I have seen packages on the RSS feed that  
have no package description, no external URL, no author contact  
info... Not to mention the huge preponderance of  
plone.basketweaving.underwater packages or other plugins that really  
don't interest me but I have no good way to filter out (not that  
there's anything wrong with plone, but it's a general problem with a  
lack of namespace-awareness).

David, the description of toydist sounds fantastic, and there's nobody  
I'd trust more to have thought through the design of such a beast.  
Happy New Year to you and yours. :)

David
Permalink | Reply | 0 comments |
headers
David Cournapeau | 3 Jan 13:23
Picon

Re: [matplotlib-devel] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith <njs <at> pobox.com> wrote:
> On Tue, Dec 29, 2009 at 6:34 AM, David Cournapeau <cournape <at> gmail.com> wrote:
>> Buildout, virtualenv all work by sandboxing from the system python:
>> each of them do not see each other, which may be useful for
>> development, but as a deployment solution to the casual user who may
>> not be familiar with python, it is useless. A scientist who installs
>> numpy, scipy, etc... to try things out want to have everything
>> available in one python interpreter, and does not want to jump to
>> different virtualenvs and whatnot to try different packages.
>
> What I do -- and documented for people in my lab to do -- is set up
> one virtualenv in my user account, and use it as my default python. (I
> 'activate' it from my login scripts.) The advantage of this is that
> easy_install (or pip) just works, without any hassle about permissions
> etc.

It just works if you happen to be able to build everything from
sources. That alone means you ignore the majority of users I intend to
target.

No other community (except maybe Ruby) push those isolated install
solutions as a general deployment solutions. If it were such a great
idea, other people would have picked up those solutions.

> This should be easier, but I think the basic approach is sound.
> "Integration with the package system" is useless; the advantage of
> distribution packages is that distributions can provide a single
> coherent system with consistent version numbers across all packages,
> etc., and the only way to "integrate" with that is to, well, get the
> packages into the distribution.

Another way is to provide our own repository for a few major
distributions, with automatically built packages. This is how most
open source providers work. Miguel de Icaza explains this well:

http://tirania.org/blog/archive/2007/Jan-26.html

I hope we will be able to reuse much of the opensuse build service
infrastructure.

>
> On another note, I hope toydist will provide a "source prepare" step,
> that allows arbitrary code to be run on the source tree. (For, e.g.,
> cython->C conversion, ad-hoc template languages, etc.) IME this is a
> very common pain point with distutils; there is just no good way to do
> it, and it has to be supported in the distribution utility in order to
> get everything right. In particular:
>  -- Generated files should never be written to the source tree
> itself, but only the build directory
>  -- Building from a source checkout should run the "source prepare"
> step automatically
>  -- Building a source distribution should also run the "source
> prepare" step, and stash the results in such a way that when later
> building the source distribution, this step can be skipped. This is a
> common requirement for user convenience, and necessary if you want to
> avoid arbitrary code execution during builds.

Build directories are hard to implement right. I don't think toydist
will support this directly. IMO, those advanced builds warrant a real
build tool - one main goal of toydist is to make integration with waf
or scons much easier. Both waf and scons have the concept of a build
directory, which should do everything you described.

David
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 5 comments |
headers
josef.pktd | 3 Jan 16:40
Picon

namespace recommendation in scipy tutorial and docs for np.emath

I'm going through some scipy tickets and I found
http://projects.scipy.org/scipy/ticket/882

I don't know much about the old usage of mixing (mixed up) namespaces.
But I think it would be good if someone could check the namespace
convention/recommendation in the basic scipy tutorial

http://docs.scipy.org/doc/scipy/reference/tutorial/basic.html

When I tried to figure out the difference between scipy.* and numpy.*,
I also found that the functions in numpy.emath (numpy.scipy) have good
docstrings, but they are not included in the docs (at least I don't
find them), because
http://docs.scipy.org/numpy/docs/numpy-docs/reference/routines.emath.rst/#numpy-docs-reference-routines-emath-rst
is still a stub page without function links.
http://docs.scipy.org/doc/numpy/reference/routines.emath.html

Josef
Permalink | Reply | 2 comments |
headers
Arkapravo Bhaumik | 3 Jan 20:19
Picon
Gravatar

Module for test for convergence ?

Hello everyone ! 


Wish you all a very happy new year ! 

I had a question ! Is there any scipy module for confirming convergence of a series, given the generic term of tn ? If not, have any of you tried to write such a module ? 

I have been searching MATLAB, I doubt that there is any such facility ? 

Regards

Arkapravo




_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 1 comment |
headers
David Warde-Farley | 4 Jan 01:18
Picon
Favicon
Gravatar

Re: Module for test for convergence ?

On 3-Jan-10, at 2:19 PM, Arkapravo Bhaumik wrote:

> I had a question ! Is there any scipy module for confirming  
> convergence of a series, given the generic term of tn ? If not, have  
> any of you tried to write such a module ?

This would be more a task for SymPy.

David
Permalink | Reply | 0 comments |
headers
Arkapravo Bhaumik | 4 Jan 02:42
Picon
Gravatar

Zeta Functions !

Dear Friends

I found some serious discrepancies with the zeta function modules. I have discussed them in my blogspot : http://3chevrons.blogspot.com/2010/01/zeta-in-scipy.html . Please feel free to comment on it, any other suggestion to improve the module is welcome.

Regards

Arkapravo

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 2 comments |
headers
Warren Weckesser | 4 Jan 03:38
Gravatar

Re: Zeta Functions !

I don't know the reason for the names of the functions, but it appears 
that the function that you should use to compute the zeta function for 
an arbitrary argument is zetac(x) + 1:

In [1]: from scipy.special import zeta, zetac

In [2]: zetac(0) + 1
Out[2]: -0.5

In [3]: zetac(-1) + 1
Out[3]: -0.083333333333333259

In [4]: zetac(0.5) + 1
Out[4]: -1.4603545088095866

In [5]: zetac(1) + 1
Out[5]: 1.7014118346046923e+38

In [6]: zetac(2) + 1
Out[6]: 1.6449340668482264

In [7]: zetac(-2) + 1
Out[7]: 0.0

zeta() and zetac() are wrappers for functions from the cephes library; 
you can find the source code at the end of this list:

    http://projects.scipy.org/scipy/browser/trunk/scipy/special/cephes

In the C file zeta.c, you can see that zeta(x,q) returns NaN if x < 1.0.

Of course, a SciPy user should not have to dig into the C code to find 
this out.  Clearly the docstrings for zeta() and zetac() should be improved.

Warren

P.S. Be careful: don't forget the 1/2 is zero, unless you are using 
Python 3.

Arkapravo Bhaumik wrote:
> Dear Friends
>
> I found some serious discrepancies with the zeta function modules. I 
> have discussed them in my blogspot 
> : http://3chevrons.blogspot.com/2010/01/zeta-in-scipy.html . Please 
> feel free to comment on it, any other suggestion to improve the module 
> is welcome.
>
> Regards
>
> Arkapravo
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev <at> scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
Permalink | Reply | 1 comment |
headers
josef.pktd | 4 Jan 04:07
Picon

Re: Zeta Functions !

On Sun, Jan 3, 2010 at 9:38 PM, Warren Weckesser
<warren.weckesser <at> enthought.com> wrote:
> I don't know the reason for the names of the functions, but it appears
> that the function that you should use to compute the zeta function for
> an arbitrary argument is zetac(x) + 1:
>
> In [1]: from scipy.special import zeta, zetac
>
> In [2]: zetac(0) + 1
> Out[2]: -0.5
>
> In [3]: zetac(-1) + 1
> Out[3]: -0.083333333333333259
>
> In [4]: zetac(0.5) + 1
> Out[4]: -1.4603545088095866
>
> In [5]: zetac(1) + 1
> Out[5]: 1.7014118346046923e+38
>
> In [6]: zetac(2) + 1
> Out[6]: 1.6449340668482264
>
> In [7]: zetac(-2) + 1
> Out[7]: 0.0
>
>
> zeta() and zetac() are wrappers for functions from the cephes library;
> you can find the source code at the end of this list:
>
>    http://projects.scipy.org/scipy/browser/trunk/scipy/special/cephes
>
> In the C file zeta.c, you can see that zeta(x,q) returns NaN if x < 1.0.
>
> Of course, a SciPy user should not have to dig into the C code to find
> this out.  Clearly the docstrings for zeta() and zetac() should be improved.

c at end of name usually stands for complement, only in this case the
docstring for zetac gets it wrong.

y=zetac(x) returns 1.0 - the Riemann zeta function: sum(k**(-x), k=2..inf)

In the c source you linked to, it says

25	 * is related to the Riemann zeta function by
26	 *
27	 *      Riemann zeta(x) = zetac(x) + 1.

for scipy.special (and lapack) the docs is usually better (or only
exist) in the c or fortran files.

Josef

>
>
> Warren
>
> P.S. Be careful: don't forget the 1/2 is zero, unless you are using
> Python 3.
>
>
> Arkapravo Bhaumik wrote:
>> Dear Friends
>>
>> I found some serious discrepancies with the zeta function modules. I
>> have discussed them in my blogspot
>> : http://3chevrons.blogspot.com/2010/01/zeta-in-scipy.html . Please
>> feel free to comment on it, any other suggestion to improve the module
>> is welcome.
>>
>> Regards
>>
>> Arkapravo
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev <at> scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev <at> scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
Permalink | Reply | 0 comments |

Gmane