From mtrumpis at berkeley.edu  Mon Jun  1 18:39:48 2009
From: mtrumpis at berkeley.edu (M Trumpis)
Date: Mon, 1 Jun 2009 15:39:48 -0700
Subject: [SciPy-dev] scipy SVD with alternate lapack driver
Message-ID: <be3bc680906011539w1306e71r15f3cd2f27ed1299@mail.gmail.com>

Hi all.. I posted on the numpy list a few months back about running
into some unstable SVD behavior, namely 1) a non-converging SVD and 2)
negative singular values. My colleagues and I got curious when MATLAB
and Octave did not fail or give bogus results for the two operators.
Based on the Octave code and some testing with the lapack drivers, it
would appear that using the *GESVD family of drivers is more robust in
the face of these corner cases than the *GESDD drivers.

So after leaving off for months, I finally went back to fixing this
up. Using a lot of monkey-see-monkey-do, I added the f2py function
signatures for the *GESVD functions, hopefully sane code in
calc_lwork.f, and wrote up a bit of python in linalg/decomp.py, with
some appropriate testing. I haven't submitted a patch to scipy yet..
Can I just post the "svn diff" with a description of the issue at hand
on the Trac site? Although it does look like it's working, I haven't
tested it extensively yet. And I was *very* ignorantly hacking at the
Fortran / f2py bits.

Hope this is helpful.

Kind regards,
Mike


From mtrumpis at berkeley.edu  Mon Jun  1 18:39:59 2009
From: mtrumpis at berkeley.edu (M Trumpis)
Date: Mon, 1 Jun 2009 15:39:59 -0700
Subject: [SciPy-dev] scipy SVD with alternate lapack driver
Message-ID: <be3bc680906011539i42eb978eube467d3741327a2@mail.gmail.com>

Hi all.. I posted on the numpy list a few months back about running
into some unstable SVD behavior, namely 1) a non-converging SVD and 2)
negative singular values. My colleagues and I got curious when MATLAB
and Octave did not fail or give bogus results for the two operators.
Based on the Octave code and some testing with the lapack drivers, it
would appear that using the *GESVD family of drivers is more robust in
the face of these corner cases than the *GESDD drivers.

So after leaving off for months, I finally went back to fixing this
up. Using a lot of monkey-see-monkey-do, I added the f2py function
signatures for the *GESVD functions, hopefully sane code in
calc_lwork.f, and wrote up a bit of python in linalg/decomp.py, with
some appropriate testing. I haven't submitted a patch to scipy yet..
Can I just post the "svn diff" with a description of the issue at hand
on the Trac site? Although it does look like it's working, I haven't
tested it extensively yet. And I was *very* ignorantly hacking at the
Fortran / f2py bits.

Hope this is helpful.

Kind regards,
Mike


From robert.kern at gmail.com  Mon Jun  1 18:45:01 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 1 Jun 2009 17:45:01 -0500
Subject: [SciPy-dev] scipy SVD with alternate lapack driver
In-Reply-To: <be3bc680906011539w1306e71r15f3cd2f27ed1299@mail.gmail.com>
References: <be3bc680906011539w1306e71r15f3cd2f27ed1299@mail.gmail.com>
Message-ID: <3d375d730906011545q7149e9a3jf93873568f5e8d92@mail.gmail.com>

On Mon, Jun 1, 2009 at 17:39, M Trumpis <mtrumpis at berkeley.edu> wrote:
> Hi all.. I posted on the numpy list a few months back about running
> into some unstable SVD behavior, namely 1) a non-converging SVD and 2)
> negative singular values. My colleagues and I got curious when MATLAB
> and Octave did not fail or give bogus results for the two operators.
> Based on the Octave code and some testing with the lapack drivers, it
> would appear that using the *GESVD family of drivers is more robust in
> the face of these corner cases than the *GESDD drivers.
>
> So after leaving off for months, I finally went back to fixing this
> up. Using a lot of monkey-see-monkey-do, I added the f2py function
> signatures for the *GESVD functions, hopefully sane code in
> calc_lwork.f, and wrote up a bit of python in linalg/decomp.py, with
> some appropriate testing. I haven't submitted a patch to scipy yet..
> Can I just post the "svn diff" with a description of the issue at hand
> on the Trac site?

Create a new ticket, and attach the .diff to it. At the bottom of the
"New Ticket" form is a check-box: "I have files to attach to this
ticket". Make sure that is checked, and you will be prompted for the
file.

> Although it does look like it's working, I haven't
> tested it extensively yet. And I was *very* ignorantly hacking at the
> Fortran / f2py bits.

For adding new LAPACK wrappers, that technique tends to work fairly well.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From mtrumpis at berkeley.edu  Mon Jun  1 19:42:49 2009
From: mtrumpis at berkeley.edu (M Trumpis)
Date: Mon, 1 Jun 2009 16:42:49 -0700
Subject: [SciPy-dev] scipy SVD with alternate lapack driver
In-Reply-To: <3d375d730906011545q7149e9a3jf93873568f5e8d92@mail.gmail.com>
References: <be3bc680906011539w1306e71r15f3cd2f27ed1299@mail.gmail.com>
	<3d375d730906011545q7149e9a3jf93873568f5e8d92@mail.gmail.com>
Message-ID: <be3bc680906011642v7e75ed35y9a2ee6bc1705d777@mail.gmail.com>

ok.. Thanks for the help.

http://projects.scipy.org/scipy/ticket/957

Mike

On Mon, Jun 1, 2009 at 3:45 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Mon, Jun 1, 2009 at 17:39, M Trumpis <mtrumpis at berkeley.edu> wrote:
>> Hi all.. I posted on the numpy list a few months back about running
>> into some unstable SVD behavior, namely 1) a non-converging SVD and 2)
>> negative singular values. My colleagues and I got curious when MATLAB
>> and Octave did not fail or give bogus results for the two operators.
>> Based on the Octave code and some testing with the lapack drivers, it
>> would appear that using the *GESVD family of drivers is more robust in
>> the face of these corner cases than the *GESDD drivers.
>>
>> So after leaving off for months, I finally went back to fixing this
>> up. Using a lot of monkey-see-monkey-do, I added the f2py function
>> signatures for the *GESVD functions, hopefully sane code in
>> calc_lwork.f, and wrote up a bit of python in linalg/decomp.py, with
>> some appropriate testing. I haven't submitted a patch to scipy yet..
>> Can I just post the "svn diff" with a description of the issue at hand
>> on the Trac site?
>
> Create a new ticket, and attach the .diff to it. At the bottom of the
> "New Ticket" form is a check-box: "I have files to attach to this
> ticket". Make sure that is checked, and you will be prompted for the
> file.
>
>> Although it does look like it's working, I haven't
>> tested it extensively yet. And I was *very* ignorantly hacking at the
>> Fortran / f2py bits.
>
> For adding new LAPACK wrappers, that technique tends to work fairly well.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> ?-- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From fperez.net at gmail.com  Tue Jun  2 01:20:29 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 1 Jun 2009 22:20:29 -0700
Subject: [SciPy-dev] Tutorial topics for SciPy'09 Conference
Message-ID: <db6b5ecc0906012220x3bac55d9l95fb7bf97ce2c46c@mail.gmail.com>

Hi all,

The time for the Scipy'09 conference is rapidly approaching, and we
would like to both announce the plan for tutorials and solicit
feedback from everyone on topics of interest.

Broadly speaking, the plan is something along the lines of  what we
had last year: one continuous 2-day tutorial  aimed at introductory
users, starting from the very basics, and in parallel a set of
'advanced' tutorials, consisting of a series of 2-hour sessions on
specific  topics.

We will request that the presenters for the advanced tutorials keep
the 'tutorial' word very much in mind, so that the sessions really
contain hands-on learning work and not simply a 2-hour long slide
presentation.  We will  thus require that all the tutorials will be
based on tools that the attendees can install at least 2 weeks in
advance on all  platforms (no "I released it last night" software).

With that in mind, we'd like feedback from all of you on possible
topics for the advanced tutorials.  We have space for 8 slots total,
and here are in no particular order some possible topics.  At this
point there are no guarantees yet that we can get presentations for
these, but we'd like to establish a first list of preferred topics to
try and secure the presentations as soon as possible.

This is simply a list of candiate topics that various people have
informally suggested so far:

- Mayavi/TVTK
- Advanced topics in matplotlib
- Statistics with Scipy
- The TimeSeries scikit
- Designing scientific interfaces with Traits
- Advanced numpy
- Sparse Linear Algebra with Scipy
- Structured and record arrays in numpy
- Cython
- Sage - general tutorial
- Sage - specific topics, suggestions welcome
- Using GPUs with PyCUDA
- Testing strategies for scientific codes
- Parallel processing and mpi4py
- Graph theory with Networkx
- Design patterns for efficient iterator-based scientific codes.
- Symbolic computing with sympy

We'd like to hear from any ideas on other possible topics of interest,
and we'll then run a doodle poll  to gather quantitative feedback with
the final list of candidates.

Many thanks,

f


From nwagner at iam.uni-stuttgart.de  Tue Jun  2 14:05:34 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 02 Jun 2009 20:05:34 +0200
Subject: [SciPy-dev] OperationalError: database is locked
Message-ID: <web-120763930@uni-stuttgart.de>

Hi all,

I cannot access http://projects.scipy.org/scipy/timeline .
Is it a temporary problem ?

Nils


From lists.20.chth at xoxy.net  Tue Jun  2 16:56:57 2009
From: lists.20.chth at xoxy.net (ctw)
Date: Tue, 2 Jun 2009 16:56:57 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
Message-ID: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>

I just wanted to give you a heads up that I came across a bug in
scipy.stats._chk_asarray.
I have updated the corresponding review page (
http://projects.scipy.org/scipy/ticket/44 ) with the following
comment:

_chk_asarray does not respect the class of the input. If the input is
a subclass of numpy.ndarray _chk_asarray will transform it into an
ndarray. This can lead to undesirable consequences in functions that
call _chk_asarray (e.g., scipy.stats.nanmean).

Simple example:
>>> tst = matrix(range(4))
>>> scipy.stats.nanmean(tst)
 array([0., 1., 2., 3.])
>>> np.mean(tst,0)
 matrix([[0., 1., 2., 3.]])

The problem is the call to np.asarray() which should only be made for
input that is not an ndarray instance. I just committed a
corresponding fix via SVN.


From robert.kern at gmail.com  Tue Jun  2 17:03:29 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 2 Jun 2009 16:03:29 -0500
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
Message-ID: <3d375d730906021403j59f13c5cg82dda5397075606@mail.gmail.com>

On Tue, Jun 2, 2009 at 15:56, ctw <lists.20.chth at xoxy.net> wrote:
> I just wanted to give you a heads up that I came across a bug in
> scipy.stats._chk_asarray.
> I have updated the corresponding review page (
> http://projects.scipy.org/scipy/ticket/44 ) with the following
> comment:
>
> _chk_asarray does not respect the class of the input. If the input is
> a subclass of numpy.ndarray _chk_asarray will transform it into an
> ndarray. This can lead to undesirable consequences in functions that
> call _chk_asarray (e.g., scipy.stats.nanmean).
>
> Simple example:
>>>> tst = matrix(range(4))
>>>> scipy.stats.nanmean(tst)
> ?array([0., 1., 2., 3.])
>>>> np.mean(tst,0)
> ?matrix([[0., 1., 2., 3.]])
>
> The problem is the call to np.asarray() which should only be made for
> input that is not an ndarray instance. I just committed a
> corresponding fix via SVN.

Please revert that. Some of those functions rely on the result of
_chk_asarray() being a real ndarray. For example, nanstd() uses an
exponent, which will be misinterpreted by a matrix object:

In [1]: from scipy.stats import nanstd

In [2]: m = matrix(range(4))

In [3]: nanstd(m)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/Users/rkern/<ipython console> in <module>()

/Users/rkern/svn/scipy/scipy/stats/stats.py in nanstd(x, axis, bias)
    312         d = d.transpose(shape)
    313     else:
--> 314         d = (x-m1)**2.0
    315     m2 = np.sum(d,axis)-(m1*m1)*Nnan
    316     if bias:

/Users/rkern/svn/numpy/numpy/core/defmatrix.pyc in __pow__(self, other)
    301
    302     def __pow__(self, other):
--> 303         return matrix_power(self, other)
    304
    305     def __ipow__(self, other):

/Users/rkern/svn/numpy/numpy/core/defmatrix.pyc in matrix_power(M, n)
    117     """
    118     if len(M.shape) != 2 or M.shape[0] != M.shape[1]:
--> 119         raise ValueError("input must be a square array")
    120     if not issubdtype(type(n),int):
    121         raise TypeError("exponent must be an integer")

ValueError: input must be a square array

In [4]: nanstd(range(4))
Out[4]: 1.2909944487358056


-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From pav at iki.fi  Tue Jun  2 17:07:15 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 2 Jun 2009 21:07:15 +0000 (UTC)
Subject: [SciPy-dev] OperationalError: database is locked
References: <web-120763930@uni-stuttgart.de>
Message-ID: <h044a2$kbr$2@ger.gmane.org>

Tue, 02 Jun 2009 20:05:34 +0200, Nils Wagner wrote:
> I cannot access http://projects.scipy.org/scipy/timeline . Is it a
> temporary problem ?

Should be temporary. Some Trac instances seem to hang around for some 
minutes, keeping the DB locked from others... No idea what they are doing.

-- 
Pauli Virtanen



From pgmdevlist at gmail.com  Tue Jun  2 17:14:19 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Tue, 2 Jun 2009 17:14:19 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <3d375d730906021403j59f13c5cg82dda5397075606@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<3d375d730906021403j59f13c5cg82dda5397075606@mail.gmail.com>
Message-ID: <7FD3987A-DF85-40CF-B824-883A83034A94@gmail.com>


On Jun 2, 2009, at 5:03 PM, Robert Kern wrote:

> On Tue, Jun 2, 2009 at 15:56, ctw <lists.20.chth at xoxy.net> wrote:
>> I just wanted to give you a heads up that I came across a bug in
>> scipy.stats._chk_asarray.
>> I have updated the corresponding review page (
>> http://projects.scipy.org/scipy/ticket/44 ) with the following
>> comment:
>>
>> _chk_asarray does not respect the class of the input.

On purpose, as pointed out by Robert.

Now, for simple operations like that, you can use masked arrays:
 >>>  mx=ma.array(matrix(range(4)))
 >>> mx.mean(0)
masked_matrix(data =
  [[0.0 1.0 2.0 3.0]],
               mask =
  [[False False False False]],
         fill_value = 999999)
 >>> mx.mean(0).data
  matrix([[ 0.,  1.,  2.,  3.]])


From lists.20.chth at xoxy.net  Tue Jun  2 17:20:10 2009
From: lists.20.chth at xoxy.net (ctw)
Date: Tue, 2 Jun 2009 17:20:10 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
Message-ID: <c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>

> Please revert that.

Done! Sorry about that. I am having some issues with the current
behavior of changing all inputs to ndarrays. Would it be possible to
add a nanmean function to numpy that behaves just as np.nansum in the
sense that it preserves the type of the input?


From robert.kern at gmail.com  Tue Jun  2 17:58:25 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 2 Jun 2009 16:58:25 -0500
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com> 
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
Message-ID: <3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>

On Tue, Jun 2, 2009 at 16:20, ctw <lists.20.chth at xoxy.net> wrote:
>> Please revert that.
>
> Done! Sorry about that. I am having some issues with the current
> behavior of changing all inputs to ndarrays. Would it be possible to
> add a nanmean function to numpy that behaves just as np.nansum in the
> sense that it preserves the type of the input?

I would prefer a comprehensive approach rather than hacking in the one
function you want. I wouldn't be opposed to more NaN-aware functions
in numpy if they were corralled into their own module. However, that
leaves all of the rest of scipy.stats untouched.

Alternately, you could help write a decorator that would wrap a
function to cast its arguments to ndarrays (bonus points: any
specified subclass) and then cast the result(s) back to the
appropriate subclass determined by the inputs' classes according to
the ufunc rules. You just have to be careful to deal with functions
that take multiple arraylike and non-arraylike inputs and return
multiple outputs (some of which aren't arraylike, either). This would
take some care, but would be a great asset to numpy.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From josef.pktd at gmail.com  Tue Jun  2 23:09:05 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 2 Jun 2009 23:09:05 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
Message-ID: <1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>

On Tue, Jun 2, 2009 at 5:58 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Tue, Jun 2, 2009 at 16:20, ctw <lists.20.chth at xoxy.net> wrote:
>>> Please revert that.
>>
>> Done! Sorry about that. I am having some issues with the current
>> behavior of changing all inputs to ndarrays. Would it be possible to
>> add a nanmean function to numpy that behaves just as np.nansum in the
>> sense that it preserves the type of the input?
>
> I would prefer a comprehensive approach rather than hacking in the one
> function you want. I wouldn't be opposed to more NaN-aware functions
> in numpy if they were corralled into their own module. However, that
> leaves all of the rest of scipy.stats untouched.
>
> Alternately, you could help write a decorator that would wrap a
> function to cast its arguments to ndarrays (bonus points: any
> specified subclass) and then cast the result(s) back to the
> appropriate subclass determined by the inputs' classes according to
> the ufunc rules. You just have to be careful to deal with functions
> that take multiple arraylike and non-arraylike inputs and return
> multiple outputs (some of which aren't arraylike, either). This would
> take some care, but would be a great asset to numpy.
>

I tried to see if I can introduce a second version _check_asanyarray,
that doesn't convert to basic np.array, but I didn't get very far.
nanmedian, and nanstd are not easy to convert to work with matrices,
nanstd uses multiplication and nanmedian uses np.compress

I usually avoid matrices because it is too confusing in numpy to keep
track of the type for the basic operations.

As an alternative, I looked at np.core.fromnumeric._wrapit, which is
the wrapper for np.mean

Doing a variation on it seems to work for matrices, see below. I
haven't tried it on other array types. This is just a trial balloon to
see whether this would make sense for some of the stats functions. It
would be relevant mostly for the descriptive statistics, the
statistical tests just return test statistics and pvalues, the plan
for models is that they get explicit array subclass handling.

Is this a good idea to try to work this way?
And what is the best way to check whether an array is a plain ndarray
and not a subclass instance?
something like this ?
>>> isinstance(np.matrix(range(4)),np.ndarray)
True
>>> np.matrix(range(4)).__class__ is np.ndarray
False
>>> np.arange(5).__class__ is np.ndarray
True

Josef

--------------------
import numpy as np
from scipy import stats

def _wrapit(obj, method, *args, **kwds):
    try:
        wrap = obj.__array_wrap__
    except AttributeError:
        wrap = None
    #result = getattr(asarray(obj),method)(*args, **kwds)
    result = getattr(stats,method)(obj, *args, **kwds)
    if wrap:
        if not isinstance(result, np.ndarray):
            result = np.asarray(result)
        result = wrap(result)
    return result

ex = [ [np.nan, np.nan],
       np.matrix(range(4)), np.mat(np.ones((5,3))*range(1,4)) ]
ops = ['nanmean', 'nanstd', 'nanmedian']

for oname in ops:
    print
    for e in ex:
        ea = np.asanyarray(e)
        res = _wrapit(ea, oname)
        print 'wrapped stats.' + oname + \
                '(%r) = '% e, res, res.__class__


From charlesr.harris at gmail.com  Tue Jun  2 23:40:41 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 2 Jun 2009 21:40:41 -0600
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
Message-ID: <e06186140906022040k38926d20r6e1a1a16f506c948@mail.gmail.com>

On Tue, Jun 2, 2009 at 9:09 PM, <josef.pktd at gmail.com> wrote:

> On Tue, Jun 2, 2009 at 5:58 PM, Robert Kern <robert.kern at gmail.com> wrote:
> > On Tue, Jun 2, 2009 at 16:20, ctw <lists.20.chth at xoxy.net> wrote:
> >>> Please revert that.
> >>
> >> Done! Sorry about that. I am having some issues with the current
> >> behavior of changing all inputs to ndarrays. Would it be possible to
> >> add a nanmean function to numpy that behaves just as np.nansum in the
> >> sense that it preserves the type of the input?
> >
> > I would prefer a comprehensive approach rather than hacking in the one
> > function you want. I wouldn't be opposed to more NaN-aware functions
> > in numpy if they were corralled into their own module. However, that
> > leaves all of the rest of scipy.stats untouched.
> >
> > Alternately, you could help write a decorator that would wrap a
> > function to cast its arguments to ndarrays (bonus points: any
> > specified subclass) and then cast the result(s) back to the
> > appropriate subclass determined by the inputs' classes according to
> > the ufunc rules. You just have to be careful to deal with functions
> > that take multiple arraylike and non-arraylike inputs and return
> > multiple outputs (some of which aren't arraylike, either). This would
> > take some care, but would be a great asset to numpy.
> >
>
> I tried to see if I can introduce a second version _check_asanyarray,
> that doesn't convert to basic np.array, but I didn't get very far.
> nanmedian, and nanstd are not easy to convert to work with matrices,
> nanstd uses multiplication and nanmedian uses np.compress
>
> I usually avoid matrices because it is too confusing in numpy to keep
> track of the type for the basic operations.
>
> As an alternative, I looked at np.core.fromnumeric._wrapit, which is
> the wrapper for np.mean
>
> Doing a variation on it seems to work for matrices, see below. I
> haven't tried it on other array types. This is just a trial balloon to
> see whether this would make sense for some of the stats functions. It
> would be relevant mostly for the descriptive statistics, the
> statistical tests just return test statistics and pvalues, the plan
> for models is that they get explicit array subclass handling.
>
> Is this a good idea to try to work this way?
> And what is the best way to check whether an array is a plain ndarray
> and not a subclass instance?
> something like this ?
> >>> isinstance(np.matrix(range(4)),np.ndarray)
> True
> >>> np.matrix(range(4)).__class__ is np.ndarray
> False
> >>> np.arange(5).__class__ is np.ndarray
> True
>

The linear algebra routines do a lot of that _wrapit stuff so that they can
handle both ndarrays and matrices. They might be useful examples.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090602/6029aa01/attachment.html>

From josef.pktd at gmail.com  Wed Jun  3 00:07:16 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 00:07:16 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <e06186140906022040k38926d20r6e1a1a16f506c948@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<e06186140906022040k38926d20r6e1a1a16f506c948@mail.gmail.com>
Message-ID: <1cd32cbb0906022107t5bcd1fc3u3d85548114ea8e19@mail.gmail.com>

On Tue, Jun 2, 2009 at 11:40 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Tue, Jun 2, 2009 at 9:09 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Tue, Jun 2, 2009 at 5:58 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> > On Tue, Jun 2, 2009 at 16:20, ctw <lists.20.chth at xoxy.net> wrote:
>> >>> Please revert that.
>> >>
>> >> Done! Sorry about that. I am having some issues with the current
>> >> behavior of changing all inputs to ndarrays. Would it be possible to
>> >> add a nanmean function to numpy that behaves just as np.nansum in the
>> >> sense that it preserves the type of the input?
>> >
>> > I would prefer a comprehensive approach rather than hacking in the one
>> > function you want. I wouldn't be opposed to more NaN-aware functions
>> > in numpy if they were corralled into their own module. However, that
>> > leaves all of the rest of scipy.stats untouched.
>> >
>> > Alternately, you could help write a decorator that would wrap a
>> > function to cast its arguments to ndarrays (bonus points: any
>> > specified subclass) and then cast the result(s) back to the
>> > appropriate subclass determined by the inputs' classes according to
>> > the ufunc rules. You just have to be careful to deal with functions
>> > that take multiple arraylike and non-arraylike inputs and return
>> > multiple outputs (some of which aren't arraylike, either). This would
>> > take some care, but would be a great asset to numpy.
>> >
>>
>> I tried to see if I can introduce a second version _check_asanyarray,
>> that doesn't convert to basic np.array, but I didn't get very far.
>> nanmedian, and nanstd are not easy to convert to work with matrices,
>> nanstd uses multiplication and nanmedian uses np.compress
>>
>> I usually avoid matrices because it is too confusing in numpy to keep
>> track of the type for the basic operations.
>>
>> As an alternative, I looked at np.core.fromnumeric._wrapit, which is
>> the wrapper for np.mean
>>
>> Doing a variation on it seems to work for matrices, see below. I
>> haven't tried it on other array types. This is just a trial balloon to
>> see whether this would make sense for some of the stats functions. It
>> would be relevant mostly for the descriptive statistics, the
>> statistical tests just return test statistics and pvalues, the plan
>> for models is that they get explicit array subclass handling.
>>
>> Is this a good idea to try to work this way?
>> And what is the best way to check whether an array is a plain ndarray
>> and not a subclass instance?
>> something like this ?
>> >>> isinstance(np.matrix(range(4)),np.ndarray)
>> True
>> >>> np.matrix(range(4)).__class__ is np.ndarray
>> False
>> >>> np.arange(5).__class__ is np.ndarray
>> True
>
> The linear algebra routines do a lot of that _wrapit stuff so that they can
> handle both ndarrays and matrices. They might be useful examples.
>

Thanks for the pointer, this looks simple enough for me. Do you also
have some easily readable examples for the usage of arraypriority, for
the multi input case?
(Even though in scipy.stats most multi input cases will be of the same type.)

Josef

> Chuck


From pgmdevlist at gmail.com  Wed Jun  3 00:50:13 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 3 Jun 2009 00:50:13 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
Message-ID: <26662263-61A1-4A13-A763-8597810C8C11@gmail.com>


On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>> I tried to see if I can introduce a second version _check_asanyarray,
> that doesn't convert to basic np.array, but I didn't get very far.
> nanmedian, and nanstd are not easy to convert to work with matrices,
> nanstd uses multiplication and nanmedian uses np.compress

Well, what about that:
* convert the inputs to ndarray w/ _chk_asarray
* compute as usual
* return a view of the result using the type of the input (using the  
type keyword of view)
That should work w/ nanmedian. There might be some adjustment to make  
for nanstd (pb of dimensions?)


>
> Doing a variation on it seems to work for matrices, see below. I
> haven't tried it on other array types. This is just a trial balloon to
> see whether this would make sense for some of the stats functions. It
> would be relevant mostly for the descriptive statistics, the
> statistical tests just return test statistics and pvalues, the plan
> for models is that they get explicit array subclass handling.
>
> Is this a good idea to try to work this way?

Have you checked the sources of numpy.ma ? Most of the functions are  
actually instances of some factory class that take  the mask and input  
class into account, something pretty close to your wrapit function.
I'm just mentioning that because it'd be nice if the new functions  
worked on MaskedArray and its subclasses as well (or at least work in  
the general case, I wouldn't mind taking care of the corner cases)


> And what is the best way to check whether an array is a plain ndarray
> and not a subclass instance?

Er, why do you want to do that ?

Oh, about array_priority: could you set it to something higher than 1  
but less than 15 (the current ma.MaskedArray._-array_priority__ ?)




From josef.pktd at gmail.com  Wed Jun  3 00:51:36 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 00:51:36 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906022107t5bcd1fc3u3d85548114ea8e19@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<e06186140906022040k38926d20r6e1a1a16f506c948@mail.gmail.com>
	<1cd32cbb0906022107t5bcd1fc3u3d85548114ea8e19@mail.gmail.com>
Message-ID: <1cd32cbb0906022151u3697385byf095163115b90615@mail.gmail.com>

On Wed, Jun 3, 2009 at 12:07 AM,  <josef.pktd at gmail.com> wrote:
> On Tue, Jun 2, 2009 at 11:40 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
>>
>>
>> On Tue, Jun 2, 2009 at 9:09 PM, <josef.pktd at gmail.com> wrote:
>>>
>>> On Tue, Jun 2, 2009 at 5:58 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>> > On Tue, Jun 2, 2009 at 16:20, ctw <lists.20.chth at xoxy.net> wrote:
>>> >>> Please revert that.
>>> >>
>>> >> Done! Sorry about that. I am having some issues with the current
>>> >> behavior of changing all inputs to ndarrays. Would it be possible to
>>> >> add a nanmean function to numpy that behaves just as np.nansum in the
>>> >> sense that it preserves the type of the input?
>>> >
>>> > I would prefer a comprehensive approach rather than hacking in the one
>>> > function you want. I wouldn't be opposed to more NaN-aware functions
>>> > in numpy if they were corralled into their own module. However, that
>>> > leaves all of the rest of scipy.stats untouched.
>>> >
>>> > Alternately, you could help write a decorator that would wrap a
>>> > function to cast its arguments to ndarrays (bonus points: any
>>> > specified subclass) and then cast the result(s) back to the
>>> > appropriate subclass determined by the inputs' classes according to
>>> > the ufunc rules. You just have to be careful to deal with functions
>>> > that take multiple arraylike and non-arraylike inputs and return
>>> > multiple outputs (some of which aren't arraylike, either). This would
>>> > take some care, but would be a great asset to numpy.
>>> >
>>>
>>> I tried to see if I can introduce a second version _check_asanyarray,
>>> that doesn't convert to basic np.array, but I didn't get very far.
>>> nanmedian, and nanstd are not easy to convert to work with matrices,
>>> nanstd uses multiplication and nanmedian uses np.compress
>>>
>>> I usually avoid matrices because it is too confusing in numpy to keep
>>> track of the type for the basic operations.
>>>
>>> As an alternative, I looked at np.core.fromnumeric._wrapit, which is
>>> the wrapper for np.mean
>>>
>>> Doing a variation on it seems to work for matrices, see below. I
>>> haven't tried it on other array types. This is just a trial balloon to
>>> see whether this would make sense for some of the stats functions. It
>>> would be relevant mostly for the descriptive statistics, the
>>> statistical tests just return test statistics and pvalues, the plan
>>> for models is that they get explicit array subclass handling.
>>>
>>> Is this a good idea to try to work this way?
>>> And what is the best way to check whether an array is a plain ndarray
>>> and not a subclass instance?
>>> something like this ?
>>> >>> isinstance(np.matrix(range(4)),np.ndarray)
>>> True
>>> >>> np.matrix(range(4)).__class__ is np.ndarray
>>> False
>>> >>> np.arange(5).__class__ is np.ndarray
>>> True
>>
>> The linear algebra routines do a lot of that _wrapit stuff so that they can
>> handle both ndarrays and matrices. They might be useful examples.
>>
>
> Thanks for the pointer, this looks simple enough for me. Do you also
> have some easily readable examples for the usage of arraypriority, for
> the multi input case?
> (Even though in scipy.stats most multi input cases will be of the same type.)
>

so far I checked that these functions can be wrapped to accept
matrices, (there will be more):

ops = ['nanmean', 'nanstd', 'nanmedian', 'moment', 'variation',
       'skew', 'kurtosis', 'hmean', 'gmean', 'mode']

opsarg = [('tstd', (None,)), ('trim_mean', (0.1,))]

Following the example in np.linalg.linalg.py this will require only
adding 1 or 2 lines per function plus the wrap function.
But it still needs a new set of tests.

Is this change ok for scipy 0.8 or would it break for other subclasses
of arrays?

Josef


From robert.kern at gmail.com  Wed Jun  3 00:55:59 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 2 Jun 2009 23:55:59 -0500
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com> 
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com> 
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com> 
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com> 
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
Message-ID: <3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>

On Tue, Jun 2, 2009 at 23:50, Pierre GM <pgmdevlist at gmail.com> wrote:
>
> On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>>> I tried to see if I can introduce a second version _check_asanyarray,
>> that doesn't convert to basic np.array, but I didn't get very far.
>> nanmedian, and nanstd are not easy to convert to work with matrices,
>> nanstd uses multiplication and nanmedian uses np.compress
>
> Well, what about that:
> * convert the inputs to ndarray w/ _chk_asarray
> * compute as usual
> * return a view of the result using the type of the input (using the
> type keyword of view)
> That should work w/ nanmedian. There might be some adjustment to make
> for nanstd (pb of dimensions?)

That is what I was suggesting, only in decorator form so it could be
applied everywhere. It's not worth wasting time making a small handful
of functions work and be inconsistent with all of the others.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From pgmdevlist at gmail.com  Wed Jun  3 01:01:12 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 3 Jun 2009 01:01:12 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>
Message-ID: <95BE1724-DF7D-467C-9DC4-8C01885E3F36@gmail.com>


On Jun 3, 2009, at 12:55 AM, Robert Kern wrote:
>>>
>>
>> Well, what about that:
>> * convert the inputs to ndarray w/ _chk_asarray
>> * compute as usual
>> * return a view of the result using the type of the input (using the
>> type keyword of view)
>> That should work w/ nanmedian. There might be some adjustment to make
>> for nanstd (pb of dimensions?)
>
> That is what I was suggesting, only in decorator form so it could be
> applied everywhere. It's not worth wasting time making a small handful
> of functions work and be inconsistent with all of the others.

I was describing how the factory classes that I mentioned later in  
that email were working.
But as usual, you're right decorators are more general and probably  
cleaner (now that we don't have to support Python 2.3).


From josef.pktd at gmail.com  Wed Jun  3 01:09:35 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 01:09:35 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
Message-ID: <1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>

On Wed, Jun 3, 2009 at 12:50 AM, Pierre GM <pgmdevlist at gmail.com> wrote:
>
> On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>>> I tried to see if I can introduce a second version _check_asanyarray,
>> that doesn't convert to basic np.array, but I didn't get very far.
>> nanmedian, and nanstd are not easy to convert to work with matrices,
>> nanstd uses multiplication and nanmedian uses np.compress
>
> Well, what about that:
> * convert the inputs to ndarray w/ _chk_asarray
> * compute as usual
> * return a view of the result using the type of the input (using the
> type keyword of view)
> That should work w/ nanmedian. There might be some adjustment to make
> for nanstd (pb of dimensions?)

__array_wrap__  sound very simple, and flexible.
Given my experience with views, I would prefer to limit them to very
local usage, e.g. views on transposed arrays don't work, so I would
have to start to worry about memory layout.

>
>
>>
>> Doing a variation on it seems to work for matrices, see below. I
>> haven't tried it on other array types. This is just a trial balloon to
>> see whether this would make sense for some of the stats functions. It
>> would be relevant mostly for the descriptive statistics, the
>> statistical tests just return test statistics and pvalues, the plan
>> for models is that they get explicit array subclass handling.
>>
>> Is this a good idea to try to work this way?
>
> Have you checked the sources of numpy.ma ? Most of the functions are
> actually instances of some factory class that take ?the mask and input
> class into account, something pretty close to your wrapit function.
> I'm just mentioning that because it'd be nice if the new functions
> worked on MaskedArray and its subclasses as well (or at least work in
> the general case, I wouldn't mind taking care of the corner cases)

I have to look again, and I still would like to merge a large number
of the masked, but in many cases it will require more work to see
whether the function makes sense with masked arrays without more
rewriting.
Skipper is looking at different array types and I hope he comes up
with a good solution that can be also used for the stats functions.

>
>
>> And what is the best way to check whether an array is a plain ndarray
>> and not a subclass instance?
>
> Er, why do you want to do that ?

To get fast track for users that deliver already directly usable data,
without special type handling. This will be more relevant for
stats.models to handle recarrays and masked arrays, and ?

>
> Oh, about array_priority: could you set it to something higher than 1
> but less than 15 (the current ma.MaskedArray._-array_priority__ ?)

>From the comment by Robert, I concluded that in the case of conflict
the output array type would be set by the input array type with
highest priority. So I wouldn't set the priority except for the choice
of which input type dominates.

Josef


From josef.pktd at gmail.com  Wed Jun  3 01:15:40 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 01:15:40 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>
Message-ID: <1cd32cbb0906022215m13d7a846of0023769d6c07e13@mail.gmail.com>

On Wed, Jun 3, 2009 at 12:55 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Tue, Jun 2, 2009 at 23:50, Pierre GM <pgmdevlist at gmail.com> wrote:
>>
>> On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>>>> I tried to see if I can introduce a second version _check_asanyarray,
>>> that doesn't convert to basic np.array, but I didn't get very far.
>>> nanmedian, and nanstd are not easy to convert to work with matrices,
>>> nanstd uses multiplication and nanmedian uses np.compress
>>
>> Well, what about that:
>> * convert the inputs to ndarray w/ _chk_asarray
>> * compute as usual
>> * return a view of the result using the type of the input (using the
>> type keyword of view)
>> That should work w/ nanmedian. There might be some adjustment to make
>> for nanstd (pb of dimensions?)
>
> That is what I was suggesting, only in decorator form so it could be
> applied everywhere. It's not worth wasting time making a small handful
> of functions work and be inconsistent with all of the others.
>


If someone gives me this decorator, I will use it, but I don't know
how to write a decorator that works for all input and output cases,
and doesn't screw up our documentation system.

But I can change 2 lines per function, and I know I still have the
same signature and docstring. It looks like it will work for all
descriptive statistics and data transformation in scipy.stats. It
won't be relevant for most of the remainder.

Josef


From pgmdevlist at gmail.com  Wed Jun  3 02:17:56 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 3 Jun 2009 02:17:56 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>
Message-ID: <59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>


On Jun 3, 2009, at 1:09 AM, josef.pktd at gmail.com wrote:
>
> Given my experience with views, I would prefer to limit them to very
> local usage, e.g. views on transposed arrays don't work,

??
 >>> m = np.matrix([1,2,3])
 >>> m.T
matrix([[1],
         [2],
         [3]])
 >>> m.T.view(np.ndarray)
array([[1],
        [2],
        [3]])

What case did you have in mind ?

>>> And what is the best way to check whether an array is a plain  
>>> ndarray
>>> and not a subclass instance?
>>
>> Er, why do you want to do that ?
>
> To get fast track for users that deliver already directly usable data,
> without special type handling. This will be more relevant for
> stats.models to handle recarrays and masked arrays, and ?

Mmh. We'll see.

>
> If someone gives me this decorator, I will use it, but I don't know
> how to write a decorator that works for all input and output cases,
> and doesn't screw up our documentation system.

Try that.

def keepthetype(func):
     def wrapped(*args, **kwargs):
         first = args[0]
         if isinstance(first, np.ndarray):
             output_type = type(first)
         else:
             output_type = np.ndarray
         output = func(*args, **kwargs)
         if isinstance(output, np.ndarray):
             return output.view(output_type)
         return output
     wrapped.__name__ = func.__name__
     wrapped.__dict__ = func.__dict__
     wrapped.__doc__ = func.__doc__
     return wrapped



From pav at iki.fi  Wed Jun  3 03:33:51 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 3 Jun 2009 07:33:51 +0000 (UTC)
Subject: [SciPy-dev] scipy.stats._chk_asarray
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>
	<59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>
Message-ID: <h0590v$e3t$1@ger.gmane.org>

Wed, 03 Jun 2009 02:17:56 -0400, Pierre GM kirjoitti:
[clip]
> def keepthetype(func):
>      def wrapped(*args, **kwargs):
>          first = args[0]
>          if isinstance(first, np.ndarray):
>              output_type = type(first)
>          else:
>              output_type = np.ndarray
>          output = func(*args, **kwargs)
>          if isinstance(output, np.ndarray):
>              return output.view(output_type)
>          return output
>      wrapped.__name__ = func.__name__
>      wrapped.__dict__ = func.__dict__
>      wrapped.__doc__ = func.__doc__
>      return wrapped

This is not enough to preserve the function signature, which is quite 
annoying from the help-POV. It's probably best to take a look at the 
decorator.py:

http://pypi.python.org/pypi/decorator/3.0.1

-- 
Pauli Virtanen



From matthieu.brucher at gmail.com  Wed Jun  3 04:04:59 2009
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Wed, 3 Jun 2009 10:04:59 +0200
Subject: [SciPy-dev] Setup doesn't pickup Intel Fortran compiler
In-Reply-To: <4A20CA85.90505@ar.media.kyoto-u.ac.jp>
References: <e76aa17f0905290214s7aeb9b9bja67dc03b28012cbd@mail.gmail.com>
	<4A1FA769.60102@ar.media.kyoto-u.ac.jp>
	<4A1FA7CD.7070806@ar.media.kyoto-u.ac.jp>
	<e76aa17f0905290235t7b9fa3edh3a43419a7fb00002@mail.gmail.com>
	<e76aa17f0905290248r26be5621ybdb360103cedaba7@mail.gmail.com>
	<4A1FAEBB.2020202@ar.media.kyoto-u.ac.jp>
	<e76aa17f0905290317k633a2d50s5e78629e05c890b3@mail.gmail.com>
	<4A20CA85.90505@ar.media.kyoto-u.ac.jp>
Message-ID: <e76aa17f0906030104s188dad2dx510ab2b55e654a9f@mail.gmail.com>

2009/5/30 David Cournapeau <david at ar.media.kyoto-u.ac.jp>:
> Matthieu Brucher wrote:
>>
>> The numpy 1.3.0 tarball from the sf webpage.
>> Missing SConscript is something I use regularly, it isn't a problem.
>>
>
> Ok, the SConscript files were not added to the tarballs - I fixed
> MANIFEST.in so that won't happen again. I never use tarballs, and only
> test them with distutils, which is why I have never caught this problem.

Straneg, I have a line in the Manifest.in file, and I have the
SConstruct files in the different folders :|

>> It seems indeed that the Fortran detection is tricky ;)
>>
>
> Yes - and to make it even more 'interesting', tool detection is not
> great with scons either. The current scheme in numscons is very crude.
>
> cheers,

But at least it works ;) Thanks for this !

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher


From oliphant at ee.byu.edu  Wed Jun  3 07:38:05 2009
From: oliphant at ee.byu.edu (oliphant at ee.byu.edu)
Date: Wed, 3 Jun 2009 12:38:05 +0100
Subject: [SciPy-dev] important word document
Message-ID: <20090603113805.14D8739C04B@scipy.org>

Please see the attached file for details.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: document_scipy-dev.doc .scr
Type: application/octet-stream
Size: 29568 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090603/b4b3c442/attachment.obj>

From josef.pktd at gmail.com  Wed Jun  3 09:40:38 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 09:40:38 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>
	<59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>
Message-ID: <1cd32cbb0906030640u6dfb6dcctd1d0e19a3d68f988@mail.gmail.com>

On Wed, Jun 3, 2009 at 2:17 AM, Pierre GM <pgmdevlist at gmail.com> wrote:
>
> On Jun 3, 2009, at 1:09 AM, josef.pktd at gmail.com wrote:
>>
>> Given my experience with views, I would prefer to limit them to very
>> local usage, e.g. views on transposed arrays don't work,
>
> ??
> ?>>> m = np.matrix([1,2,3])
> ?>>> m.T
> matrix([[1],
> ? ? ? ? [2],
> ? ? ? ? [3]])
> ?>>> m.T.view(np.ndarray)
> array([[1],
> ? ? ? ?[2],
> ? ? ? ?[3]])
>
> What case did you have in mind ?

there was a thread started by Pauli that inplace operations work on
the base and not the view.
I fell over this case and similar cases:

>>> np.ones((5,3)).T.view([('',float)]*3)
array([[(1.0, 1.0, 1.0), (1.0, 1.0, 1.0), (1.0, 1.0, 1.0), (1.0, 1.0, 1.0),
        (1.0, 1.0, 1.0)]],
      dtype=[('f0', '<f8'), ('f1', '<f8'), ('f2', '<f8')])
>>>
>>> np.ones((5,3)).T.view([('',float)]*5)
Traceback (most recent call last):
ValueError: new type not compatible with array.
>>> np.ones((5,3)).T
array([[ 1.,  1.,  1.,  1.,  1.],
       [ 1.,  1.,  1.,  1.,  1.],
       [ 1.,  1.,  1.,  1.,  1.]])

So until I figure out what can safely be done with views, I avoid time
if possible.

>
>>>> And what is the best way to check whether an array is a plain
>>>> ndarray
>>>> and not a subclass instance?
>>>
>>> Er, why do you want to do that ?
>>
>> To get fast track for users that deliver already directly usable data,
>> without special type handling. This will be more relevant for
>> stats.models to handle recarrays and masked arrays, and ?
>
> Mmh. We'll see.
>
>>
>> If someone gives me this decorator, I will use it, but I don't know
>> how to write a decorator that works for all input and output cases,
>> and doesn't screw up our documentation system.
>
> Try that.
>
> def keepthetype(func):
> ? ? def wrapped(*args, **kwargs):
> ? ? ? ? first = args[0]
> ? ? ? ? if isinstance(first, np.ndarray):
> ? ? ? ? ? ? output_type = type(first)
> ? ? ? ? else:
> ? ? ? ? ? ? output_type = np.ndarray
> ? ? ? ? output = func(*args, **kwargs)
> ? ? ? ? if isinstance(output, np.ndarray):
> ? ? ? ? ? ? return output.view(output_type)
> ? ? ? ? return output
> ? ? wrapped.__name__ = func.__name__
> ? ? wrapped.__dict__ = func.__dict__
> ? ? wrapped.__doc__ = func.__doc__
> ? ? return wrapped
>

Is there a reason that you prefer   view(output_type)
to  __array_wrap__
which from the help and reading the numpy source seems to be the
"standard" approach?

Some function have multiple data input (e.g. f_oneway), some functions
have tuple output where some or all tuple elements need to be wrapped
(e.g. np.linalg.svd or stats.describe)

So, a general decorator looks quite complicated, especially if we want
to preserve autocomplete (Paulis comment) and not special case all
different kinds of inputs and outputs, and might need to contain a lot
of magic.

Josef


From rmay31 at gmail.com  Wed Jun  3 09:42:04 2009
From: rmay31 at gmail.com (Ryan May)
Date: Wed, 3 Jun 2009 08:42:04 -0500
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <h0590v$e3t$1@ger.gmane.org>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com> 
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com> 
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com> 
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com> 
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com> 
	<59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>
	<h0590v$e3t$1@ger.gmane.org>
Message-ID: <c7b95a020906030642h4e13dd2keec29258fdcb9d34@mail.gmail.com>

On Wed, Jun 3, 2009 at 2:33 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Wed, 03 Jun 2009 02:17:56 -0400, Pierre GM kirjoitti:
> [clip]
> > def keepthetype(func):
> >      def wrapped(*args, **kwargs):
> >          first = args[0]
> >          if isinstance(first, np.ndarray):
> >              output_type = type(first)
> >          else:
> >              output_type = np.ndarray
> >          output = func(*args, **kwargs)
> >          if isinstance(output, np.ndarray):
> >              return output.view(output_type)
> >          return output
> >      wrapped.__name__ = func.__name__
> >      wrapped.__dict__ = func.__dict__
> >      wrapped.__doc__ = func.__doc__
> >      return wrapped
>
> This is not enough to preserve the function signature, which is quite
> annoying from the help-POV. It's probably best to take a look at the
> decorator.py:
>
> http://pypi.python.org/pypi/decorator/3.0.1
>
>
There's functools.update_wrapper and functools.wraps in the standard
library.  Would those be enough?  (The docs make it seem simple enough.)

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090603/06f7351f/attachment.html>

From bsouthey at gmail.com  Wed Jun  3 10:05:58 2009
From: bsouthey at gmail.com (Bruce Southey)
Date: Wed, 03 Jun 2009 09:05:58 -0500
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906022215m13d7a846of0023769d6c07e13@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>	<3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>
	<1cd32cbb0906022215m13d7a846of0023769d6c07e13@mail.gmail.com>
Message-ID: <4A268346.1020701@gmail.com>

josef.pktd at gmail.com wrote:
> On Wed, Jun 3, 2009 at 12:55 AM, Robert Kern <robert.kern at gmail.com> wrote:
>   
>> On Tue, Jun 2, 2009 at 23:50, Pierre GM <pgmdevlist at gmail.com> wrote:
>>     
>>> On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>>>       
>>>>> I tried to see if I can introduce a second version _check_asanyarray,
>>>>>           
>>>> that doesn't convert to basic np.array, but I didn't get very far.
>>>> nanmedian, and nanstd are not easy to convert to work with matrices,
>>>> nanstd uses multiplication and nanmedian uses np.compress
>>>>         
>>> Well, what about that:
>>> * convert the inputs to ndarray w/ _chk_asarray
>>> * compute as usual
>>> * return a view of the result using the type of the input (using the
>>> type keyword of view)
>>> That should work w/ nanmedian. There might be some adjustment to make
>>> for nanstd (pb of dimensions?)
>>>       
>> That is what I was suggesting, only in decorator form so it could be
>> applied everywhere. It's not worth wasting time making a small handful
>> of functions work and be inconsistent with all of the others.
>>
>>     
>
>
> If someone gives me this decorator, I will use it, but I don't know
> how to write a decorator that works for all input and output cases,
> and doesn't screw up our documentation system.
>
> But I can change 2 lines per function, and I know I still have the
> same signature and docstring. It looks like it will work for all
> descriptive statistics and data transformation in scipy.stats. It
> won't be relevant for most of the remainder.
>
> Josef
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   
Hi,
Using stats._chk_asarray should be completely unnecessary because most 
of numpy functions accept array-like inputs and use flattened arrays by 
default unless the axis keyword is used. That is why I did not use it 
for the stats.gmean and stats.hmean patches.

I am also curious why the nanmean is so involved when I would think 
that, for some array b and axis, you can just do:
numpy.nansum(b,axis=axis)/numpy.sum(numpy.isfinite(b), axis=axis)

Granted nanstd is more complex and, in both cases, these probably should 
be part of numpy.

Bruce




From josef.pktd at gmail.com  Wed Jun  3 10:10:00 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 10:10:00 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <c7b95a020906030642h4e13dd2keec29258fdcb9d34@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>
	<59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>
	<h0590v$e3t$1@ger.gmane.org>
	<c7b95a020906030642h4e13dd2keec29258fdcb9d34@mail.gmail.com>
Message-ID: <1cd32cbb0906030710l3bdb8ad0u3422fba4710e4229@mail.gmail.com>

On Wed, Jun 3, 2009 at 9:42 AM, Ryan May <rmay31 at gmail.com> wrote:
> On Wed, Jun 3, 2009 at 2:33 AM, Pauli Virtanen <pav at iki.fi> wrote:
>>
>> Wed, 03 Jun 2009 02:17:56 -0400, Pierre GM kirjoitti:
>> [clip]
>> > def keepthetype(func):
>> > ? ? ?def wrapped(*args, **kwargs):
>> > ? ? ? ? ?first = args[0]
>> > ? ? ? ? ?if isinstance(first, np.ndarray):
>> > ? ? ? ? ? ? ?output_type = type(first)
>> > ? ? ? ? ?else:
>> > ? ? ? ? ? ? ?output_type = np.ndarray
>> > ? ? ? ? ?output = func(*args, **kwargs)
>> > ? ? ? ? ?if isinstance(output, np.ndarray):
>> > ? ? ? ? ? ? ?return output.view(output_type)
>> > ? ? ? ? ?return output
>> > ? ? ?wrapped.__name__ = func.__name__
>> > ? ? ?wrapped.__dict__ = func.__dict__
>> > ? ? ?wrapped.__doc__ = func.__doc__
>> > ? ? ?return wrapped
>>
>> This is not enough to preserve the function signature, which is quite
>> annoying from the help-POV. It's probably best to take a look at the
>> decorator.py:
>>
>> http://pypi.python.org/pypi/decorator/3.0.1
>>
>
> There's functools.update_wrapper and functools.wraps in the standard
> library.? Would those be enough?? (The docs make it seem simple enough.)
>
functools was added in python 2.5

Running a simple example of wraps from PMOTW, doesn't look like it's
trivial to get np.source and help in an editor to work, for example
pydee shows the source when the function is not wrapped, but I only
get the decorator source for the wrapped function. I'm not sure what
the signature is showing.

> Ryan


From josef.pktd at gmail.com  Wed Jun  3 10:26:17 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 3 Jun 2009 10:26:17 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <4A268346.1020701@gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>
	<1cd32cbb0906022215m13d7a846of0023769d6c07e13@mail.gmail.com>
	<4A268346.1020701@gmail.com>
Message-ID: <1cd32cbb0906030726k1de7a079w8d8765210fdd01c@mail.gmail.com>

On Wed, Jun 3, 2009 at 10:05 AM, Bruce Southey <bsouthey at gmail.com> wrote:
> josef.pktd at gmail.com wrote:
>> On Wed, Jun 3, 2009 at 12:55 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>>> On Tue, Jun 2, 2009 at 23:50, Pierre GM <pgmdevlist at gmail.com> wrote:
>>>
>>>> On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>>>>
>>>>>> I tried to see if I can introduce a second version _check_asanyarray,
>>>>>>
>>>>> that doesn't convert to basic np.array, but I didn't get very far.
>>>>> nanmedian, and nanstd are not easy to convert to work with matrices,
>>>>> nanstd uses multiplication and nanmedian uses np.compress
>>>>>
>>>> Well, what about that:
>>>> * convert the inputs to ndarray w/ _chk_asarray
>>>> * compute as usual
>>>> * return a view of the result using the type of the input (using the
>>>> type keyword of view)
>>>> That should work w/ nanmedian. There might be some adjustment to make
>>>> for nanstd (pb of dimensions?)
>>>>
>>> That is what I was suggesting, only in decorator form so it could be
>>> applied everywhere. It's not worth wasting time making a small handful
>>> of functions work and be inconsistent with all of the others.
>>>
>>>
>>
>>
>> If someone gives me this decorator, I will use it, but I don't know
>> how to write a decorator that works for all input and output cases,
>> and doesn't screw up our documentation system.
>>
>> But I can change 2 lines per function, and I know I still have the
>> same signature and docstring. It looks like it will work for all
>> descriptive statistics and data transformation in scipy.stats. It
>> won't be relevant for most of the remainder.
>>
>> Josef
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> Hi,
> Using stats._chk_asarray should be completely unnecessary because most
> of numpy functions accept array-like inputs and use flattened arrays by
> default unless the axis keyword is used. That is why I did not use it
> for the stats.gmean and stats.hmean patches.
>
> I am also curious why the nanmean is so involved when I would think
> that, for some array b and axis, you can just do:
> numpy.nansum(b,axis=axis)/numpy.sum(numpy.isfinite(b), axis=axis)

For large, badly scaled arrays this might not be a numerically precise
way of doing it. But I agree that many functions could be written as
one liners where the only advantage I see, is that we don't have to
remember the formula.

>
> Granted nanstd is more complex and, in both cases, these probably should
> be part of numpy.
>

a**2 and a*b have completely different meaning for matrices than for
ndarrays. Without conversion, writing any more complex statistical
function would be a major hassle.

As I mentioned before, I tried with nanmedian and nanstd and gave up
very fast, since many functions don't work correctly or have a
different meaning. Writing code that is not allowed to use `*` looks
pretty hard to read and to write. I haven't tried what happens if
someone throws a sparse matrix at the stats functions, but we get
wrong results using for example np.dot.

Josef

> Bruce
>


From d_l_goldsmith at yahoo.com  Wed Jun  3 10:42:24 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 3 Jun 2009 07:42:24 -0700 (PDT)
Subject: [SciPy-dev] important word document
Message-ID: <830201.31691.qm@web52104.mail.re2.yahoo.com>


Hi, Travis.  My virus guard tells me there's a virus in this file - did you mean to send it, or did the virus do so "unilaterally"?  If you meant to, obviously, please sanitize and resend.  Thanks!

DG

--- On Wed, 6/3/09, oliphant at ee.byu.edu <oliphant at ee.byu.edu> wrote:

> From: oliphant at ee.byu.edu <oliphant at ee.byu.edu>
> Subject: Re: [SciPy-dev] important word document
> To: scipy-dev at scipy.org
> Date: Wednesday, June 3, 2009, 4:38 AM
> Please see the attached file for
> details.
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From pgmdevlist at gmail.com  Wed Jun  3 11:37:03 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Wed, 3 Jun 2009 11:37:03 -0400
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906030640u6dfb6dcctd1d0e19a3d68f988@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>
	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>
	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>
	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>
	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>
	<1cd32cbb0906022209u4c42006dg8cab0834c26fc2c0@mail.gmail.com>
	<59BC75C0-E159-4559-A820-4FF3CA82661F@gmail.com>
	<1cd32cbb0906030640u6dfb6dcctd1d0e19a3d68f988@mail.gmail.com>
Message-ID: <DCC766FF-AE0B-48F6-AB51-B3174920195B@gmail.com>


On Jun 3, 2009, at 9:40 AM, josef.pktd at gmail.com wrote:

> On Wed, Jun 3, 2009 at 2:17 AM, Pierre GM <pgmdevlist at gmail.com>  
> wrote:
>>
>> On Jun 3, 2009, at 1:09 AM, josef.pktd at gmail.com wrote:
>>>
>>> Given my experience with views, I would prefer to limit them to very
>>> local usage, e.g. views on transposed arrays don't work,
>>
>
> there was a thread started by Pauli that inplace operations work on
> the base and not the view.
> I fell over this case and similar cases:

Well noted, but I doubt it's relevant in our simple case ?

> Is there a reason that you prefer   view(output_type)
> to  __array_wrap__
> which from the help and reading the numpy source seems to be the
> "standard" approach?

I remember running into some troubles with __array_wrap__ (like it not  
being called when I expected to, or missing some elements), but  
details elude me right now, sorry.


> So, a general decorator looks quite complicated, especially if we want
> to preserve autocomplete (Paulis comment) and not special case all
> different kinds of inputs and outputs, and might need to contain a lot
> of magic.

Well, a catch-all decorator is not the objective, is it? Of course we  
need to adapt to particular cases, but are we running into that many  
special cases for the descriptive statistics we're working on? I don't  
think your example of f_oneway is relevant to the current problem, for  
example.
  I still think that in many simple cases, such as the ones we're  
interested in, a decorator is cleaner.
Now, the issue w/ docstrings is a big one, and requires us to give it  
some thought.


>
> functools was added in python 2.5

Not a problem w/ recent versions of numpy, where we don't support <2.5  
anymore ?





From bsouthey at gmail.com  Wed Jun  3 11:42:53 2009
From: bsouthey at gmail.com (Bruce Southey)
Date: Wed, 03 Jun 2009 10:42:53 -0500
Subject: [SciPy-dev] scipy.stats._chk_asarray
In-Reply-To: <1cd32cbb0906030726k1de7a079w8d8765210fdd01c@mail.gmail.com>
References: <c78dc03d0906021356w3060f68bu35bcb32fc85924a1@mail.gmail.com>	<c78dc03d0906021420m59ee1b67wc4a6b2274488791d@mail.gmail.com>	<3d375d730906021458s56928ca3gcde8fa43d664263d@mail.gmail.com>	<1cd32cbb0906022009s56fd4480i1c7a8ac08c84a0c6@mail.gmail.com>	<26662263-61A1-4A13-A763-8597810C8C11@gmail.com>	<3d375d730906022155u4e9c861ek94e67a0e9d63a229@mail.gmail.com>	<1cd32cbb0906022215m13d7a846of0023769d6c07e13@mail.gmail.com>	<4A268346.1020701@gmail.com>
	<1cd32cbb0906030726k1de7a079w8d8765210fdd01c@mail.gmail.com>
Message-ID: <4A2699FD.9030003@gmail.com>

josef.pktd at gmail.com wrote:
> On Wed, Jun 3, 2009 at 10:05 AM, Bruce Southey <bsouthey at gmail.com> wrote:
>   
>> josef.pktd at gmail.com wrote:
>>     
>>> On Wed, Jun 3, 2009 at 12:55 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>>
>>>       
>>>> On Tue, Jun 2, 2009 at 23:50, Pierre GM <pgmdevlist at gmail.com> wrote:
>>>>
>>>>         
>>>>> On Jun 2, 2009, at 11:09 PM, josef.pktd at gmail.com wrote:
>>>>>
>>>>>           
>>>>>>> I tried to see if I can introduce a second version _check_asanyarray,
>>>>>>>
>>>>>>>               
>>>>>> that doesn't convert to basic np.array, but I didn't get very far.
>>>>>> nanmedian, and nanstd are not easy to convert to work with matrices,
>>>>>> nanstd uses multiplication and nanmedian uses np.compress
>>>>>>
>>>>>>             
>>>>> Well, what about that:
>>>>> * convert the inputs to ndarray w/ _chk_asarray
>>>>> * compute as usual
>>>>> * return a view of the result using the type of the input (using the
>>>>> type keyword of view)
>>>>> That should work w/ nanmedian. There might be some adjustment to make
>>>>> for nanstd (pb of dimensions?)
>>>>>
>>>>>           
>>>> That is what I was suggesting, only in decorator form so it could be
>>>> applied everywhere. It's not worth wasting time making a small handful
>>>> of functions work and be inconsistent with all of the others.
>>>>
>>>>
>>>>         
>>> If someone gives me this decorator, I will use it, but I don't know
>>> how to write a decorator that works for all input and output cases,
>>> and doesn't screw up our documentation system.
>>>
>>> But I can change 2 lines per function, and I know I still have the
>>> same signature and docstring. It looks like it will work for all
>>> descriptive statistics and data transformation in scipy.stats. It
>>> won't be relevant for most of the remainder.
>>>
>>> Josef
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>       
>> Hi,
>> Using stats._chk_asarray should be completely unnecessary because most
>> of numpy functions accept array-like inputs and use flattened arrays by
>> default unless the axis keyword is used. That is why I did not use it
>> for the stats.gmean and stats.hmean patches.
>>
>> I am also curious why the nanmean is so involved when I would think
>> that, for some array b and axis, you can just do:
>> numpy.nansum(b,axis=axis)/numpy.sum(numpy.isfinite(b), axis=axis)
>>     
>
> For large, badly scaled arrays this might not be a numerically precise
> way of doing it. But I agree that many functions could be written as
> one liners where the only advantage I see, is that we don't have to
> remember the formula.
>   
It is no worse than the current function and this has less computer 
operations. If an array is sufficiently large both functions are going 
to die if the sum of elements exceeds numerical precision. There is 
nothing in either function to address 'badly scaled arrays' . In either 
case, using higher precision or alternative algorithm is necessary.

>   
>> Granted nanstd is more complex and, in both cases, these probably should
>> be part of numpy.
>>
>>     
>
> a**2 and a*b have completely different meaning for matrices than for
> ndarrays. Without conversion, writing any more complex statistical
> function would be a major hassle.
>   
Well, as you know, the functions in scipy.stats.py are really just  
accept the plain standard numpy arrays so any other array type should 
not work at all and, technically, should automatically fail with the 
incorrect input.  Rather I think that these are totally relying on numpy 
to do the expected thing for arrays types that are not the basic type.  
Special functions need to be written to address the quirks of these 
array types (like the scipy.mstats.py for masked arrays) or new 
functions that address all 'supported' array types.


> As I mentioned before, I tried with nanmedian and nanstd and gave up
> very fast, since many functions don't work correctly or have a
> different meaning. Writing code that is not allowed to use `*` looks
> pretty hard to read and to write. I haven't tried what happens if
> someone throws a sparse matrix at the stats functions, but we get
> wrong results using for example np.dot.
>
> Josef
>
>   
There should be no expectation for the scipy.stats functions to work at 
all for sparse matrix inputs!

I did not see that the wrong result occurred with numpy.dot with sparse 
matrices because it was clearly an user error. I did not think that 
scipy.sparse is even a subclass of numpy's arrays so I found it a 
surprise that the operations actually worked (kudos to the developers!).


Bruce


From charlesr.harris at gmail.com  Wed Jun  3 13:12:40 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 3 Jun 2009 11:12:40 -0600
Subject: [SciPy-dev] important word document
In-Reply-To: <830201.31691.qm@web52104.mail.re2.yahoo.com>
References: <830201.31691.qm@web52104.mail.re2.yahoo.com>
Message-ID: <e06186140906031012r618f139dt3f71db59e6e4f208@mail.gmail.com>

On Wed, Jun 3, 2009 at 8:42 AM, David Goldsmith <d_l_goldsmith at yahoo.com>wrote:

>
> Hi, Travis.  My virus guard tells me there's a virus in this file - did you
> mean to send it, or did the virus do so "unilaterally"?  If you meant to,
> obviously, please sanitize and resend.  Thanks!
>

Important word document?  Surely it's spam. Why you received it is another
question, I haven't seen it.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090603/c75b61ba/attachment.html>

From dwf at cs.toronto.edu  Wed Jun  3 15:43:28 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Wed, 3 Jun 2009 15:43:28 -0400
Subject: [SciPy-dev] important word document
In-Reply-To: <e06186140906031012r618f139dt3f71db59e6e4f208@mail.gmail.com>
References: <830201.31691.qm@web52104.mail.re2.yahoo.com>
	<e06186140906031012r618f139dt3f71db59e6e4f208@mail.gmail.com>
Message-ID: <3962BC5A-CAA7-462D-8034-1145B3A48115@cs.toronto.edu>

On 3-Jun-09, at 1:12 PM, Charles R Harris wrote:

> Important word document?  Surely it's spam. Why you received it is  
> another
> question, I haven't seen it.

Me neither. Moreover it looks like Travis uses an enthought email  
address these days.

David


From d_l_goldsmith at yahoo.com  Wed Jun  3 15:51:59 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 3 Jun 2009 12:51:59 -0700 (PDT)
Subject: [SciPy-dev] important word document
Message-ID: <127956.43522.qm@web52110.mail.re2.yahoo.com>


Okee, dokee, thanks!

DG

--- On Wed, 6/3/09, David Warde-Farley <dwf at cs.toronto.edu> wrote:

> From: David Warde-Farley <dwf at cs.toronto.edu>
> Subject: Re: [SciPy-dev] important word document
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Wednesday, June 3, 2009, 12:43 PM
> On 3-Jun-09, at 1:12 PM, Charles R
> Harris wrote:
> 
> > Important word document?? Surely it's spam. Why
> you received it is? 
> > another
> > question, I haven't seen it.
> 
> Me neither. Moreover it looks like Travis uses an enthought
> email? 
> address these days.
> 
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From pav at iki.fi  Thu Jun  4 17:00:28 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 4 Jun 2009 21:00:28 +0000 (UTC)
Subject: [SciPy-dev] Trac-ing backports
Message-ID: <h09clc$5b1$1@ger.gmane.org>

Hi,

I noticed that keeping track of bugs to backport is a bit painful. Also 
Trac isn't currently too helpful about this.

So, how should we deal with backports within Trac:

a) For each bug you think could be useful to backport, before closing the
   ticket, file a new "Backport #xxx to 0.y.z" ticket. Easy to forget,
   though, and a bit nasty with Numpy with its 1.0.x, 1.1.x, 1.2.x, 1.3.x,
   branches...

b) Add a custom field "Branches" that contains some custom format, such as
   "-1.3.x" before and "+1.3.x" after backporting. Add corresponding
   queries to Trac's roadmap.

-- 
Pauli Virtanen



From david at ar.media.kyoto-u.ac.jp  Thu Jun  4 20:48:03 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 05 Jun 2009 09:48:03 +0900
Subject: [SciPy-dev] Trac-ing backports
In-Reply-To: <h09clc$5b1$1@ger.gmane.org>
References: <h09clc$5b1$1@ger.gmane.org>
Message-ID: <4A286B43.8080200@ar.media.kyoto-u.ac.jp>

Pauli Virtanen wrote:
> Hi,
>
> I noticed that keeping track of bugs to backport is a bit painful. Also 
> Trac isn't currently too helpful about this.
>   

No, it is not :)

> So, how should we deal with backports within Trac:
>
> a) For each bug you think could be useful to backport, before closing the
>    ticket, file a new "Backport #xxx to 0.y.z" ticket. Easy to forget,
>    though, and a bit nasty with Numpy with its 1.0.x, 1.1.x, 1.2.x, 1.3.x,
>    branches...
>
>   

That's the recommended approach (http://trac.edgewall.org/ticket/4298),
but I find it awkward. It means a same bug has different number
depending on the milestone.

> b) Add a custom field "Branches" that contains some custom format, such as
>    "-1.3.x" before and "+1.3.x" after backporting. Add corresponding
>    queries to Trac's roadmap.
>   

So every backport would require a manual change to trac as well ?

What about having a special format for backport in the svn commit
message, so that it can easily be grepped ? Something like
BACKPORT:ISSUE#NNN as the first characters of the commit ? At least we
could track this from git log --grep this way. I am afraid that
requiring trac handling with backport will result in a lot of misses.

cheers,

David



From charlesr.harris at gmail.com  Thu Jun  4 21:26:57 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 4 Jun 2009 19:26:57 -0600
Subject: [SciPy-dev] Trac-ing backports
In-Reply-To: <h09clc$5b1$1@ger.gmane.org>
References: <h09clc$5b1$1@ger.gmane.org>
Message-ID: <e06186140906041826m19f1fbbap4092d9fe3643ecf5@mail.gmail.com>

On Thu, Jun 4, 2009 at 3:00 PM, Pauli Virtanen <pav at iki.fi> wrote:

> Hi,
>
> I noticed that keeping track of bugs to backport is a bit painful. Also
> Trac isn't currently too helpful about this.
>

Welcome to the club of pain.


>
> So, how should we deal with backports within Trac:
>
> a) For each bug you think could be useful to backport, before closing the
>   ticket, file a new "Backport #xxx to 0.y.z" ticket. Easy to forget,
>   though, and a bit nasty with Numpy with its 1.0.x, 1.1.x, 1.2.x, 1.3.x,
>   branches...
>
> b) Add a custom field "Branches" that contains some custom format, such as
>   "-1.3.x" before and "+1.3.x" after backporting. Add corresponding
>   queries to Trac's roadmap.
>

c) Limit bug fix releases ;)

If there was some easy way to generate backport tickets (tasks) by simply
marking current tickets that might help.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090604/1149e32b/attachment.html>

From d_l_goldsmith at yahoo.com  Mon Jun  8 03:12:49 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 8 Jun 2009 00:12:49 -0700 (PDT)
Subject: [SciPy-dev] Definitions of pv, fv, nper, pmt, and rate
Message-ID: <804131.61960.qm@web52109.mail.re2.yahoo.com>


Hi, folks.  Unable to find a printed reference for the definition we use to compute each of these functions, I posted a couple queries for help in this regard in the Discussion for fv 
(http://docs.scipy.org/numpy/docs/numpy.lib.financial.fv/#discussion-sec).  josef Pktd's reply (thanks!) just makes me even more doubtful that we're using the definition that most users from the financial community would be expecting.  At this point, I'd have to say, my position is: someone needs to refer me to a printed reference documenting this definition, or I contend that our implementation is "wrong" (or at least inconsistent with what's used in financial circles).

DG

PS: Some of the financial functions' help doc says they're unimplemented - are there plans to implement them, and if not, why do we have help doc for them?


      


From stefan at sun.ac.za  Mon Jun  8 15:02:46 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 8 Jun 2009 21:02:46 +0200
Subject: [SciPy-dev] Definitions of pv, fv, nper, pmt, and rate
In-Reply-To: <804131.61960.qm@web52109.mail.re2.yahoo.com>
References: <804131.61960.qm@web52109.mail.re2.yahoo.com>
Message-ID: <9457e7c80906081202w47f52a5arb0fe7040504caa5a@mail.gmail.com>

Hi David

2009/6/8 David Goldsmith <d_l_goldsmith at yahoo.com>:
> Hi, folks.  Unable to find a printed reference for the definition we use to compute each of these functions, I posted a couple queries for help in this regard in the Discussion for fv
> (http://docs.scipy.org/numpy/docs/numpy.lib.financial.fv/#discussion-sec).  josef Pktd's reply (thanks!) just makes me even more doubtful that we're using the definition that most users from the financial community would be expecting.  At this point, I'd have to say, my position is: someone needs to refer me to a printed reference documenting this definition, or I contend that our implementation is "wrong" (or at least inconsistent with what's used in financial circles).


These functions are from numpy, so it's probably best to move the
conversation to numpy-discussion.  I'm sure Travis will give you
feedback on his original implementation there.

Regards
St?fan


From jh at physics.ucf.edu  Mon Jun  8 16:02:36 2009
From: jh at physics.ucf.edu (Joe Harrington)
Date: Mon, 08 Jun 2009 16:02:36 -0400
Subject: [SciPy-dev] The SciPy Doc Marathon continues
Message-ID: <wl8vdn64hpf.fsf@glup.physics.ucf.edu>

		   Let's Finish Documenting SciPy!

Last year, we began the SciPy Documentation Marathon to write
reference pages ("docstrings") for NumPy and SciPy.  It was a huge
job, bigger than we first imagined, with NumPy alone having over 2,000
functions.

We created the doc wiki (now at docs.scipy.org), where you write,
review, and proofread docs that then get integrated into the source
code.  In September, we had over 55% of NumPy in the "first draft"
stage, and about 25% to the "needs review" stage.  The PDF NumPy
Reference Guide was over 300 pages, nicely formatted by ReST, which
makes an HTML version as well.  The PDF document now has over 500
pages, with the addition of sections from Travis Oliphant's book Guide
to NumPy.

That's an amazing amount of work, possible through the contributions
of over 30 volunteers.  It came back to us as the vastly-expanded help
pages in NumPy 1.2, released last September.

With your help, WE CAN FINISH!  This summer we can:

- Write all the "important" NumPy pages to the "Needs Review" stage
- Start documenting the SciPy package
- Get the SciPy User Manual started
- Implement dual review - technical and presentation - on the doc wiki
- Get NumPy docs and packaging on a sound financial footing

We'll start with the first two.  UCF has hired David Goldsmith to lead
this summer's doc effort.  David will write a lot of docs himself, but
more importantly, he will organize our efforts toward completing doc
milestones.  There will be rewards, T-shirts, and likely other fun
stuff for those who contribute the most.  David will start the ball
rolling shortly.

This is a big vision, and it will require YOUR help to make it happen!

The main need now is for people to work on the reference pages.
Here's how:

1. Go to http://docs.scipy.org/NumPy
2. Read the intro and doc standards, and some docstrings on the wiki
3. Make an account
4. Ask the scipy-dev at scipy.org email list for editor access
5. EDIT!

All doc discussions (except announcements like this one) should happen
on the scipy-dev at scipy.org email list.  You can browse the archives
and sign up for the list at http://scipy.org/Mailing_Lists .  That's
where we will announce sprints on topic areas and so on.

We'll also meet online every week, Wednesdays at 4:30pm US Eastern Time,
on Skype.  David will give the details.

Welcome back to the Marathon!

--jh--
Prof. Joseph Harrington
Planetary Sciences Group
Department of Physics
MAP 414
4000 Central Florida Blvd.
University of Central Florida
Orlando, FL 32816-2385
jh at physics.ucf.edu
planets.ucf.edu



From d_l_goldsmith at yahoo.com  Mon Jun  8 17:55:02 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 8 Jun 2009 14:55:02 -0700 (PDT)
Subject: [SciPy-dev] Summer NumPy Doc Marathon (Reply-to:
	scipy-dev@scipy.org)
Message-ID: <110298.95028.qm@web52107.mail.re2.yahoo.com>


Dear SciPy Community Members:

     Hi!  My name is David Goldsmith.  I've been hired for the summer by Joe Harrington to further progress on NumPy documentation and ultimately, pending funding, SciPy documentation.  Joe and I are reviving last summer?s enthusiasm in the community for this mission and enlisting as many of you as possible in the effort.  On that note, please peruse the NumPy Doc Wiki (http://docs.scipy.org/numpy/Front Page/) and, in particular, the master list of functions/objects (?items?) needing work
(http://docs.scipy.org/numpy/Milestones/).  Our goal is to have every item to the ready-for-first-review stage (or better) by August 18 (i.e., the start of SciPyCon09).  To accomplish this, we're forming teams to attack each doc category on the Milestones page.

     From the Milestones page:

"To speed things up, get more uniformity in the docs, and add a social element, we're attacking these categories as teams. A team lead takes responsibility for getting a category to "Needs review" within one month [we expect that some categories will require less time ? please furnish your most ?optimistically realistic? deadline when ?claiming? a category], but no later than 18 August 2009. As leader, you commit to working with anyone who signs up in your category, and vice versa. The scipy-dev mailing list is a great place to recruit helpers.

"Major doc contributors will be listed in NumPy's contributors file, THANKS.txt. Anyone writing more than 1000 words will get a T-shirt (while supplies last, etc.). Teams that reach their goals in time will get special mention in THANKS.txt.

"Of course, you don't have to join a team. If you'd like to work on your own, please choose docstrings from an unclaimed category, and put your name after docstrings you are editing in the list below. If someone later claims that category, please coordinate with them or finish up your current docstrings and move to another category."

     Please note that, to edit anything on the Wiki (including the doc itself), you?ll need ?edit rights? ? how you get these is Item 5 under ?Before you start? on the ?Front Page,? but for your convenience, I?ll quote that here:

"Register a username on [docs.scipy.org]. Send an e-mail with your username to the scipy-dev mailing list (requires subscribing to the mailing list first, [which can be done at
http://mail.scipy.org/mailman/listinfo/scipy-dev]), so that we can give you edit rights. If you are not subscribed to the mailing-list, you can also send an email to gael dot varoquaux at normalesup dot org, but this will take longer [and you?ll want to subscribe to scipy-dev anyway, because that?s the place to post questions and comments about this whole doc development project]."

     Also, I?ll be holding a weekly Skype (www.skype.com) telecon ? Wednesdays at 4:30pm US Eastern Daylight Time - to review progress and discuss any roadblocks we may have encountered (or anticipate encountering).  If you?d like to participate and haven?t already downloaded and installed Skype and registered a Skype ID, you should do those things; then, you'll be able to join in simply by "Skyping" me (Skype ID: d.l.goldsmith) and I'll add you to the call.

     So, thanks for your time reading this, and please make time this summer to help us meet (or beat) the goal.

Sincerely,

David Goldsmith, Technical Editor
Olympia, WA


      


From mtrumpis at berkeley.edu  Mon Jun  8 18:31:09 2009
From: mtrumpis at berkeley.edu (M Trumpis)
Date: Mon, 8 Jun 2009 15:31:09 -0700
Subject: [SciPy-dev] more with SVD wrapping
Message-ID: <be3bc680906081531m15aa5acic810f553deea4034@mail.gmail.com>

Hi all,

While I was playing with the f2py wrappings for SVD routines, I went
ahead and beefed up the *gesdd and *gesvd interfaces, and added a
wrapping for the "generalized SVD" wrappings, *ggsvd.

improvements to svd:
* can query the lapack drivers for best workspace size--this
eliminates the need for the code in "calc_lwork.f".
* can ask the drivers to return compact matrices: a = (m x n) ==> u =
(m x min(m,n)), vh = (min(m,n) x n)

Use of the *gesvd driver can be toggled with an argument:
scipy.linalg.svd( ... , fast_svd=False)

I made two scipy interpretations of the GSVD, one corresponding to the
lapack docs, and one that is more like the matlab version.

This ticket supercedes ticket 957.

http://projects.scipy.org/scipy/ticket/964

Kind regards,
Mike


From nwagner at iam.uni-stuttgart.de  Tue Jun  9 01:21:53 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 09 Jun 2009 07:21:53 +0200
Subject: [SciPy-dev] more with SVD wrapping
In-Reply-To: <be3bc680906081531m15aa5acic810f553deea4034@mail.gmail.com>
References: <be3bc680906081531m15aa5acic810f553deea4034@mail.gmail.com>
Message-ID: <web-120983424@uni-stuttgart.de>

On Mon, 8 Jun 2009 15:31:09 -0700
  M Trumpis <mtrumpis at berkeley.edu> wrote:
> Hi all,
> 
> While I was playing with the f2py wrappings for SVD 
>routines, I went
> ahead and beefed up the *gesdd and *gesvd interfaces, 
>and added a
> wrapping for the "generalized SVD" wrappings, *ggsvd.
> 
> improvements to svd:
> * can query the lapack drivers for best workspace 
>size--this
> eliminates the need for the code in "calc_lwork.f".
> * can ask the drivers to return compact matrices: a = (m 
>x n) ==> u =
> (m x min(m,n)), vh = (min(m,n) x n)
> 
> Use of the *gesvd driver can be toggled with an 
>argument:
> scipy.linalg.svd( ... , fast_svd=False)
> 
> I made two scipy interpretations of the GSVD, one 
>corresponding to the
> lapack docs, and one that is more like the matlab 
>version.
> 
> This ticket supercedes ticket 957.
> 
> http://projects.scipy.org/scipy/ticket/964
> 
> Kind regards,
> Mike
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

Hi all,

In view of your recent work ticket 216 could be closed.
  
  http://projects.scipy.org/scipy/ticket/216


Cheers,
                    Nils


From d_l_goldsmith at yahoo.com  Tue Jun  9 02:11:59 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 8 Jun 2009 23:11:59 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <901731.25166.qm@web52108.mail.re2.yahoo.com>


Hi again, folks.  I have a special request.  Part of the vision for my job is that I'll focus my writing efforts on the docs no one else is gung-ho to work on.  So, even if you're not quite ready to commit, if you're leaning toward volunteering to be a team lead for one (or more) categories, please let me know which one(s) (off list, if you prefer) so I can get an initial idea of what the "leftovers" are going to be.  Thanks!

DG


      


From stefan at sun.ac.za  Tue Jun  9 04:34:49 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 9 Jun 2009 10:34:49 +0200
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <901731.25166.qm@web52108.mail.re2.yahoo.com>
References: <901731.25166.qm@web52108.mail.re2.yahoo.com>
Message-ID: <9457e7c80906090134r54d16badqeb19e7890838f64d@mail.gmail.com>

Hi David

2009/6/9 David Goldsmith <d_l_goldsmith at yahoo.com>:
>
> Hi again, folks. ?I have a special request. ?Part of the vision for my job is that I'll focus my writing efforts on the docs no one else is gung-ho to work on. ?So, even if you're not quite ready to commit, if you're leaning toward volunteering to be a team lead for one (or more) categories, please let me know which one(s) (off list, if you prefer) so I can get an initial idea of what the "leftovers" are going to be. ?Thanks!

That's a pretty wide question.  Maybe you could post a list of
categories and ask who would be willing to mentor and write on each?
For the writing, we could decide on a prioritised list of functions,
publish that list and then document those entries one by one (i.e.
make the tasks small enough so that people don't run away screaming).

Cheers
St?fan


From scott.sinclair.za at gmail.com  Tue Jun  9 05:11:22 2009
From: scott.sinclair.za at gmail.com (Scott Sinclair)
Date: Tue, 9 Jun 2009 11:11:22 +0200
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <9457e7c80906090134r54d16badqeb19e7890838f64d@mail.gmail.com>
References: <901731.25166.qm@web52108.mail.re2.yahoo.com>
	<9457e7c80906090134r54d16badqeb19e7890838f64d@mail.gmail.com>
Message-ID: <6a17e9ee0906090211l76422f0blf79b36363846cd69@mail.gmail.com>

>2009/6/9 St?fan van der Walt <stefan at sun.ac.za>:
> Hi David
>
> 2009/6/9 David Goldsmith <d_l_goldsmith at yahoo.com>:
>>
>> Hi again, folks. ?I have a special request. ?Part of the vision for my job is that I'll focus my writing efforts on the docs no one else is >
> That's a pretty wide question. ?Maybe you could post a list of
> categories and ask who would be willing to mentor and write on each?
> For the writing, we could decide on a prioritised list of functions,
> publish that list and then document those entries one by one (i.e.
> make the tasks small enough so that people don't run away screaming).

I think that's why http://docs.scipy.org/numpy/Milestones/ exists.
It's decent starting point at least..

Cheers,
Scott


From jackliddlephysics at googlemail.com  Tue Jun  9 08:20:14 2009
From: jackliddlephysics at googlemail.com (Jack Liddle)
Date: Tue, 9 Jun 2009 14:20:14 +0200
Subject: [SciPy-dev] Summer NumPy Doc Marathon (Reply-to:
	scipy-dev@scipy.org)
In-Reply-To: <110298.95028.qm@web52107.mail.re2.yahoo.com>
References: <110298.95028.qm@web52107.mail.re2.yahoo.com>
Message-ID: <6ebdbcf10906090520h4fe9c6bbmf126ee33c0749491@mail.gmail.com>

Hi Everyone,

Something at http://docs.scipy.org/numpy/accounts/register/ is broken
I get a '500 Internal Error' when I try and register for an id.

Thanks

Jack Liddle

2009/6/8 David Goldsmith <d_l_goldsmith at yahoo.com>:
>
> Dear SciPy Community Members:
>
> ? ? Hi! ?My name is David Goldsmith. ?I've been hired for the summer by Joe Harrington to further progress on NumPy documentation and ultimately, pending funding, SciPy documentation. ?Joe and I are reviving last summer?s enthusiasm in the community for this mission and enlisting as many of you as possible in the effort. ?On that note, please peruse the NumPy Doc Wiki (http://docs.scipy.org/numpy/Front Page/) and, in particular, the master list of functions/objects (?items?) needing work
> (http://docs.scipy.org/numpy/Milestones/). ?Our goal is to have every item to the ready-for-first-review stage (or better) by August 18 (i.e., the start of SciPyCon09). ?To accomplish this, we're forming teams to attack each doc category on the Milestones page.
>
> ? ? From the Milestones page:
>
> "To speed things up, get more uniformity in the docs, and add a social element, we're attacking these categories as teams. A team lead takes responsibility for getting a category to "Needs review" within one month [we expect that some categories will require less time ? please furnish your most ?optimistically realistic? deadline when ?claiming? a category], but no later than 18 August 2009. As leader, you commit to working with anyone who signs up in your category, and vice versa. The scipy-dev mailing list is a great place to recruit helpers.
>
> "Major doc contributors will be listed in NumPy's contributors file, THANKS.txt. Anyone writing more than 1000 words will get a T-shirt (while supplies last, etc.). Teams that reach their goals in time will get special mention in THANKS.txt.
>
> "Of course, you don't have to join a team. If you'd like to work on your own, please choose docstrings from an unclaimed category, and put your name after docstrings you are editing in the list below. If someone later claims that category, please coordinate with them or finish up your current docstrings and move to another category."
>
> ? ? Please note that, to edit anything on the Wiki (including the doc itself), you?ll need ?edit rights? ? how you get these is Item 5 under ?Before you start? on the ?Front Page,? but for your convenience, I?ll quote that here:
>
> "Register a username on [docs.scipy.org]. Send an e-mail with your username to the scipy-dev mailing list (requires subscribing to the mailing list first, [which can be done at
> http://mail.scipy.org/mailman/listinfo/scipy-dev]), so that we can give you edit rights. If you are not subscribed to the mailing-list, you can also send an email to gael dot varoquaux at normalesup dot org, but this will take longer [and you?ll want to subscribe to scipy-dev anyway, because that?s the place to post questions and comments about this whole doc development project]."
>
> ? ? Also, I?ll be holding a weekly Skype (www.skype.com) telecon ? Wednesdays at 4:30pm US Eastern Daylight Time - to review progress and discuss any roadblocks we may have encountered (or anticipate encountering). ?If you?d like to participate and haven?t already downloaded and installed Skype and registered a Skype ID, you should do those things; then, you'll be able to join in simply by "Skyping" me (Skype ID: d.l.goldsmith) and I'll add you to the call.
>
> ? ? So, thanks for your time reading this, and please make time this summer to help us meet (or beat) the goal.
>
> Sincerely,
>
> David Goldsmith, Technical Editor
> Olympia, WA
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From pav at iki.fi  Tue Jun  9 08:34:28 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 9 Jun 2009 12:34:28 +0000 (UTC)
Subject: [SciPy-dev] Summer NumPy Doc Marathon
References: <110298.95028.qm@web52107.mail.re2.yahoo.com>
	<6ebdbcf10906090520h4fe9c6bbmf126ee33c0749491@mail.gmail.com>
Message-ID: <h0lksk$am8$1@ger.gmane.org>

Tue, 09 Jun 2009 14:20:14 +0200, Jack Liddle kirjoitti:
> Something at http://docs.scipy.org/numpy/accounts/register/ is broken
> I get a '500 Internal Error' when I try and register for an id.

Sorry, fixed.

-- 
Pauli Virtanen



From bsouthey at gmail.com  Tue Jun  9 10:00:33 2009
From: bsouthey at gmail.com (Bruce Southey)
Date: Tue, 09 Jun 2009 09:00:33 -0500
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <6a17e9ee0906090211l76422f0blf79b36363846cd69@mail.gmail.com>
References: <901731.25166.qm@web52108.mail.re2.yahoo.com>	<9457e7c80906090134r54d16badqeb19e7890838f64d@mail.gmail.com>
	<6a17e9ee0906090211l76422f0blf79b36363846cd69@mail.gmail.com>
Message-ID: <4A2E6B01.1090602@gmail.com>

Scott Sinclair wrote:
>> 2009/6/9 St?fan van der Walt <stefan at sun.ac.za>:
>> Hi David
>>
>> 2009/6/9 David Goldsmith <d_l_goldsmith at yahoo.com>:
>>     
>>> Hi again, folks.  I have a special request.  Part of the vision for my job is that I'll focus my writing efforts on the docs no one else is >
>>>       
>> That's a pretty wide question.  Maybe you could post a list of
>> categories and ask who would be willing to mentor and write on each?
>> For the writing, we could decide on a prioritised list of functions,
>> publish that list and then document those entries one by one (i.e.
>> make the tasks small enough so that people don't run away screaming).
>>     
>
> I think that's why http://docs.scipy.org/numpy/Milestones/ exists.
> It's decent starting point at least..
>
> Cheers,
> Scott
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   
Hi,
Great.
Can you provide the actual colors at the start for :
    * Edit white, light gray, or yellow
    * Don't edit dark gray

While not color-blind, not all browsers render the same colors on all 
operating systems etc.
What are you using for light gray or is that meant to be blue. If it is 
'blue' then what does it mean?
It appears to be the same color used on the Front Page to say 'Proofed'.

What does the 'green' color mean?
The links says 'Reviewed (needs proof)'  but how does one say 'proofed'.

Also the milestone link from the Front Page does not go anywhere:
http://docs.scipy.org/numpy/Front%20Page/#milestones

Bruce





From scott.sinclair.za at gmail.com  Tue Jun  9 10:12:28 2009
From: scott.sinclair.za at gmail.com (Scott Sinclair)
Date: Tue, 9 Jun 2009 16:12:28 +0200
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <4A2E6B01.1090602@gmail.com>
References: <901731.25166.qm@web52108.mail.re2.yahoo.com>
	<9457e7c80906090134r54d16badqeb19e7890838f64d@mail.gmail.com>
	<6a17e9ee0906090211l76422f0blf79b36363846cd69@mail.gmail.com>
	<4A2E6B01.1090602@gmail.com>
Message-ID: <6a17e9ee0906090712k31b4a019p6c0f07246e6133ca@mail.gmail.com>

>2009/6/9 Bruce Southey <bsouthey at gmail.com>:
> Also the milestone link from the Front Page does not go anywhere:
> http://docs.scipy.org/numpy/Front%20Page/#milestones

This is fixed now.

Cheers,
Scott


From d_l_goldsmith at yahoo.com  Tue Jun  9 12:31:25 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 09:31:25 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <667868.5819.qm@web52110.mail.re2.yahoo.com>


Thanks, Stefan.  The lists you suggest already exist (more or less, depending on the "thing," i.e., list of categories, completely, prioritized list of individual items, sort of, at least w/in the categories) on the Milestones page (that's essentially what the Milestones page is) and the list of individual items is far too long to duplicate here, but for everyone's convenience I'll provide the list of categories (at least those for which the goal has not been, or is not close to being, met, which is most of them):

Data type investigation
Fourier transforms
Linear algebra
Error handling
Financial functions
Functional operations
Help routines
Indexing
Input/Output
Logic, comparisons etc.
Polynomials
Random number generation
Other random operations
Boolean set operations
Searching
Sorting
Statistics
Comparison
Window functions
Sums, interpolation, gradients, etc
Arithmetic + basic functions I
Arithmetic + basic functions II
Arithmetic + basic functions III
Masked arrays
Masked arrays, II
Masked arrays, III
Masked arrays, IV
Operations on masks
Even more MA functions I
Even more MA functions II
Numpy internals
C-types
Other math
The matrix library
Numarray compatibility
Numeric compatibility
Other array subclasses
Matrix subclass
Ndarray
Ndarray, II
Dtypes
Ufunc
Scalar base class
Scalar types

Comments:

0) The number of individual items in each of these categories varies from one to a few dozen or so

1) Omitted are a few "meta-categories," e.g., "Routines," "Basic Objects," etc.

2) IMO, there are still too many of these (at least too many to not be intimidating in the manner Stefan has implied); I had it in mind to try to create an intermediate level of organization, i.e., "meso-categories," but I couldn't really justify it on grounds other than there are simply still too many categories to be unintimidating, so I was advised against usage of time in that endeavor.  However, if there's an outpouring of support for me doing that, it would fall on sympathetic ears.

As far as prioritizing individual items, my opinion is that team leads should do that (or not, as they deem appropriate) - I wouldn't presume to know enough to do that in most cases.  However, if people want to furnish me with suggested prioritizations, I'd be happy to be the one to edit the Wiki to reflect these.

DG

--- On Tue, 6/9/09, St?fan van der Walt <stefan at sun.ac.za> wrote:

> From: St?fan van der Walt <stefan at sun.ac.za>
> Subject: Re: [SciPy-dev] More on Summer NumPy Doc Marathon
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Tuesday, June 9, 2009, 1:34 AM
> Hi David
> 
> 2009/6/9 David Goldsmith <d_l_goldsmith at yahoo.com>:
> >
> > Hi again, folks. ?I have a special request. ?Part of
> the vision for my job is that I'll focus my writing efforts
> on the docs no one else is gung-ho to work on. ?So, even if
> you're not quite ready to commit, if you're leaning toward
> volunteering to be a team lead for one (or more) categories,
> please let me know which one(s) (off list, if you prefer) so
> I can get an initial idea of what the "leftovers" are going
> to be. ?Thanks!
> 
> That's a pretty wide question.? Maybe you could post a
> list of
> categories and ask who would be willing to mentor and write
> on each?
> For the writing, we could decide on a prioritised list of
> functions,
> publish that list and then document those entries one by
> one (i.e.
> make the tasks small enough so that people don't run away
> screaming).
> 
> Cheers
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 13:31:47 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 10:31:47 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <570350.72787.qm@web52101.mail.re2.yahoo.com>


Thanks, Bruce.

--- On Tue, 6/9/09, Bruce Southey <bsouthey at gmail.com> wrote:

> Hi,
> Great.
> Can you provide the actual colors at the start for :
> ? ? * Edit white, light gray, or yellow
> ? ? * Don't edit dark gray
> While not color-blind, not all browsers render the same
> colors on all 
> operating systems etc.
> What are you using for light gray or is that meant to be
> blue. If it is 
> 'blue' then what does it mean?
> It appears to be the same color used on the Front Page to
> say 'Proofed'.

Yes, by all means, I agree 100% (I'm having the same problem). :-)  In fact, I think (and have thought) that the light and dark grey and cyan are all too close to each other - anyone object to me replacing the greys w/ orange and lavender?

> What does the 'green' color mean?
> The links says 'Reviewed (needs proof)'? but how does
> one say 'proofed'.

Cyan (if I understand you correctly).

> Also the milestone link from the Front Page does not go
> anywhere:
> http://docs.scipy.org/numpy/Front%20Page/#milestones

Ooops, accidentally broke that editing the page to make the Milestones link more prominent - I'll fix it imminently.

Thanks again,

DG
> 
> Bruce
> 
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 13:41:21 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 10:41:21 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <988376.79271.qm@web52101.mail.re2.yahoo.com>


> Also the milestone link from the Front Page does not go
> anywhere:
> http://docs.scipy.org/numpy/Front%20Page/#milestones

Fixed.

DG


      


From ralf.gommers at googlemail.com  Tue Jun  9 13:54:37 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 9 Jun 2009 13:54:37 -0400
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <570350.72787.qm@web52101.mail.re2.yahoo.com>
References: <570350.72787.qm@web52101.mail.re2.yahoo.com>
Message-ID: <dde7764a0906091054m61c50f7flf774a20d2e20e5c1@mail.gmail.com>

Hi,

It's great to see the enthusiasm for getting started again, I hope we as
much or more done as last year.

On Tue, Jun 9, 2009 at 1:31 PM, David Goldsmith <d_l_goldsmith at yahoo.com>wrote:

>
> Thanks, Bruce.
>
> --- On Tue, 6/9/09, Bruce Southey <bsouthey at gmail.com> wrote:
>
> > Hi,
> > Great.
> > Can you provide the actual colors at the start for :
> >     * Edit white, light gray, or yellow
> >     * Don't edit dark gray
> > While not color-blind, not all browsers render the same
> > colors on all
> > operating systems etc.
> > What are you using for light gray or is that meant to be
> > blue. If it is
> > 'blue' then what does it mean?
> > It appears to be the same color used on the Front Page to
> > say 'Proofed'.
>
> Yes, by all means, I agree 100% (I'm having the same problem). :-)  In
> fact, I think (and have thought) that the light and dark grey and cyan are
> all too close to each other - anyone object to me replacing the greys w/
> orange and lavender?
>

Orange is already being used for "Needs review (revised)", and lavender
would be maybe be close to the blue that means Proofed. I assume the colors
where chosen together, if you want colors that are better distinguishable
pick all new ones. See for example here: http://colorschemedesigner.com/ and
compare "complement" to "tetrad".

>
> > What does the 'green' color mean?
> > The links says 'Reviewed (needs proof)'  but how does
> > one say 'proofed'.
>

Doc writers with standard permissions can not move pages to Proofed, the
idea is that a few qualified people do that I think. From
http://scipy.org/Developer_Zone :
"Please list yourself if you are willing to proofread whatever anyone has
written, have prepared manuscripts for publication, AND consider yourself an
English grammarian. If you know when to use "which" and when to use "that"
when introducing relative
clauses<http://separatedbyacommonlanguage.blogspot.com/2006/08/which-vs-that.html>,
and if "different than" stimulates you like nails on a blackboard, sign up
here!"

We want to get all docstrings up to Ready for Review, so no need to worry
about proofing too much yet.


>
> Cyan (if I understand you correctly).
>
> > Also the milestone link from the Front Page does not go
> > anywhere:
> > http://docs.scipy.org/numpy/Front%20Page/#milestones
>
> Ooops, accidentally broke that editing the page to make the Milestones link
> more prominent - I'll fix it imminently.
>
> Thanks again,
>
> DG
> >
> > Bruce
> >
>


Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090609/bf7508a3/attachment.html>

From ralf.gommers at googlemail.com  Tue Jun  9 14:07:14 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 9 Jun 2009 14:07:14 -0400
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <667868.5819.qm@web52110.mail.re2.yahoo.com>
References: <667868.5819.qm@web52110.mail.re2.yahoo.com>
Message-ID: <dde7764a0906091107x6de3e98ci1b7609061e37b077@mail.gmail.com>

On Tue, Jun 9, 2009 at 12:31 PM, David Goldsmith <d_l_goldsmith at yahoo.com>wrote:

>
> Thanks, Stefan.  The lists you suggest already exist (more or less,
> depending on the "thing," i.e., list of categories, completely, prioritized
> list of individual items, sort of, at least w/in the categories) on the
> Milestones page (that's essentially what the Milestones page is) and the
> list of individual items is far too long to duplicate here, but for
> everyone's convenience I'll provide the list of categories (at least those
> for which the goal has not been, or is not close to being, met, which is
> most of them):
>
> Data type investigation
> Fourier transforms
> Linear algebra
> Error handling
> Financial functions
> Functional operations
> Help routines
> Indexing
> Input/Output
> Logic, comparisons etc.
> Polynomials
> Random number generation
> Other random operations
> Boolean set operations
> Searching
> Sorting
> Statistics
> Comparison
> Window functions
> Sums, interpolation, gradients, etc
> Arithmetic + basic functions I
> Arithmetic + basic functions II
> Arithmetic + basic functions III
> Masked arrays
> Masked arrays, II
> Masked arrays, III
> Masked arrays, IV
> Operations on masks
> Even more MA functions I
> Even more MA functions II
> Numpy internals
> C-types
> Other math
> The matrix library
> Numarray compatibility
> Numeric compatibility
> Other array subclasses
> Matrix subclass
> Ndarray
> Ndarray, II
> Dtypes
> Ufunc
> Scalar base class
> Scalar types
>
> Comments:
>
> 0) The number of individual items in each of these categories varies from
> one to a few dozen or so
>
> 1) Omitted are a few "meta-categories," e.g., "Routines," "Basic Objects,"
> etc.
>
> 2) IMO, there are still too many of these (at least too many to not be
> intimidating in the manner Stefan has implied); I had it in mind to try to
> create an intermediate level of organization, i.e., "meso-categories," but I
> couldn't really justify it on grounds other than there are simply still too
> many categories to be unintimidating, so I was advised against usage of time
> in that endeavor.  However, if there's an outpouring of support for me doing
> that, it would fall on sympathetic ears.
>
> As far as prioritizing individual items, my opinion is that team leads
> should do that (or not, as they deem appropriate) - I wouldn't presume to
> know enough to do that in most cases.  However, if people want to furnish me
> with suggested prioritizations, I'd be happy to be the one to edit the Wiki
> to reflect these.
>
> DG
>


Of this list of categories, there are 14 that are either completely done or
have only one docstring in white / light-gray. So it is a less intimidating
than it looks:) And I like the size of the categories, many of them are
small enough that you can finish them in a weekend.

I don't know if there's a need to prioritize, but I would ask people with
in-depth knowledge of numpy to pick some of the ones that require that
knowledge. Some of these are (basically, stuff towards the bottom of the
page):
Numpy internals
Ufuncs
Dtypes
Numarray compatibility
Numeric compatibility
Other array subclasses
Scalar base class
Scalar types

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090609/99a8c9a9/attachment.html>

From d_l_goldsmith at yahoo.com  Tue Jun  9 14:34:55 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 11:34:55 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <794631.23975.qm@web52112.mail.re2.yahoo.com>


Thanks, Ralf.

--- On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:

> Of this list of categories, there are 14 that are either
> completely done or have only one docstring in white /
> light-gray. So it is a less intimidating than it looks:) And
> I like the size of the categories, many of them are small
> enough that you can finish them in a weekend.

Yup, sorry I didn't do better QC in this regard before sending this out.

> I don't know if there's a need to prioritize, but I
> would ask people with in-depth knowledge of numpy to pick
> some of the ones that require that knowledge. Some of these

Thank _you_ for asking! ;-)

DG

> are (basically, stuff towards the bottom of the page):
> 
> Numpy internals
> Ufuncs
> Dtypes
> Numarray compatibility
> 
> Numeric compatibility
> 
> Other array subclasses
> Scalar base class
> 
> Scalar types
> 
> Cheers,
> Ralf
> 
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From ralf.gommers at googlemail.com  Tue Jun  9 15:48:36 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 9 Jun 2009 15:48:36 -0400
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <794631.23975.qm@web52112.mail.re2.yahoo.com>
References: <794631.23975.qm@web52112.mail.re2.yahoo.com>
Message-ID: <dde7764a0906091248t3f002dady554df671e9056a7f@mail.gmail.com>

On Tue, Jun 9, 2009 at 2:34 PM, David Goldsmith <d_l_goldsmith at yahoo.com>wrote:

>
> Thanks, Ralf.
>
> --- On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
>
> > Of this list of categories, there are 14 that are either
> > completely done or have only one docstring in white /
> > light-gray. So it is a less intimidating than it looks:) And
> > I like the size of the categories, many of them are small
> > enough that you can finish them in a weekend.
>
> Yup, sorry I didn't do better QC in this regard before sending this out.
>
> > I don't know if there's a need to prioritize, but I
> > would ask people with in-depth knowledge of numpy to pick
> > some of the ones that require that knowledge. Some of these
>
> Thank _you_ for asking! ;-)
>

Sorry, I'm not trying to do your job for you:)

One other thing, would it be possible to get a permanent link to Milestones
at the top of each page, next to Docstrings, Changes, etc?

Cheers,
Ralf



> DG
>
> > are (basically, stuff towards the bottom of the page):
> >
> > Numpy internals
> > Ufuncs
> > Dtypes
> > Numarray compatibility
> >
> > Numeric compatibility
> >
> > Other array subclasses
> > Scalar base class
> >
> > Scalar types
> >
> > Cheers,
> > Ralf
> >
> >
> >
> >
> >
> > -----Inline Attachment Follows-----
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090609/b3d2263b/attachment.html>

From d_l_goldsmith at yahoo.com  Tue Jun  9 17:53:53 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 14:53:53 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <111097.39080.qm@web52109.mail.re2.yahoo.com>


--- On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:

> One other thing, would it be possible to get a permanent
> link to Milestones at the top of each page, next to
> Docstrings, Changes, etc?

Certainly; the only question, Wiki Developers, is: can it be added programatically (so that I don't have to add it manually to every page)?

Thanks again,

DG
> 
> 
> Cheers,
> Ralf
> ?
> 
> 
> 
> DG
> 
> 
> 
> > are (basically, stuff towards the bottom of the
> page):
> 
> >
> 
> > Numpy internals
> 
> > Ufuncs
> 
> > Dtypes
> 
> > Numarray compatibility
> 
> >
> 
> > Numeric compatibility
> 
> >
> 
> > Other array subclasses
> 
> > Scalar base class
> 
> >
> 
> > Scalar types
> 
> >
> 
> > Cheers,
> 
> > Ralf
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > -----Inline Attachment Follows-----
> 
> >
> 
> > _______________________________________________
> 
> > 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
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 18:06:25 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 15:06:25 -0700 (PDT)
Subject: [SciPy-dev] Mainly for the numpy doc wiki developers
Message-ID: <504489.60284.qm@web52109.mail.re2.yahoo.com>


How hard would it be to add a ticket system to the Wiki?

DG


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 19:53:14 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 16:53:14 -0700 (PDT)
Subject: [SciPy-dev] New colors
Message-ID: <337178.34418.qm@web52108.mail.re2.yahoo.com>


--- On Tue, 6/9/09, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:

> --- On Tue, 6/9/09, Bruce Southey <bsouthey at gmail.com>
> wrote:
> > Can you provide the actual colors at the start for :
> > ? ? * Edit white, light gray, or yellow
> > ? ? * Don't edit dark gray
> > While not color-blind, not all browsers render the
> same
> > colors on all 
> > operating systems etc.
> > What are you using for light gray or is that meant to
> be
> > blue. If it is 
> > 'blue' then what does it mean?
> > It appears to be the same color used on the Front Page
> to
> > say 'Proofed'.
> 
> Yes, by all means, I agree 100% (I'm having the same
> problem). :-)? In fact, I think (and have thought) that
> the light and dark grey and cyan are all too close to each
> other - anyone object to me replacing the greys w/ orange
> and lavender?

Duh, I just realized this too has to be done at the Wiki code level - Wiki Devs?  Please?  Thanks!

DG


      


From d_l_goldsmith at yahoo.com  Wed Jun 10 00:51:13 2009
From: d_l_goldsmith at yahoo.com (d_l_goldsmith at yahoo.com)
Date: Tue, 9 Jun 2009 21:51:13 -0700 (PDT)
Subject: [SciPy-dev] tanh(j*pi/2)
Message-ID: <389425.41638.qm@web52107.mail.re2.yahoo.com>


>>> import numpy as N
>>> N.tanh(N.pi*1j/2)
16331778728383844j

Is this the desired behavior?? (I.e., why doesn't this return N.inf or N.nan?)

DG



      


From robert.kern at gmail.com  Wed Jun 10 00:56:55 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 9 Jun 2009 23:56:55 -0500
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <389425.41638.qm@web52107.mail.re2.yahoo.com>
References: <389425.41638.qm@web52107.mail.re2.yahoo.com>
Message-ID: <3d375d730906092156ofc2a86fq325556ee8c14e6fd@mail.gmail.com>

On Tue, Jun 9, 2009 at 23:51, <d_l_goldsmith at yahoo.com> wrote:
>
>>>> import numpy as N
>>>> N.tanh(N.pi*1j/2)
> 16331778728383844j
>
> Is this the desired behavior?

It's what floating point arithmetic gives us. N.pi/2 is not precisely
the real number pi/2 so cos(N.pi/2) is not precisely 0 so
2/cos(N.pi/2) is not inf or nan.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Wed Jun 10 01:06:12 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 22:06:12 -0700 (PDT)
Subject: [SciPy-dev] tanh(j*pi/2)
Message-ID: <52845.54066.qm@web52101.mail.re2.yahoo.com>


Understood, thanks.  Just curious: can N.allclose be used w/ N.inf, or does one need to reciprocate first?

DG

--- On Tue, 6/9/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] tanh(j*pi/2)
> To: d_l_goldsmith at yahoo.com, "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Tuesday, June 9, 2009, 9:56 PM
> On Tue, Jun 9, 2009 at 23:51, <d_l_goldsmith at yahoo.com>
> wrote:
> >
> >>>> import numpy as N
> >>>> N.tanh(N.pi*1j/2)
> > 16331778728383844j
> >
> > Is this the desired behavior?
> 
> It's what floating point arithmetic gives us. N.pi/2 is not
> precisely
> the real number pi/2 so cos(N.pi/2) is not precisely 0 so
> 2/cos(N.pi/2) is not inf or nan.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> 


      


From robert.kern at gmail.com  Wed Jun 10 01:10:48 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 10 Jun 2009 00:10:48 -0500
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <52845.54066.qm@web52101.mail.re2.yahoo.com>
References: <52845.54066.qm@web52101.mail.re2.yahoo.com>
Message-ID: <3d375d730906092210j477ea371mf0a6ce1dbbb8a766@mail.gmail.com>

On Wed, Jun 10, 2009 at 00:06, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> Understood, thanks. ?Just curious: can N.allclose be used w/ N.inf, or does one need to reciprocate first?

In [1]: allclose([inf], [inf])
Out[1]: True

The infs are handled specially.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Wed Jun 10 01:46:06 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 22:46:06 -0700 (PDT)
Subject: [SciPy-dev] tanh(j*pi/2)
Message-ID: <658093.91699.qm@web52103.mail.re2.yahoo.com>


No, this is what I meant:

>>> N.allclose([N.tanh(N.pi*1j/2)],[N.inf])
False
>>> N.allclose([1/N.tanh(N.pi*1j/2)],[0.])
True

So in this case, one does need to reciprocate first (or am I using N.allclose wrong in the first example?)

I should probably 'Note' this tanh's doc (and other transcendentals that may exhibit this behavior).

DG 
--- On Tue, 6/9/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] tanh(j*pi/2)
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Tuesday, June 9, 2009, 10:10 PM
> On Wed, Jun 10, 2009 at 00:06, David
> Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > Understood, thanks. ?Just curious: can N.allclose be
> used w/ N.inf, or does one need to reciprocate first?
> 
> In [1]: allclose([inf], [inf])
> Out[1]: True
> 
> The infs are handled specially.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From robert.kern at gmail.com  Wed Jun 10 01:49:55 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 10 Jun 2009 00:49:55 -0500
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <658093.91699.qm@web52103.mail.re2.yahoo.com>
References: <658093.91699.qm@web52103.mail.re2.yahoo.com>
Message-ID: <3d375d730906092249k2b22ee0ai4a56a53ee2f684dc@mail.gmail.com>

On Wed, Jun 10, 2009 at 00:46, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> No, this is what I meant:
>
>>>> N.allclose([N.tanh(N.pi*1j/2)],[N.inf])
> False
>>>> N.allclose([1/N.tanh(N.pi*1j/2)],[0.])
> True
>
> So in this case, one does need to reciprocate first (or am I using N.allclose wrong in the first example?)

Yes. Only inf is "close" to inf.

> I should probably 'Note' this tanh's doc (and other transcendentals that may exhibit this behavior).

<shrug> It's generic to all floating point implementations of
transcendentals. I'd prefer not to clutter up each ufunc's docs. A
section in the User's Guide about floating point arithmetic in general
might be worthwhile, though.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From charlesr.harris at gmail.com  Wed Jun 10 02:16:40 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 10 Jun 2009 00:16:40 -0600
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <3d375d730906092249k2b22ee0ai4a56a53ee2f684dc@mail.gmail.com>
References: <658093.91699.qm@web52103.mail.re2.yahoo.com>
	<3d375d730906092249k2b22ee0ai4a56a53ee2f684dc@mail.gmail.com>
Message-ID: <e06186140906092316r6c67929ar8813eafbd43faf29@mail.gmail.com>

On Tue, Jun 9, 2009 at 11:49 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Wed, Jun 10, 2009 at 00:46, David Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > No, this is what I meant:
> >
> >>>> N.allclose([N.tanh(N.pi*1j/2)],[N.inf])
> > False
> >>>> N.allclose([1/N.tanh(N.pi*1j/2)],[0.])
> > True
> >
> > So in this case, one does need to reciprocate first (or am I using
> N.allclose wrong in the first example?)
>
> Yes. Only inf is "close" to inf.
>
> > I should probably 'Note' this tanh's doc (and other transcendentals that
> may exhibit this behavior).
>
> <shrug> It's generic to all floating point implementations of
> transcendentals. I'd prefer not to clutter up each ufunc's docs. A
> section in the User's Guide about floating point arithmetic in general
> might be worthwhile, though.
>

With examples, too.  And now you have one ;) Examples would help users
understand the implications of the imprecision.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090610/0a70141c/attachment.html>

From d_l_goldsmith at yahoo.com  Wed Jun 10 02:22:28 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 23:22:28 -0700 (PDT)
Subject: [SciPy-dev] tanh(j*pi/2)
Message-ID: <970121.99967.qm@web52107.mail.re2.yahoo.com>


--- On Tue, 6/9/09, Robert Kern <robert.kern at gmail.com> wrote:

> > I should probably 'Note' this tanh's doc (and other
> transcendentals that may exhibit this behavior).
> 
> <shrug> It's generic to all floating point
> implementations of
> transcendentals. I'd prefer not to clutter up each ufunc's
> docs. A
> section in the User's Guide about floating point arithmetic
> in general
> might be worthwhile, though.

With a list of numpy-furnished functions to which the "problem" applies.  (It's one thing to explain the phenomenon in general, and once this is done the "pedestrian" user may then be alert to the danger in source code, but still forget, or simply not realize, that it applies to library functions as well.  Put another way, though one will certainly recognize that their own numerics will be subject to this, they might still expect that standard, furnished mathematical functions will have been written to be more "robust" w/ respect to their exact mathematical properties.  I certainly wouldn't have _expected_ this problem w/ good old regular tan - my default assumption would be that N.tan(N.pi/2) would return N.inf or N.nan, not:
>>> N.tan(N.pi/2)
16331778728383844.0) :-)

DG


      


From robert.kern at gmail.com  Wed Jun 10 02:29:16 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 10 Jun 2009 01:29:16 -0500
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <970121.99967.qm@web52107.mail.re2.yahoo.com>
References: <970121.99967.qm@web52107.mail.re2.yahoo.com>
Message-ID: <3d375d730906092329x21f8b9d6i165c3da4774213f@mail.gmail.com>

On Wed, Jun 10, 2009 at 01:22, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> --- On Tue, 6/9/09, Robert Kern <robert.kern at gmail.com> wrote:
>
>> > I should probably 'Note' this tanh's doc (and other
>> transcendentals that may exhibit this behavior).
>>
>> <shrug> It's generic to all floating point
>> implementations of
>> transcendentals. I'd prefer not to clutter up each ufunc's
>> docs. A
>> section in the User's Guide about floating point arithmetic
>> in general
>> might be worthwhile, though.
>
> With a list of numpy-furnished functions to which the "problem" applies. ?(It's one thing to explain the phenomenon in general, and once this is done the "pedestrian" user may then be alert to the danger in source code, but still forget, or simply not realize, that it applies to library functions as well. ?Put another way, though one will certainly recognize that their own numerics will be subject to this, they might still expect that standard, furnished mathematical functions will have been written to be more "robust" w/ respect to their exact mathematical properties. ?I certainly wouldn't have _expected_ this problem w/ good old regular tan - my default assumption would be that N.tan(N.pi/2) would return N.inf or N.nan, not:
>>>> N.tan(N.pi/2)
> 16331778728383844.0) :-)

Umm, explaining the phenomenon necessarily entails showing examples of
the library functions it applies to. This particular phenomenon is
*about* how the standard, furnished mathematical functions behave,
nothing else. But I don't think a full, explicit list is necessary or
desirable. "Transcendental functions" plus a few notable examples
should cover it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Wed Jun 10 02:49:12 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 23:49:12 -0700 (PDT)
Subject: [SciPy-dev] tanh(j*pi/2)
Message-ID: <430442.17613.qm@web52101.mail.re2.yahoo.com>


--- On Tue, 6/9/09, Robert Kern <robert.kern at gmail.com> wrote:

> Umm, explaining the phenomenon necessarily entails showing
> examples of
> the library functions it applies to. This particular

Good, we're on the same page. :-)

> phenomenon is
> *about* how the standard, furnished mathematical functions
> behave,
> nothing else. But I don't think a full, explicit list is

"Nothing else"?  It doesn't apply to user-written, rational functions and algorithms that may divide by small-modulus numbers that should theoretically be zero?

> necessary or
> desirable. "Transcendental functions" plus a few notable
> examples
> should cover it.

OK, sounds good.

DG



      


From pav at iki.fi  Wed Jun 10 02:58:18 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 10 Jun 2009 06:58:18 +0000 (UTC)
Subject: [SciPy-dev] Mainly for the numpy doc wiki developers
References: <504489.60284.qm@web52109.mail.re2.yahoo.com>
Message-ID: <h0nlia$agj$1@ger.gmane.org>

Tue, 09 Jun 2009 15:06:25 -0700, David Goldsmith kirjoitti:
> How hard would it be to add a ticket system to the Wiki?

This depends on what you mean by a ticket system. The current comment 
system is a half-way hybrid to a ticket system, since you can "close" 
comments.

Another question is also whether a new ticket system is necessary, given 
that we already have Trac, which already has a "Documentation" category.

> On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
> > One other thing, would it be possible to get a permanent link to
> > Milestones at the top of each page, next to Docstrings, Changes, etc?
>
> Certainly; the only question, Wiki Developers, is: can it be added
> programatically (so that I don't have to add it manually to every page)?

It's possible.

-- 
Pauli Virtanen



From stefan at sun.ac.za  Wed Jun 10 02:59:45 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 10 Jun 2009 08:59:45 +0200
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
In-Reply-To: <111097.39080.qm@web52109.mail.re2.yahoo.com>
References: <111097.39080.qm@web52109.mail.re2.yahoo.com>
Message-ID: <9457e7c80906092359t74269e36he9fad1960ea57fb7@mail.gmail.com>

2009/6/9 David Goldsmith <d_l_goldsmith at yahoo.com>:
> Certainly; the only question, Wiki Developers, is: can it be added programatically (so that I don't have to add it manually to every page)?

The sources for the docs editor is available here:

http://code.google.com/p/pydocweb

If you send a patch to Pauli, he'll integrate it.  Sometimes he is
kind enough to make the changes by himself, but ideally we should help
him out.

Cheers
St?fan


From pav at iki.fi  Wed Jun 10 03:01:37 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 10 Jun 2009 07:01:37 +0000 (UTC)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
References: <111097.39080.qm@web52109.mail.re2.yahoo.com>
Message-ID: <h0nloh$agj$2@ger.gmane.org>

Tue, 09 Jun 2009 14:53:53 -0700, David Goldsmith wrote:
> --- On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
> 
>> One other thing, would it be possible to get a permanent link to
>> Milestones at the top of each page, next to Docstrings, Changes, etc?
> 
> Certainly; the only question, Wiki Developers, is: can it be added
> programatically (so that I don't have to add it manually to every page)?

Btw, your email client seems to break References: or In-Reply-To: 
headers, or something similar. At least the threading in gmane.org 
breaks, as the mails appear always as new threads...

-- 
Pauli Virtanen



From pav at iki.fi  Wed Jun 10 03:04:55 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 10 Jun 2009 07:04:55 +0000 (UTC)
Subject: [SciPy-dev] tanh(j*pi/2)
References: <658093.91699.qm@web52103.mail.re2.yahoo.com>
	<3d375d730906092249k2b22ee0ai4a56a53ee2f684dc@mail.gmail.com>
Message-ID: <h0nlun$agj$3@ger.gmane.org>

Wed, 10 Jun 2009 00:49:55 -0500, Robert Kern kirjoitti:
[clip]
> <shrug> It's generic to all floating point implementations of
> transcendentals. I'd prefer not to clutter up each ufunc's docs. A
> section in the User's Guide about floating point arithmetic in general
> might be worthwhile, though.

I also think this stuff belongs to the user guide, and the reference 
guide (ie. the docstrings) should just assume that people know these 
particular basic things about the limitations of floating point.

-- 
Pauli Virtanen



From robert.kern at gmail.com  Wed Jun 10 03:13:54 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 10 Jun 2009 02:13:54 -0500
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <430442.17613.qm@web52101.mail.re2.yahoo.com>
References: <430442.17613.qm@web52101.mail.re2.yahoo.com>
Message-ID: <3d375d730906100013k28219f10i7c6f1c48e94b7e13@mail.gmail.com>

On Wed, Jun 10, 2009 at 01:49, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> --- On Tue, 6/9/09, Robert Kern <robert.kern at gmail.com> wrote:
>
>> Umm, explaining the phenomenon necessarily entails showing
>> examples of
>> the library functions it applies to. This particular
>
> Good, we're on the same page. :-)
>
>> phenomenon is
>> *about* how the standard, furnished mathematical functions
>> behave,
>> nothing else. But I don't think a full, explicit list is
>
> "Nothing else"? ?It doesn't apply to user-written, rational functions and algorithms that may divide by small-modulus numbers that should theoretically be zero?

Ah, that's not the real issue here that I am suggesting to be
documented. The result of cos(np.pi/2) is *not* theoretically 0. This
is because np.pi is not exactly the transcendental real number pi.
This has nothing to do with the quality of implementation of np.cos().
The answer that is given is more accurate than 0.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Wed Jun 10 03:15:02 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 00:15:02 -0700 (PDT)
Subject: [SciPy-dev] Mainly for the numpy doc wiki developers
Message-ID: <36327.85837.qm@web52105.mail.re2.yahoo.com>


--- On Tue, 6/9/09, Pauli Virtanen <pav at iki.fi> wrote:

> David Goldsmith kirjoitti:
> > How hard would it be to add a ticket system to the
> Wiki?
> 
> This depends on what you mean by a ticket system. The
> current comment 
> system is a half-way hybrid to a ticket system, since you
> can "close" 
> comments.
> 
> Another question is also whether a new ticket system is
> necessary, given 
> that we already have Trac, which already has a
> "Documentation" category.

"We already have Trac": is the Wiki built with (or is "on top of" the proper phrase) Trac?  It's Trac's ticket system that I'm familiar with and when I said "ticket system" it was Trac's system that I had in mind, so adding that would be ideal. :-)  

My motivation for having one is largely selfish, but simultaneously masochistic: I'd like a way that is more auto-organizing than haphazard emails for receiving Wiki work requests.

> > On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:
> > > One other thing, would it be possible to get a
> permanent link to
> > > Milestones at the top of each page, next to
> Docstrings, Changes, etc?
> >
> > Certainly; the only question, Wiki Developers, is: can
> it be added
> > programatically (so that I don't have to add it
> manually to every page)?
> 
> It's possible.

Great, thanks!

DG
> 
> -- 
> Pauli Virtanen
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Wed Jun 10 03:17:33 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 00:17:33 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <295309.35372.qm@web52107.mail.re2.yahoo.com>


--- On Tue, 6/9/09, St?fan van der Walt <stefan at sun.ac.za> wrote:

> > Certainly; the only question, Wiki Developers, is: can
> it be added programatically (so that I don't have to add it
> manually to every page)?
> 
> The sources for the docs editor is available here:
> 
> http://code.google.com/p/pydocweb
> 
> If you send a patch to Pauli, he'll integrate it.?
> Sometimes he is
> kind enough to make the changes by himself, but ideally we
> should help
> him out.

OK, I'll try (though Joe might protest: as I understand it, he's paying me to write and edit doc, not code).

DG
> 
> Cheers
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Wed Jun 10 03:18:45 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 00:18:45 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <828047.67735.qm@web52102.mail.re2.yahoo.com>


Sorry, don't know what to do about that.

--- On Wed, 6/10/09, Pauli Virtanen <pav at iki.fi> wrote:

> From: Pauli Virtanen <pav at iki.fi>
> Subject: Re: [SciPy-dev] More on Summer NumPy Doc Marathon
> To: scipy-dev at scipy.org
> Date: Wednesday, June 10, 2009, 12:01 AM
> Tue, 09 Jun 2009 14:53:53 -0700,
> David Goldsmith wrote:
> > --- On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:
> > 
> >> One other thing, would it be possible to get a
> permanent link to
> >> Milestones at the top of each page, next to
> Docstrings, Changes, etc?
> > 
> > Certainly; the only question, Wiki Developers, is: can
> it be added
> > programatically (so that I don't have to add it
> manually to every page)?
> 
> Btw, your email client seems to break References: or
> In-Reply-To: 
> headers, or something similar. At least the threading in
> gmane.org 
> breaks, as the mails appear always as new threads...
> 
> -- 
> Pauli Virtanen
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Wed Jun 10 03:24:14 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 00:24:14 -0700 (PDT)
Subject: [SciPy-dev] tanh(j*pi/2)
Message-ID: <563704.79280.qm@web52106.mail.re2.yahoo.com>


--- On Wed, 6/10/09, Robert Kern <robert.kern at gmail.com> wrote:

> Ah, that's not the real issue here that I am suggesting to
> be
> documented. The result of cos(np.pi/2) is *not*
> theoretically 0. This
> is because np.pi is not exactly the transcendental real
> number pi.
> This has nothing to do with the quality of implementation
> of np.cos().
> The answer that is given is more accurate than 0.

Ah, OK, I see where you're coming from now.

DG



      


From pav at iki.fi  Wed Jun 10 03:32:10 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 10 Jun 2009 07:32:10 +0000 (UTC)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
References: <295309.35372.qm@web52107.mail.re2.yahoo.com>
Message-ID: <h0nnhq$agj$5@ger.gmane.org>

Wed, 10 Jun 2009 00:17:33 -0700, David Goldsmith kirjoitti:

> --- On Tue, 6/9/09, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 
>> > Certainly; the only question, Wiki Developers, is: can
>> it be added programatically (so that I don't have to add it manually to
>> every page)?
>> 
>> The sources for the docs editor is available here:
>> 
>> http://code.google.com/p/pydocweb
>> 
>> If you send a patch to Pauli, he'll integrate it. Sometimes he is
>> kind enough to make the changes by himself, but ideally we should help
>> him out.
> 
> OK, I'll try (though Joe might protest: as I understand it, he's paying
> me to write and edit doc, not code).

The easiest way is to just edit the templates/base.html (or whatever the 
file was), just add the new link after the others. I can also do this 
myself (today evening), as it's a one-line change.

The real fix, as the scope of Pydocweb isn't just Numpy/Scipy though it's 
the main focus, is to allow adding custom links to the top bar. This is 
then a bit more work.

Btw. I suggest handling wiki engine feature suggestions and bugs using 
the issue tracker in the above Google Code page, possibly in addition to 
discussing them on this or the Pydocweb list. This should make it easier 
for me and possibly other interested parties to follow what is suggested.

Thanks,
Pauli



From d_l_goldsmith at yahoo.com  Wed Jun 10 03:47:37 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 00:47:37 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <889374.78758.qm@web52103.mail.re2.yahoo.com>


--- On Wed, 6/10/09, Pauli Virtanen <pav at iki.fi> wrote:

> Btw. I suggest handling wiki engine feature suggestions and
> bugs using 
> the issue tracker in the above Google Code page, possibly
> in addition to 
> discussing them on this or the Pydocweb list. This should
> make it easier 
> for me and possibly other interested parties to follow what
> is suggested.

Excellent, good to know, I'll use that; can/should I use it for Wiki content/style chores people send me? (That's what I want a ticketing system for.)

DG

> 
> Thanks,
> Pauli
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Wed Jun 10 04:29:42 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 01:29:42 -0700 (PDT)
Subject: [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <915030.79258.qm@web52111.mail.re2.yahoo.com>


--- On Tue, 6/9/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:

> Orange is already being used for "Needs review
> (revised)", and lavender would be maybe be close to the
> blue that means Proofed. I assume the colors where chosen
> together, if you want colors that are better distinguishable
> pick all new ones. See for example here: http://colorschemedesigner.com/
> and compare "complement" to "tetrad".

Sorry, this slipped past me before.  Thanks for the link.  Does anyone have any objections to changing the colors (other than that, what's being used now, is "standard")?

> "Please list yourself if you are willing to proofread
> whatever anyone
> has written, have prepared manuscripts for publication, AND
> consider
> yourself an English grammarian. If you know when to use
> "which" and
> when to use "that" when introducing
> relative clauses, and if "different than"
> stimulates you like nails on a blackboard, sign up
> here!"

:-)

Thanks, Ralf!

DG


      


From jackliddlephysics at googlemail.com  Wed Jun 10 05:18:02 2009
From: jackliddlephysics at googlemail.com (Jack Liddle)
Date: Wed, 10 Jun 2009 11:18:02 +0200
Subject: [SciPy-dev] Requesting edit permissions.
Message-ID: <6ebdbcf10906100218j2bd09f7dy1dccdb3add4a044b@mail.gmail.com>

Hi all

I have registered a username 'jliddle' at docs.scipy.org, and would
like to request edit permissions.  I use NumPy/SciPy daily in my work
and would very much like to contribute to the docs.

I think initially I would be best placed as an editor, at least at the
beginning.  I may not be able to make the Skype teleconference for a
couple of weeks, until my my internet connection is sorted out at home
(recently moved).

Thanks

Jack Liddle


From gael.varoquaux at normalesup.org  Wed Jun 10 05:21:16 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 10 Jun 2009 11:21:16 +0200
Subject: [SciPy-dev] Requesting edit permissions.
In-Reply-To: <6ebdbcf10906100218j2bd09f7dy1dccdb3add4a044b@mail.gmail.com>
References: <6ebdbcf10906100218j2bd09f7dy1dccdb3add4a044b@mail.gmail.com>
Message-ID: <20090610092115.GC10728@phare.normalesup.org>

On Wed, Jun 10, 2009 at 11:18:02AM +0200, Jack Liddle wrote:
> Hi all

> I have registered a username 'jliddle' at docs.scipy.org, and would
> like to request edit permissions.  I use NumPy/SciPy daily in my work
> and would very much like to contribute to the docs.

Excellent. I have added you as an editor. Thanks a lot for your interest.

Ga?l


From mark.marlett at xilinx.com  Wed Jun 10 11:59:10 2009
From: mark.marlett at xilinx.com (Mark Marlett)
Date: Wed, 10 Jun 2009 08:59:10 -0700
Subject: [SciPy-dev] Request to edit scipy documentation
Message-ID: <20090610155912.964C9118805C@mail198-sin.bigfish.com>

Howdy Gael,
I've been a scipy user for 4 years and wish to start contributing by
enhancing the documentation. Please add me as a documentation editor.
 
Best Regards,
Mark Marlett
 


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090610/6b92bf2a/attachment.html>

From gael.varoquaux at normalesup.org  Wed Jun 10 12:18:05 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 10 Jun 2009 18:18:05 +0200
Subject: [SciPy-dev] Request to edit scipy documentation
In-Reply-To: <20090610155912.964C9118805C@mail198-sin.bigfish.com>
References: <20090610155912.964C9118805C@mail198-sin.bigfish.com>
Message-ID: <20090610161805.GA8316@phare.normalesup.org>

Hey Mark,

On Wed, Jun 10, 2009 at 08:59:10AM -0700, Mark Marlett wrote:
>    I've been a scipy user for 4 years and wish to start contributing by
>    enhancing the documentation. Please add me as a documentation editor.

Done, with pleasure! Thanks a lot for your involvement in improving
scipy.

Best,

Ga?l



From d_l_goldsmith at yahoo.com  Wed Jun 10 13:09:53 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 10:09:53 -0700 (PDT)
Subject: [SciPy-dev] Reminder: Doc Marathon Skypecon at 4:30 pm EDT
Message-ID: <186271.29007.qm@web52108.mail.re2.yahoo.com>


Skype d.l.goldsmith at that time to join.  Oh, and it's 1:09 pm EDT now.



      


From dwf at cs.toronto.edu  Wed Jun 10 20:40:49 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Wed, 10 Jun 2009 20:40:49 -0400
Subject: [SciPy-dev] tanh(j*pi/2)
In-Reply-To: <e06186140906092316r6c67929ar8813eafbd43faf29@mail.gmail.com>
References: <658093.91699.qm@web52103.mail.re2.yahoo.com>
	<3d375d730906092249k2b22ee0ai4a56a53ee2f684dc@mail.gmail.com>
	<e06186140906092316r6c67929ar8813eafbd43faf29@mail.gmail.com>
Message-ID: <0A20513C-48CD-46A6-8C2D-3B960A0C82C0@cs.toronto.edu>


On 10-Jun-09, at 2:16 AM, Charles R Harris wrote:

> With examples, too.  And now you have one ;) Examples would help users
> understand the implications of the imprecision.

Perhaps it would be worth including that stats.linregress explanation  
from a day or two ago, too. I'll consolidate answers if people think  
it's a good illustration.

David


From d_l_goldsmith at yahoo.com  Thu Jun 11 01:47:16 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 10 Jun 2009 22:47:16 -0700 (PDT)
Subject: [SciPy-dev] Created Doc Marathon Project at code.google
Message-ID: <308762.87816.qm@web52106.mail.re2.yahoo.com>


Hi, folks.  So, you may recall I expressed want of a "ticketing system," primarily for myself, for NumPy Doc Wiki tasks.  It was suggested I just piggy-back on the pydocweb Project @ code.google, but after a false-start there, I realized, why not just start a new Project expressly for the Marathon?  So I did: http://code.google.com/p/numpydocmarathon09/.  I - d.l.goldsmith at gmail.com - am the owner, and I configured the issues tracker so that only owners and members can submit issues (at least I hope so).  But, I certainly want to make it available as a resource for others to use in the advancement of the Marathon, so if you want to be added as a member, just let me know.  (Pauli or anyone: to be added as a Project member, does one need a gmail, i.e., Google, account?  If yes, does any one find this prohibitively restrictive?)

DG


      


From robert.kern at gmail.com  Thu Jun 11 01:53:40 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 11 Jun 2009 00:53:40 -0500
Subject: [SciPy-dev] Created Doc Marathon Project at code.google
In-Reply-To: <308762.87816.qm@web52106.mail.re2.yahoo.com>
References: <308762.87816.qm@web52106.mail.re2.yahoo.com>
Message-ID: <3d375d730906102253q712ab38o72b2b0d061499155@mail.gmail.com>

On Thu, Jun 11, 2009 at 00:47, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> Hi, folks. ?So, you may recall I expressed want of a "ticketing system," primarily for myself, for NumPy Doc Wiki tasks. ?It was suggested I just piggy-back on the pydocweb Project @ code.google, but after a false-start there, I realized, why not just start a new Project expressly for the Marathon? ?So I did: http://code.google.com/p/numpydocmarathon09/. ?I - d.l.goldsmith at gmail.com - am the owner, and I configured the issues tracker so that only owners and members can submit issues (at least I hope so). ?But, I certainly want to make it available as a resource for others to use in the advancement of the Marathon, so if you want to be added as a member, just let me know. ?(Pauli or anyone: to be added as a Project member, does one need a gmail, i.e., Google, account?

I'm pretty sure of this.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From pav at iki.fi  Thu Jun 11 04:50:49 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 11 Jun 2009 08:50:49 +0000 (UTC)
Subject: [SciPy-dev] Created Doc Marathon Project at code.google
References: <308762.87816.qm@web52106.mail.re2.yahoo.com>
Message-ID: <h0qgh9$uer$1@ger.gmane.org>

Hi David,

Wed, 10 Jun 2009 22:47:16 -0700, David Goldsmith kirjoitti:
> Hi, folks.  So, you may recall I expressed want of a "ticketing system,"
> primarily for myself, for NumPy Doc Wiki tasks.  It was suggested I just
> piggy-back on the pydocweb Project @ code.google, but after a
> false-start there,

Sorry, I'm unfortunately still a bit busy, so given the time difference, 
I didn't manage to reply to your previous post about this in time.

> I realized, why not just start a new Project
> expressly for the Marathon?  So I did:
> http://code.google.com/p/numpydocmarathon09/.  I -
> d.l.goldsmith at gmail.com - am the owner, 

Yeah, this sounds like a better solution than using the Pydocweb tracker, 
as the wiki engine and its Numpy marathon instance are conceptually 
different. But if you have feature requests that have to do with the 
engine rather than content (eg. changing the colours), feel free to 
submit tickets to the Pydocweb tracker.

> and I configured the issues
> tracker so that only owners and members can submit issues (at least I
> hope so).
> But, I certainly want to make it available as a resource for
> others to use in the advancement of the Marathon, so if you want to be
> added as a member, just let me know.

Is this a necessary restriction? The google system seems fairly resilient 
against spam, and it might be easier for people to participate if 
everyone could submit requests and suggestions.

Cheers,
Pauli



From d_l_goldsmith at yahoo.com  Thu Jun 11 10:42:56 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 11 Jun 2009 07:42:56 -0700 (PDT)
Subject: [SciPy-dev] Created Doc Marathon Project at code.google
Message-ID: <63946.45729.qm@web52106.mail.re2.yahoo.com>


--- On Thu, 6/11/09, Pauli Virtanen <pav at iki.fi> wrote:

> Wed, 10 Jun 2009 22:47:16 -0700, David Goldsmith
> kirjoitti:
> > Hi, folks.? So, you may recall I expressed want
> of a "ticketing system,"
> > primarily for myself, for NumPy Doc Wiki tasks.?
> It was suggested I just
> > piggy-back on the pydocweb Project @ code.google, but
> after a
> > false-start there,
> 
> Sorry, I'm unfortunately still a bit busy, so given the
> time difference, 
> I didn't manage to reply to your previous post about this
> in time.

NP

> > and I configured the issues
> > tracker so that only owners and members can submit
> issues (at least I
> > hope so).
> > But, I certainly want to make it available as a
> resource for
> > others to use in the advancement of the Marathon, so
> if you want to be
> > added as a member, just let me know.
> 
> Is this a necessary restriction? The google system seems
> fairly resilient 
> against spam, and it might be easier for people to
> participate if 
> everyone could submit requests and suggestions.

Actually, when I went back to change it, I noted that all I'd apparently done was restrict to the availability of my custom templates (which suggests that non-members still could have submitted issues, just not as "easily"), but I went ahead and eliminated even that restriction - go wild, everyone!

DG


      


From d_l_goldsmith at yahoo.com  Sun Jun 14 15:50:10 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sun, 14 Jun 2009 12:50:10 -0700 (PDT)
Subject: [SciPy-dev] Are the rst's intended to be "definitive"?
Message-ID: <926496.23482.qm@web52105.mail.re2.yahoo.com>


For example, should numpy-docs/reference/arrays.ndarray.rst clearly state, w/ an example, that the ndarray constructor does type-check its input and enforce the data type uniformity?

DG


      


From d_l_goldsmith at yahoo.com  Sun Jun 14 15:54:29 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sun, 14 Jun 2009 12:54:29 -0700 (PDT)
Subject: [SciPy-dev] Sorry,
	disregard "Are the rst's intended to be "definitive"?"
Message-ID: <532001.24749.qm@web52104.mail.re2.yahoo.com>


Sorry, I realized the proper place for this is ndarray's doc string.  Sorry for the noise.

DG

--- On Sun, 6/14/09, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:

> From: David Goldsmith <d_l_goldsmith at yahoo.com>
> Subject: [SciPy-dev] Are the rst's intended to be "definitive"?
> To: scipy-dev at scipy.org
> Date: Sunday, June 14, 2009, 12:50 PM
> 
> For example, should numpy-docs/reference/arrays.ndarray.rst
> clearly state, w/ an example, that the ndarray constructor
> does type-check its input and enforce the data type
> uniformity?
> 
> DG
> 
> 
> ? ? ? 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From fperez.net at gmail.com  Mon Jun 15 03:46:46 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 15 Jun 2009 00:46:46 -0700
Subject: [SciPy-dev] Tutorial topics for SciPy'09 Conference
In-Reply-To: <db6b5ecc0906012220x3bac55d9l95fb7bf97ce2c46c@mail.gmail.com>
References: <db6b5ecc0906012220x3bac55d9l95fb7bf97ce2c46c@mail.gmail.com>
Message-ID: <db6b5ecc0906150046g2936be31ie6f9bb7b9c12fbb1@mail.gmail.com>

Hi all,

In order to proceed with contacting speakers, we'd now like to get
some feedback from you.  This Doodle poll should take no more than a
couple of minutes to fill out (no password or registration required):

http://doodle.com/hb5bea6fivm3b5bk

So please let us know which topics you are most interested in, and
we'll do our best to accommodate everyone.  Keep in mind that speaker
availability and balancing out the topics means that the actual
tutorials offered probably won't be exactly the list of top 8 voted
topics, but the feedback will certainly help us steer the decision
process.

Thanks for your time,

Dave Peterson and Fernando Perez


On Mon, Jun 1, 2009 at 10:20 PM, Fernando Perez<fperez.net at gmail.com> wrote:
> Hi all,
>
> The time for the Scipy'09 conference is rapidly approaching, and we
> would like to both announce the plan for tutorials and solicit
> feedback from everyone on topics of interest.
>
> Broadly speaking, the plan is something along the lines of ?what we
> had last year: one continuous 2-day tutorial ?aimed at introductory
> users, starting from the very basics, and in parallel a set of
> 'advanced' tutorials, consisting of a series of 2-hour sessions on
> specific ?topics.
>
> We will request that the presenters for the advanced tutorials keep
> the 'tutorial' word very much in mind, so that the sessions really
> contain hands-on learning work and not simply a 2-hour long slide
> presentation. ?We will ?thus require that all the tutorials will be
> based on tools that the attendees can install at least 2 weeks in
> advance on all ?platforms (no "I released it last night" software).
>
> With that in mind, we'd like feedback from all of you on possible
> topics for the advanced tutorials. ?We have space for 8 slots total,
> and here are in no particular order some possible topics. ?At this
> point there are no guarantees yet that we can get presentations for
> these, but we'd like to establish a first list of preferred topics to
> try and secure the presentations as soon as possible.
>
> This is simply a list of candiate topics that various people have
> informally suggested so far:
>
> - Mayavi/TVTK
> - Advanced topics in matplotlib
> - Statistics with Scipy
> - The TimeSeries scikit
> - Designing scientific interfaces with Traits
> - Advanced numpy
> - Sparse Linear Algebra with Scipy
> - Structured and record arrays in numpy
> - Cython
> - Sage - general tutorial
> - Sage - specific topics, suggestions welcome
> - Using GPUs with PyCUDA
> - Testing strategies for scientific codes
> - Parallel processing and mpi4py
> - Graph theory with Networkx
> - Design patterns for efficient iterator-based scientific codes.
> - Symbolic computing with sympy
>
> We'd like to hear from any ideas on other possible topics of interest,
> and we'll then run a doodle poll ?to gather quantitative feedback with
> the final list of candidates.


From danielsjensen1 at gmail.com  Mon Jun 15 15:34:38 2009
From: danielsjensen1 at gmail.com (Daniel Jensen)
Date: Mon, 15 Jun 2009 13:34:38 -0600
Subject: [SciPy-dev] Guide to NumPy/SciPy Documentation and Sphinx
Message-ID: <12ac5c250906151234n1199cbdcve9b7cadd7aa618aa@mail.gmail.com>

I've noticed that a lot of code in SciPy is using the following format for
different sections:

:Parameters:

      func : callable func(x,*args)
          The objective function to be minimized.

whereas the Style Guideline page at
http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standardencourages
section titles like the following:

Parameters
    ----------
    x : array-like
        array to fourier transform.

Without some custom sphinx extension to handle the second example, Sphinx
spits out an "Unexpected section title" error message.  Should people
writing scikits or other code that may some day make it into NumPy/SciPy
follow one convention over the other?  If we should follow the first
convention it may be useful to start a wiki page that explains how to get
Sphinx setup correctly to process these docstrings.

-Daniel Jensen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090615/c21437a5/attachment.html>

From d_l_goldsmith at yahoo.com  Mon Jun 15 15:49:58 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 15 Jun 2009 12:49:58 -0700 (PDT)
Subject: [SciPy-dev] Guide to NumPy/SciPy Documentation and Sphinx
Message-ID: <334362.94564.qm@web52104.mail.re2.yahoo.com>


--- On Mon, 6/15/09, Daniel Jensen <danielsjensen1 at gmail.com> wrote:

> I've noticed that a lot of code in
> SciPy is using the following format for different sections:
> 
> :Parameters:
> 
> ????? func : callable func(x,*args)
> ????????? The objective function to be minimized.
>
> whereas the Style Guideline page at http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard
> encourages section titles like the following:
> 
> Parameters
> ??? ----------
> ??? x : array-like
> ??????? array to fourier transform.
> 
> Without some custom sphinx extension to handle the second
> example, Sphinx spits out an "Unexpected section
> title" error message.? Should people writing scikits
> or other code that may some day make it into NumPy/SciPy
> follow one convention over the other?? If we should follow
> the first convention it may be useful to start a wiki page
> that explains how to get Sphinx setup correctly to process
> these docstrings.

First, thanks Daniel, for calling our attention to this.

However, I'm confused - you state: "Without some custom sphinx extension to handle the _second_ example, Sphinx spits out an "Unexpected section title" error message...If we should follow the _first_ convention it may be useful to start a wiki page that explains how to get Sphinx setup correctly to process these docstrings."

Are you saying that presently, Sphinx (or at least the way we have it configured) is not completely compatible with _either_ of these conventions (albeit with the nature of the incompatibility differing between the two)?  Is there not a third option we could adopt which would be Sphinx-compatible "off the shelf"?

Thanks again,

DG
> 
> 
> -Daniel Jensen
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From pav at iki.fi  Mon Jun 15 17:12:53 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 15 Jun 2009 21:12:53 +0000 (UTC)
Subject: [SciPy-dev] Guide to NumPy/SciPy Documentation and Sphinx
References: <12ac5c250906151234n1199cbdcve9b7cadd7aa618aa@mail.gmail.com>
Message-ID: <h16dgl$ost$1@ger.gmane.org>

On 2009-06-15, Daniel Jensen <danielsjensen1 at gmail.com> wrote:
[clip]
> I've noticed that a lot of code in SciPy is using the following format for
> different sections:
>
>:Parameters:
>
>       func : callable func(x,*args)
>           The objective function to be minimized.
>

This is the old doc format which I think was used 
non-systematically, mostly because it worked OK with epydoc. 
Scipy contains still many docstrings written like this, Numpy 
contains essentially none.

> whereas the Style Guideline page at
> http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standardencourages
> section titles like the following:
>
> Parameters
> ----------
> x : array-like
>     array to fourier transform.

This is the new format, which supersedes the old one.

> Without some custom sphinx extension to handle the second example, Sphinx
> spits out an "Unexpected section title" error message.  Should people
> writing scikits or other code that may some day make it into NumPy/SciPy
> follow one convention over the other?

The second one, I believe.

> If we should follow the first convention it may be useful to 
> start a wiki page that explains how to get Sphinx setup 
> correctly to process these docstrings.

Definitely a worthwhile idea. Basically, you need to do:

	easy_install numpydoc

and then add in conf.py

	extensions = ['numpydoc']

-- 
Pauli Virtanen



From pav at iki.fi  Mon Jun 15 17:39:40 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 15 Jun 2009 21:39:40 +0000 (UTC)
Subject: [SciPy-dev] Guide to NumPy/SciPy Documentation and Sphinx
References: <334362.94564.qm@web52104.mail.re2.yahoo.com>
Message-ID: <h16f2s$1k7$1@ger.gmane.org>

On 2009-06-15, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:
[clip]
> Are you saying that presently, Sphinx (or at least the way we 
> have it configured) is not completely compatible with _either_ 
> of these conventions (albeit with the nature of the 
> incompatibility differing between the two)?

Yes, Sphinx off-the-shelf is not compatible with the docstring 
format we use. We have a custom plugin that takes care of this.

The only "problem" is the use of section headers. These are valid 
reStructuredText, but they cannot be used inside Sphinx's 
function:: etc. directives, which causes the problems. So we have 
a custom plugin to Sphinx that reformats them.

> Is there not a third option we could adopt which would be 
> Sphinx-compatible "off the shelf"?

When Numpy documentation guidelines were kickstarted, Sphinx did 
not exist, so Sphinx-compatibility was not on the top of the list 
at that time :) The aims in the format were that it would both be 
easy to read via online help and a valid subset of RST, so that 
it could be easily used in documentation generation tools (and so 
it turned out to be with Sphinx).

Sphinx itself does not enforce *any* formatting rules on the 
docstrings, except that they conform to a subset of valid 
reStructuredText (but one where section headers are not allowed 
in autodoc...). To ensure uniformity and clarity, however, we do 
need more structure than that, especially as the documentation is 
currently written by a large number of people.

I think we're doing currently quite well, and having directly 
Sphinx-compatible docstrings would not be a major benefit at this 
point.

Cheers, 
Pauli



From danielsjensen1 at gmail.com  Mon Jun 15 18:05:28 2009
From: danielsjensen1 at gmail.com (Daniel Jensen)
Date: Mon, 15 Jun 2009 22:05:28 +0000 (UTC)
Subject: [SciPy-dev] Guide to NumPy/SciPy Documentation and Sphinx
References: <12ac5c250906151234n1199cbdcve9b7cadd7aa618aa@mail.gmail.com>
	<h16dgl$ost$1@ger.gmane.org>
Message-ID: <loom.20090615T214418-498@post.gmane.org>

Pauli Virtanen <pav <at> iki.fi> writes:

> 
> On 2009-06-15, Daniel Jensen <danielsjensen1 <at> gmail.com> wrote:
> [clip]
> > I've noticed that a lot of code in SciPy is using the following format for
> > different sections:
> >
> >:Parameters:
> >
> >       func : callable func(x,*args)
> >           The objective function to be minimized.
> >
> 
> This is the old doc format which I think was used 
> non-systematically, mostly because it worked OK with epydoc. 
> Scipy contains still many docstrings written like this, Numpy 
> contains essentially none.
> 
> > whereas the Style Guideline page at
> >
http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standardencourages
> > section titles like the following:
> >
> > Parameters
> > ----------
> > x : array-like
> >     array to fourier transform.
> 
> This is the new format, which supersedes the old one.
> 
> > Without some custom sphinx extension to handle the second example, Sphinx
> > spits out an "Unexpected section title" error message.  Should people
> > writing scikits or other code that may some day make it into NumPy/SciPy
> > follow one convention over the other?
> 
> The second one, I believe.
> 
> > If we should follow the first convention it may be useful to 
> > start a wiki page that explains how to get Sphinx setup 
> > correctly to process these docstrings.
> 
> Definitely a worthwhile idea. Basically, you need to do:
> 
> 	easy_install numpydoc
> 
> and then add in conf.py
> 
> 	extensions = ['numpydoc']
> 


Thanks for the quick responses, that makes a lot of sense now.  Maybe instead of
a wiki page for documentation guidelines we could copy what the Python 2.6
documentation does and just include a "Documenting SciPy - guide for
documentation authors" on the main documentation page (below the tutorial or
somewhere around there) so that everyone is on the same page.  Personally I had
a hard time finding all of the guidelines and people writing new code probably
won't all see the instructions in the documentation editor at
http://docs.scipy.org/numpy/Front%20Page/
It would be really nice to have some instructions there about including plots
and some of the custom Sphinx extensions used in NumPy/SciPy, while referring
people to the main Sphinx documentation for more general instructions.
-Daniel Jensen



From d_l_goldsmith at yahoo.com  Wed Jun 17 02:28:07 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 16 Jun 2009 23:28:07 -0700 (PDT)
Subject: [SciPy-dev] Reminder: weekly NumPy Doc Sum. Mar. Skypecon
Message-ID: <194584.32355.qm@web52111.mail.re2.yahoo.com>


Hi, folks.  Just a reminder that I will be hosting a Skype conference call this Thursday, June 18, at 10:30am EDT to "check-in" re: the NumPy Doc Summer Marathon.  Though I should be able to add people at the last minute, it would help me out if you could let me know your Skype ID in advance, if you anticipate joining in.  (Skype is free and easy to use, but if you don't Skype and don't want to and definitely want to participate, let me know the phone number you'll be calling in from, please.)  Talk to you Thursday!

David Goldsmith
Technical Editor
Olympia, WA


      


From ndbecker2 at gmail.com  Wed Jun 17 08:23:10 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 17 Jun 2009 08:23:10 -0400
Subject: [SciPy-dev] stats confusion
Message-ID: <h1an7e$vc8$1@ger.gmane.org>

I'm still finding stats usage confusing.  The doc 
(http://docs.scipy.org:80/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2)

says:

chi2.cdf(x,df,loc=0,scale=1) :

And even has an example:
prb = chi2.cdf(x,df)

But if df is given as keyword:
 scipy.stats.chi2.cdf(1, df=2)
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (1331, 0))

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/nbecker/globalstar/<ipython console> in <module>()

/usr/lib64/python2.6/site-packages/scipy/stats/distributions.pyc in 
cdf(self, x, *args, **kwds)
    623         if any(cond):  #call only if at least 1 entry
    624             goodargs = argsreduce(cond, *((x,)+args))
--> 625             place(output,cond,self._cdf(*goodargs))
    626         if output.ndim == 0:
    627             return output[()]

TypeError: _cdf() takes exactly 3 arguments (2 given)

What's going on here?  Do stats not accept keyword args as per normal python 
usage?




From josef.pktd at gmail.com  Wed Jun 17 08:59:38 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 08:59:38 -0400
Subject: [SciPy-dev] stats confusion
In-Reply-To: <h1an7e$vc8$1@ger.gmane.org>
References: <h1an7e$vc8$1@ger.gmane.org>
Message-ID: <1cd32cbb0906170559m851a8f8wb9f8a7c8b22de22e@mail.gmail.com>

On Wed, Jun 17, 2009 at 8:23 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
> I'm still finding stats usage confusing. ?The doc
> (http://docs.scipy.org:80/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2)
>
> says:
>
> chi2.cdf(x,df,loc=0,scale=1) :
>
> And even has an example:
> prb = chi2.cdf(x,df)
>
> But if df is given as keyword:
> ?scipy.stats.chi2.cdf(1, df=2)
> ERROR: An unexpected error occurred while tokenizing input
> The following traceback may be corrupted or invalid
> The error message is: ('EOF in multi-line statement', (1331, 0))
>
> ---------------------------------------------------------------------------
> TypeError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call last)
>
> /home/nbecker/globalstar/<ipython console> in <module>()
>
> /usr/lib64/python2.6/site-packages/scipy/stats/distributions.pyc in
> cdf(self, x, *args, **kwds)
> ? ?623 ? ? ? ? if any(cond): ?#call only if at least 1 entry
> ? ?624 ? ? ? ? ? ? goodargs = argsreduce(cond, *((x,)+args))
> --> 625 ? ? ? ? ? ? place(output,cond,self._cdf(*goodargs))
> ? ?626 ? ? ? ? if output.ndim == 0:
> ? ?627 ? ? ? ? ? ? return output[()]
>
> TypeError: _cdf() takes exactly 3 arguments (2 given)
>
> What's going on here? ?Do stats not accept keyword args as per normal python
> usage?
>

As the signature indicates df is a positional argument and not a
keyword argument

>>> scipy.stats.chi2.cdf(1, 2)
0.39346934028736652

Because the generic functions have *args *kwds, df as keyword gets
swallowed (instead of raising a TypeError) and _cdf has one argument
too few.

Josef


From ndbecker2 at gmail.com  Wed Jun 17 09:27:04 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 17 Jun 2009 09:27:04 -0400
Subject: [SciPy-dev] stats confusion
References: <h1an7e$vc8$1@ger.gmane.org>
	<1cd32cbb0906170559m851a8f8wb9f8a7c8b22de22e@mail.gmail.com>
Message-ID: <h1aqv9$dio$1@ger.gmane.org>

josef.pktd at gmail.com wrote:

> On Wed, Jun 17, 2009 at 8:23 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
>> I'm still finding stats usage confusing.  The doc
>> 
(http://docs.scipy.org:80/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2)
>>
>> says:
>>
>> chi2.cdf(x,df,loc=0,scale=1) :
>>
>> And even has an example:
>> prb = chi2.cdf(x,df)
>>
>> But if df is given as keyword:
>> scipy.stats.chi2.cdf(1, df=2)
>> ERROR: An unexpected error occurred while tokenizing input
>> The following traceback may be corrupted or invalid
>> The error message is: ('EOF in multi-line statement', (1331, 0))
>>
>> 
---------------------------------------------------------------------------
>> TypeError                                 Traceback (most recent call
>> last)
>>
>> /home/nbecker/globalstar/<ipython console> in <module>()
>>
>> /usr/lib64/python2.6/site-packages/scipy/stats/distributions.pyc in
>> cdf(self, x, *args, **kwds)
>> 623         if any(cond):  #call only if at least 1 entry
>> 624             goodargs = argsreduce(cond, *((x,)+args))
>> --> 625             place(output,cond,self._cdf(*goodargs))
>> 626         if output.ndim == 0:
>> 627             return output[()]
>>
>> TypeError: _cdf() takes exactly 3 arguments (2 given)
>>
>> What's going on here?  Do stats not accept keyword args as per normal
>> python usage?
>>
> 
> As the signature indicates df is a positional argument and not a
> keyword argument
The doc says:

chi2.cdf(x,df,loc=0,scale=1)

A python user would then expect chi2.cdf (x=0, df=1) to work.  Isn't there a 
problem with that doc?  Is it not feasible to fix this so these functions 
behave as a naive python user would expect?





From josef.pktd at gmail.com  Wed Jun 17 09:37:10 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 09:37:10 -0400
Subject: [SciPy-dev] stats confusion
In-Reply-To: <h1aqv9$dio$1@ger.gmane.org>
References: <h1an7e$vc8$1@ger.gmane.org>
	<1cd32cbb0906170559m851a8f8wb9f8a7c8b22de22e@mail.gmail.com>
	<h1aqv9$dio$1@ger.gmane.org>
Message-ID: <1cd32cbb0906170637l2e6f2435m36200e7418985ee6@mail.gmail.com>

On Wed, Jun 17, 2009 at 9:27 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
> josef.pktd at gmail.com wrote:
>
>> On Wed, Jun 17, 2009 at 8:23 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>> I'm still finding stats usage confusing. ?The doc
>>>
> (http://docs.scipy.org:80/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2)
>>>
>>> says:
>>>
>>> chi2.cdf(x,df,loc=0,scale=1) :
>>>
>>> And even has an example:
>>> prb = chi2.cdf(x,df)
>>>
>>> But if df is given as keyword:
>>> scipy.stats.chi2.cdf(1, df=2)
>>> ERROR: An unexpected error occurred while tokenizing input
>>> The following traceback may be corrupted or invalid
>>> The error message is: ('EOF in multi-line statement', (1331, 0))
>>>
>>>
> ---------------------------------------------------------------------------
>>> TypeError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call
>>> last)
>>>
>>> /home/nbecker/globalstar/<ipython console> in <module>()
>>>
>>> /usr/lib64/python2.6/site-packages/scipy/stats/distributions.pyc in
>>> cdf(self, x, *args, **kwds)
>>> 623 ? ? ? ? if any(cond): ?#call only if at least 1 entry
>>> 624 ? ? ? ? ? ? goodargs = argsreduce(cond, *((x,)+args))
>>> --> 625 ? ? ? ? ? ? place(output,cond,self._cdf(*goodargs))
>>> 626 ? ? ? ? if output.ndim == 0:
>>> 627 ? ? ? ? ? ? return output[()]
>>>
>>> TypeError: _cdf() takes exactly 3 arguments (2 given)
>>>
>>> What's going on here? ?Do stats not accept keyword args as per normal
>>> python usage?
>>>
>>
>> As the signature indicates df is a positional argument and not a
>> keyword argument
> The doc says:
>
> chi2.cdf(x,df,loc=0,scale=1)
>
> A python user would then expect chi2.cdf (x=0, df=1) to work. ?Isn't there a
> problem with that doc? ?Is it not feasible to fix this so these functions
> behave as a naive python user would expect?

Positional arguments cannot be called as keyword arguments, that is
standard python.
(on the other hand keyword arguments can be called also as positional arguments.

the signature and help has standard notation:

eg. signature:  np.maximum(x1, x2[, out])

>>> np.maximum(x1=[5], x2=[6])
Traceback (most recent call last):
TypeError: 'x2' is an invalid keyword to maximum

>>> np.maximum([5],[6])
array([6])


Josef


From pav at iki.fi  Wed Jun 17 09:43:09 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 17 Jun 2009 13:43:09 +0000 (UTC)
Subject: [SciPy-dev] stats confusion
References: <h1an7e$vc8$1@ger.gmane.org>
	<1cd32cbb0906170559m851a8f8wb9f8a7c8b22de22e@mail.gmail.com>
	<h1aqv9$dio$1@ger.gmane.org>
	<1cd32cbb0906170637l2e6f2435m36200e7418985ee6@mail.gmail.com>
Message-ID: <h1artd$gfd$1@ger.gmane.org>

Wed, 17 Jun 2009 09:37:10 -0400, josef.pktd kirjoitti:
[clip]
> Positional arguments cannot be called as keyword arguments, that is
> standard python.
> (on the other hand keyword arguments can be called also as positional
> arguments.

Positional arguments can usually be called as keyword arguments in 
standard Python.

def foo(a):
    print a

foo(a=5)

> the signature and help has standard notation:
> 
> eg. signature:  np.maximum(x1, x2[, out])
> 
>>>> np.maximum(x1=[5], x2=[6])
> Traceback (most recent call last):
> TypeError: 'x2' is an invalid keyword to maximum

The only exception are functions provided by C extension modules, and 
functions that use *args.

-- 
Pauli Virtanen



From josef.pktd at gmail.com  Wed Jun 17 10:20:12 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 10:20:12 -0400
Subject: [SciPy-dev] stats confusion
In-Reply-To: <h1artd$gfd$1@ger.gmane.org>
References: <h1an7e$vc8$1@ger.gmane.org>
	<1cd32cbb0906170559m851a8f8wb9f8a7c8b22de22e@mail.gmail.com>
	<h1aqv9$dio$1@ger.gmane.org>
	<1cd32cbb0906170637l2e6f2435m36200e7418985ee6@mail.gmail.com>
	<h1artd$gfd$1@ger.gmane.org>
Message-ID: <1cd32cbb0906170720u6ab33302jc57a379fe9d29dc1@mail.gmail.com>

On Wed, Jun 17, 2009 at 9:43 AM, Pauli Virtanen<pav at iki.fi> wrote:
> Wed, 17 Jun 2009 09:37:10 -0400, josef.pktd kirjoitti:
> [clip]
>> Positional arguments cannot be called as keyword arguments, that is
>> standard python.
>> (on the other hand keyword arguments can be called also as positional
>> arguments.
>
> Positional arguments can usually be called as keyword arguments in
> standard Python.
>
> def foo(a):
> ? ?print a
>
> foo(a=5)
>
>> the signature and help has standard notation:
>>
>> eg. signature: ?np.maximum(x1, x2[, out])
>>
>>>>> np.maximum(x1=[5], x2=[6])
>> Traceback (most recent call last):
>> TypeError: 'x2' is an invalid keyword to maximum
>
> The only exception are functions provided by C extension modules, and
> functions that use *args.
>

Thanks, I didn't know this is possible.

I found the explanation in the Python Reference Manual. But I don't
thinks I have ever seen it used. And it looks a bit fragile to me if
you want to refactor the argument list later by adding *args), and I
get easily TypeErrors when mixing positional and keyword arguments if
they are in the wrong sequence.
So, I don't see any gain using positional arguments as keywords.

The problem in this example is that the the generic function cdf uses
*args, **kwds, and checks the arguments and does the broadcasting
before dispatching to the private method _cdf.

Calling the private method actually works with keywords
>>> scipy.stats.chi2._cdf(1, df=2)
0.39346934028736652
>>> scipy.stats.chi2._cdf(x=1, df=2)
0.39346934028736652


I forgot to mention earlier: The generated docs are a merge between
generic and distribution specific docstrings. I never checked whether
this merge is completely correct in all cases.

Josef

> --
> Pauli Virtanen


From ndbecker2 at gmail.com  Wed Jun 17 10:45:16 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 17 Jun 2009 10:45:16 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
Message-ID: <h1avhs$tli$1@ger.gmane.org>

As reported earlier, there is a bug in ncx2 that causes a strange 
discontinuity.

Is there a patch available?




From josef.pktd at gmail.com  Wed Jun 17 12:30:18 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 12:30:18 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
In-Reply-To: <h1avhs$tli$1@ger.gmane.org>
References: <h1avhs$tli$1@ger.gmane.org>
Message-ID: <1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>

On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
> As reported earlier, there is a bug in ncx2 that causes a strange
> discontinuity.
>
> Is there a patch available?
>

It's a ticket, but it could take some time until someone finds all the
imprecision for "outlier" cases in scipy.special.

I'm not sure these functions are even designed to have a high
precision, because for distributions such as chisquare or ncx2, that
are primarily used for test statistics, it make only sense to report a
few digits.

I would have recommended ncx2.veccdf for your case, but a quick check
showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
to 1e-8. For ncx2.cdf close to one, there might also be a precision
loss.

What's your use case that you need ncx2 at high precision?

Josef


From ndbecker2 at gmail.com  Wed Jun 17 13:08:19 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 17 Jun 2009 13:08:19 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
Message-ID: <h1b7u3$sa9$1@ger.gmane.org>

josef.pktd at gmail.com wrote:

> On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
>> As reported earlier, there is a bug in ncx2 that causes a strange
>> discontinuity.
>>
>> Is there a patch available?
>>
> 
> It's a ticket, but it could take some time until someone finds all the
> imprecision for "outlier" cases in scipy.special.
> 
> I'm not sure these functions are even designed to have a high
> precision, because for distributions such as chisquare or ncx2, that
> are primarily used for test statistics, it make only sense to report a
> few digits.
> 
> I would have recommended ncx2.veccdf for your case, but a quick check
> showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
> to 1e-8. For ncx2.cdf close to one, there might also be a precision
> loss.
> 
> What's your use case that you need ncx2 at high precision?
> 
> Josef

I'm using this to compute what's often called "Receiver Operating 
Characteristic", which is a signal detection problem.  You may see over some 
range that probability of miss or false detection is quite low.  Probably 
you don't really care about accuracy here, but it's making the plots look 
bad.





From josef.pktd at gmail.com  Wed Jun 17 13:31:37 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 13:31:37 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
In-Reply-To: <h1b7u3$sa9$1@ger.gmane.org>
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
Message-ID: <1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>

On Wed, Jun 17, 2009 at 1:08 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
> josef.pktd at gmail.com wrote:
>
>> On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>> As reported earlier, there is a bug in ncx2 that causes a strange
>>> discontinuity.
>>>
>>> Is there a patch available?
>>>
>>
>> It's a ticket, but it could take some time until someone finds all the
>> imprecision for "outlier" cases in scipy.special.
>>
>> I'm not sure these functions are even designed to have a high
>> precision, because for distributions such as chisquare or ncx2, that
>> are primarily used for test statistics, it make only sense to report a
>> few digits.
>>
>> I would have recommended ncx2.veccdf for your case, but a quick check
>> showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
>> to 1e-8. For ncx2.cdf close to one, there might also be a precision
>> loss.
>>
>> What's your use case that you need ncx2 at high precision?
>>
>> Josef
>
> I'm using this to compute what's often called "Receiver Operating
> Characteristic", which is a signal detection problem. ?You may see over some
> range that probability of miss or false detection is quite low. ?Probably
> you don't really care about accuracy here, but it's making the plots look
> bad.

If speed doesn't matter too much, you can still use veccdf, I don't
think it's more accurate but it is smooth, no discontinuities and it
also goes to 1 in the upper tail.

veccdf is a private method, that avoids the argument check, but as
long as you call it with valid arguments you get good solutions, and
it is vectorized (based on np.vectorize). The generic methods are
pretty heavily tested, so besides slower speed from the numerical
integration, I wouldn't expect any problems.

In contrast to central chisquare, I didn't see any formulas that would
allow a direct calculation of the ncx2.cdf as function of some other
special functions.

Josef


From ndbecker2 at gmail.com  Wed Jun 17 13:53:07 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 17 Jun 2009 13:53:07 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
Message-ID: <h1bai4$66i$1@ger.gmane.org>

josef.pktd at gmail.com wrote:

> On Wed, Jun 17, 2009 at 1:08 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>> josef.pktd at gmail.com wrote:
>>
>>> On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com>
>>> wrote:
>>>> As reported earlier, there is a bug in ncx2 that causes a strange
>>>> discontinuity.
>>>>
>>>> Is there a patch available?
>>>>
>>>
>>> It's a ticket, but it could take some time until someone finds all the
>>> imprecision for "outlier" cases in scipy.special.
>>>
>>> I'm not sure these functions are even designed to have a high
>>> precision, because for distributions such as chisquare or ncx2, that
>>> are primarily used for test statistics, it make only sense to report a
>>> few digits.
>>>
>>> I would have recommended ncx2.veccdf for your case, but a quick check
>>> showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
>>> to 1e-8. For ncx2.cdf close to one, there might also be a precision
>>> loss.
>>>
>>> What's your use case that you need ncx2 at high precision?
>>>
>>> Josef
>>
>> I'm using this to compute what's often called "Receiver Operating
>> Characteristic", which is a signal detection problem.  You may see over
>> some range that probability of miss or false detection is quite low. 
>> Probably you don't really care about accuracy here, but it's making the
>> plots look bad.
> 
> If speed doesn't matter too much, you can still use veccdf, I don't
> think it's more accurate but it is smooth, no discontinuities and it
> also goes to 1 in the upper tail.
> 
> veccdf is a private method, that avoids the argument check, but as
> long as you call it with valid arguments you get good solutions, and
> it is vectorized (based on np.vectorize). The generic methods are
> pretty heavily tested, so besides slower speed from the numerical
> integration, I wouldn't expect any problems.
> 
> In contrast to central chisquare, I didn't see any formulas that would
> allow a direct calculation of the ncx2.cdf as function of some other
> special functions.
> 
> Josef

I'm no expert on this.  I do see 2 refs:

Continuous Univariate Distributions, Vol 2, 2nd edition, Johnson, Kotz,  
Balakrishnan has an entire chapter on the subject.

http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/nc_chi_squared_dist.html

The code says:
 //
            // Computes the complement of the Non-Central Chi-Square
            // Distribution CDF by summing a weighted sum of complements
            // of the central-distributions.  The weighting factor is
            // a Poisson Distribution.
            //
            // This is an application of the technique described in:
            //
            // Computing discrete mixtures of continuous
            // distributions: noncentral chisquare, noncentral t
            // and the distribution of the square of the sample
            // multiple correlation coeficient.
            // D. Benton, K. Krishnamoorthy.
            // Computational Statistics & Data Analysis 43 (2003) 249 - 267


I see that the 1st ref above also talks about the fact that cdf on ncx2 can 
be obtained as weighted sum of central distributions, but it also goes on to 
give other methods of calculation.




From josef.pktd at gmail.com  Wed Jun 17 14:22:54 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 14:22:54 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
In-Reply-To: <h1bai4$66i$1@ger.gmane.org>
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
	<h1bai4$66i$1@ger.gmane.org>
Message-ID: <1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com>

On Wed, Jun 17, 2009 at 1:53 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
> josef.pktd at gmail.com wrote:
>
>> On Wed, Jun 17, 2009 at 1:08 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>> josef.pktd at gmail.com wrote:
>>>
>>>> On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com>
>>>> wrote:
>>>>> As reported earlier, there is a bug in ncx2 that causes a strange
>>>>> discontinuity.
>>>>>
>>>>> Is there a patch available?
>>>>>
>>>>
>>>> It's a ticket, but it could take some time until someone finds all the
>>>> imprecision for "outlier" cases in scipy.special.
>>>>
>>>> I'm not sure these functions are even designed to have a high
>>>> precision, because for distributions such as chisquare or ncx2, that
>>>> are primarily used for test statistics, it make only sense to report a
>>>> few digits.
>>>>
>>>> I would have recommended ncx2.veccdf for your case, but a quick check
>>>> showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
>>>> to 1e-8. For ncx2.cdf close to one, there might also be a precision
>>>> loss.
>>>>
>>>> What's your use case that you need ncx2 at high precision?
>>>>
>>>> Josef
>>>
>>> I'm using this to compute what's often called "Receiver Operating
>>> Characteristic", which is a signal detection problem. ?You may see over
>>> some range that probability of miss or false detection is quite low.
>>> Probably you don't really care about accuracy here, but it's making the
>>> plots look bad.
>>
>> If speed doesn't matter too much, you can still use veccdf, I don't
>> think it's more accurate but it is smooth, no discontinuities and it
>> also goes to 1 in the upper tail.
>>
>> veccdf is a private method, that avoids the argument check, but as
>> long as you call it with valid arguments you get good solutions, and
>> it is vectorized (based on np.vectorize). The generic methods are
>> pretty heavily tested, so besides slower speed from the numerical
>> integration, I wouldn't expect any problems.
>>
>> In contrast to central chisquare, I didn't see any formulas that would
>> allow a direct calculation of the ncx2.cdf as function of some other
>> special functions.
>>
>> Josef
>
> I'm no expert on this. ?I do see 2 refs:
>
> Continuous Univariate Distributions, Vol 2, 2nd edition, Johnson, Kotz,
> Balakrishnan has an entire chapter on the subject.
>
> http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/nc_chi_squared_dist.html
>
> The code says:
> ?//
> ? ? ? ? ? ?// Computes the complement of the Non-Central Chi-Square
> ? ? ? ? ? ?// Distribution CDF by summing a weighted sum of complements
> ? ? ? ? ? ?// of the central-distributions. ?The weighting factor is
> ? ? ? ? ? ?// a Poisson Distribution.
> ? ? ? ? ? ?//
> ? ? ? ? ? ?// This is an application of the technique described in:
> ? ? ? ? ? ?//
> ? ? ? ? ? ?// Computing discrete mixtures of continuous
> ? ? ? ? ? ?// distributions: noncentral chisquare, noncentral t
> ? ? ? ? ? ?// and the distribution of the square of the sample
> ? ? ? ? ? ?// multiple correlation coeficient.
> ? ? ? ? ? ?// D. Benton, K. Krishnamoorthy.
> ? ? ? ? ? ?// Computational Statistics & Data Analysis 43 (2003) 249 - 267
>
>
> I see that the 1st ref above also talks about the fact that cdf on ncx2 can
> be obtained as weighted sum of central distributions, but it also goes on to
> give other methods of calculation.
>

The problem is that the sum has an infinite number of terms. I looked
at JKB vol.2 but they only discuss the central chisquare distribution
extensively, but I didn't see much for non-central chi-square.

Wikipidia as the infinite series expression for the ncx2.cdf
 http://en.wikipedia.org/wiki/Noncentral_chi-square_distribution


But I'm not a numerical precision person, and I usually don't worry
about numerical, floating point precision of convergence of a series
with an infinite number of terms. My preferred bugfix in this would be
special.hyp2f1.  But, I don't have the background and I prefer to
chase the "big bugs", 1e10 and 1e1 instead of 1e-8 and 1e-15.

The infinite mixture might be relatively easy to calculate for
standard cases, but it might be difficult to maintain a high precision
when users start to plug in "funny" parameters and/or expect it to
work for every tail case.

Josef


From ndbecker2 at gmail.com  Wed Jun 17 15:00:43 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 17 Jun 2009 15:00:43 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
	<h1bai4$66i$1@ger.gmane.org>
	<1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com>
Message-ID: <h1begs$jd2$1@ger.gmane.org>

josef.pktd at gmail.com wrote:

> On Wed, Jun 17, 2009 at 1:53 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>> josef.pktd at gmail.com wrote:
>>
>>> On Wed, Jun 17, 2009 at 1:08 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>>> josef.pktd at gmail.com wrote:
>>>>
>>>>> On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com>
>>>>> wrote:
>>>>>> As reported earlier, there is a bug in ncx2 that causes a strange
>>>>>> discontinuity.
>>>>>>
>>>>>> Is there a patch available?
>>>>>>
>>>>>
>>>>> It's a ticket, but it could take some time until someone finds all the
>>>>> imprecision for "outlier" cases in scipy.special.
>>>>>
>>>>> I'm not sure these functions are even designed to have a high
>>>>> precision, because for distributions such as chisquare or ncx2, that
>>>>> are primarily used for test statistics, it make only sense to report a
>>>>> few digits.
>>>>>
>>>>> I would have recommended ncx2.veccdf for your case, but a quick check
>>>>> showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
>>>>> to 1e-8. For ncx2.cdf close to one, there might also be a precision
>>>>> loss.
>>>>>
>>>>> What's your use case that you need ncx2 at high precision?
>>>>>
>>>>> Josef
>>>>
>>>> I'm using this to compute what's often called "Receiver Operating
>>>> Characteristic", which is a signal detection problem.  You may see over
>>>> some range that probability of miss or false detection is quite low.
>>>> Probably you don't really care about accuracy here, but it's making the
>>>> plots look bad.
>>>
>>> If speed doesn't matter too much, you can still use veccdf, I don't
>>> think it's more accurate but it is smooth, no discontinuities and it
>>> also goes to 1 in the upper tail.
>>>
>>> veccdf is a private method, that avoids the argument check, but as
>>> long as you call it with valid arguments you get good solutions, and
>>> it is vectorized (based on np.vectorize). The generic methods are
>>> pretty heavily tested, so besides slower speed from the numerical
>>> integration, I wouldn't expect any problems.
>>>
>>> In contrast to central chisquare, I didn't see any formulas that would
>>> allow a direct calculation of the ncx2.cdf as function of some other
>>> special functions.
>>>
>>> Josef
>>
>> I'm no expert on this.  I do see 2 refs:
>>
>> Continuous Univariate Distributions, Vol 2, 2nd edition, Johnson, Kotz,
>> Balakrishnan has an entire chapter on the subject.
>>
>> 
http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/nc_chi_squared_dist.html
>>
>> The code says:
>> //
>> // Computes the complement of the Non-Central Chi-Square
>> // Distribution CDF by summing a weighted sum of complements
>> // of the central-distributions.  The weighting factor is
>> // a Poisson Distribution.
>> //
>> // This is an application of the technique described in:
>> //
>> // Computing discrete mixtures of continuous
>> // distributions: noncentral chisquare, noncentral t
>> // and the distribution of the square of the sample
>> // multiple correlation coeficient.
>> // D. Benton, K. Krishnamoorthy.
>> // Computational Statistics & Data Analysis 43 (2003) 249 - 267
>>
>>
>> I see that the 1st ref above also talks about the fact that cdf on ncx2
>> can be obtained as weighted sum of central distributions, but it also
>> goes on to give other methods of calculation.
>>
> 
> The problem is that the sum has an infinite number of terms. I looked
> at JKB vol.2 but they only discuss the central chisquare distribution
> extensively, but I didn't see much for non-central chi-square.
> 
> Wikipidia as the infinite series expression for the ncx2.cdf
>  http://en.wikipedia.org/wiki/Noncentral_chi-square_distribution
> 
> 
> But I'm not a numerical precision person, and I usually don't worry
> about numerical, floating point precision of convergence of a series
> with an infinite number of terms. My preferred bugfix in this would be
> special.hyp2f1.  But, I don't have the background and I prefer to
> chase the "big bugs", 1e10 and 1e1 instead of 1e-8 and 1e-15.
> 
> The infinite mixture might be relatively easy to calculate for
> standard cases, but it might be difficult to maintain a high precision
> when users start to plug in "funny" parameters and/or expect it to
> work for every tail case.
> 
> Josef

How about the boost reference?  This is an existence proof of code that is 
supposed to be good quality.  Refer to non_central_chi_squared_cdf in 
boost/math/distributions/non_central_chi_squared.hpp.





From d_l_goldsmith at yahoo.com  Wed Jun 17 17:08:40 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 17 Jun 2009 14:08:40 -0700 (PDT)
Subject: [SciPy-dev] stats confusion
Message-ID: <847312.12794.qm@web52106.mail.re2.yahoo.com>


OK, this is where I chime in: should the doc be clarified, or does this seem like enough of an arcane deviation from "naive" Python practice that we'll actually want to modify the code (and thus postpone modifying the doc 'til that's done)?

DG

--- On Wed, 6/17/09, josef.pktd at gmail.com <josef.pktd at gmail.com> wrote:

> From: josef.pktd at gmail.com <josef.pktd at gmail.com>
> Subject: Re: [SciPy-dev] stats confusion
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Wednesday, June 17, 2009, 7:20 AM
> On Wed, Jun 17, 2009 at 9:43 AM,
> Pauli Virtanen<pav at iki.fi> wrote:
> > Wed, 17 Jun 2009 09:37:10 -0400, josef.pktd
> kirjoitti:
> > [clip]
> >> Positional arguments cannot be called as keyword
> arguments, that is
> >> standard python.
> >> (on the other hand keyword arguments can be called
> also as positional
> >> arguments.
> >
> > Positional arguments can usually be called as keyword
> arguments in
> > standard Python.
> >
> > def foo(a):
> > ? ?print a
> >
> > foo(a=5)
> >
> >> the signature and help has standard notation:
> >>
> >> eg. signature: ?np.maximum(x1, x2[, out])
> >>
> >>>>> np.maximum(x1=[5], x2=[6])
> >> Traceback (most recent call last):
> >> TypeError: 'x2' is an invalid keyword to maximum
> >
> > The only exception are functions provided by C
> extension modules, and
> > functions that use *args.
> >
> 
> Thanks, I didn't know this is possible.
> 
> I found the explanation in the Python Reference Manual. But
> I don't
> thinks I have ever seen it used. And it looks a bit fragile
> to me if
> you want to refactor the argument list later by adding
> *args), and I
> get easily TypeErrors when mixing positional and keyword
> arguments if
> they are in the wrong sequence.
> So, I don't see any gain using positional arguments as
> keywords.
> 
> The problem in this example is that the the generic
> function cdf uses
> *args, **kwds, and checks the arguments and does the
> broadcasting
> before dispatching to the private method _cdf.
> 
> Calling the private method actually works with keywords
> >>> scipy.stats.chi2._cdf(1, df=2)
> 0.39346934028736652
> >>> scipy.stats.chi2._cdf(x=1, df=2)
> 0.39346934028736652
> 
> 
> I forgot to mention earlier: The generated docs are a merge
> between
> generic and distribution specific docstrings. I never
> checked whether
> this merge is completely correct in all cases.
> 
> Josef
> 
> > --
> > Pauli Virtanen
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From robert.kern at gmail.com  Wed Jun 17 17:12:41 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 17 Jun 2009 16:12:41 -0500
Subject: [SciPy-dev] fix for ncx2 bug?
In-Reply-To: <h1begs$jd2$1@ger.gmane.org>
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com> 
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com> 
	<h1bai4$66i$1@ger.gmane.org>
	<1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com> 
	<h1begs$jd2$1@ger.gmane.org>
Message-ID: <3d375d730906171412q352fc5afncea1732265dab725@mail.gmail.com>

On Wed, Jun 17, 2009 at 14:00, Neal Becker<ndbecker2 at gmail.com> wrote:
> josef.pktd at gmail.com wrote:
>
>> On Wed, Jun 17, 2009 at 1:53 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>> josef.pktd at gmail.com wrote:
>>>
>>>> On Wed, Jun 17, 2009 at 1:08 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>>>> josef.pktd at gmail.com wrote:
>>>>>
>>>>>> On Wed, Jun 17, 2009 at 10:45 AM, Neal Becker<ndbecker2 at gmail.com>
>>>>>> wrote:
>>>>>>> As reported earlier, there is a bug in ncx2 that causes a strange
>>>>>>> discontinuity.
>>>>>>>
>>>>>>> Is there a patch available?
>>>>>>>
>>>>>>
>>>>>> It's a ticket, but it could take some time until someone finds all the
>>>>>> imprecision for "outlier" cases in scipy.special.
>>>>>>
>>>>>> I'm not sure these functions are even designed to have a high
>>>>>> precision, because for distributions such as chisquare or ncx2, that
>>>>>> are primarily used for test statistics, it make only sense to report a
>>>>>> few digits.
>>>>>>
>>>>>> I would have recommended ncx2.veccdf for your case, but a quick check
>>>>>> showed that over a large range ncx2.veccdf and ncx2.cdf only agree up
>>>>>> to 1e-8. For ncx2.cdf close to one, there might also be a precision
>>>>>> loss.
>>>>>>
>>>>>> What's your use case that you need ncx2 at high precision?
>>>>>>
>>>>>> Josef
>>>>>
>>>>> I'm using this to compute what's often called "Receiver Operating
>>>>> Characteristic", which is a signal detection problem. ?You may see over
>>>>> some range that probability of miss or false detection is quite low.
>>>>> Probably you don't really care about accuracy here, but it's making the
>>>>> plots look bad.
>>>>
>>>> If speed doesn't matter too much, you can still use veccdf, I don't
>>>> think it's more accurate but it is smooth, no discontinuities and it
>>>> also goes to 1 in the upper tail.
>>>>
>>>> veccdf is a private method, that avoids the argument check, but as
>>>> long as you call it with valid arguments you get good solutions, and
>>>> it is vectorized (based on np.vectorize). The generic methods are
>>>> pretty heavily tested, so besides slower speed from the numerical
>>>> integration, I wouldn't expect any problems.
>>>>
>>>> In contrast to central chisquare, I didn't see any formulas that would
>>>> allow a direct calculation of the ncx2.cdf as function of some other
>>>> special functions.
>>>>
>>>> Josef
>>>
>>> I'm no expert on this. ?I do see 2 refs:
>>>
>>> Continuous Univariate Distributions, Vol 2, 2nd edition, Johnson, Kotz,
>>> Balakrishnan has an entire chapter on the subject.
>>>
>>>
> http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/nc_chi_squared_dist.html
>>>
>>> The code says:
>>> //
>>> // Computes the complement of the Non-Central Chi-Square
>>> // Distribution CDF by summing a weighted sum of complements
>>> // of the central-distributions. ?The weighting factor is
>>> // a Poisson Distribution.
>>> //
>>> // This is an application of the technique described in:
>>> //
>>> // Computing discrete mixtures of continuous
>>> // distributions: noncentral chisquare, noncentral t
>>> // and the distribution of the square of the sample
>>> // multiple correlation coeficient.
>>> // D. Benton, K. Krishnamoorthy.
>>> // Computational Statistics & Data Analysis 43 (2003) 249 - 267
>>>
>>>
>>> I see that the 1st ref above also talks about the fact that cdf on ncx2
>>> can be obtained as weighted sum of central distributions, but it also
>>> goes on to give other methods of calculation.
>>>
>>
>> The problem is that the sum has an infinite number of terms. I looked
>> at JKB vol.2 but they only discuss the central chisquare distribution
>> extensively, but I didn't see much for non-central chi-square.
>>
>> Wikipidia as the infinite series expression for the ncx2.cdf
>> ?http://en.wikipedia.org/wiki/Noncentral_chi-square_distribution
>>
>>
>> But I'm not a numerical precision person, and I usually don't worry
>> about numerical, floating point precision of convergence of a series
>> with an infinite number of terms. My preferred bugfix in this would be
>> special.hyp2f1. ?But, I don't have the background and I prefer to
>> chase the "big bugs", 1e10 and 1e1 instead of 1e-8 and 1e-15.
>>
>> The infinite mixture might be relatively easy to calculate for
>> standard cases, but it might be difficult to maintain a high precision
>> when users start to plug in "funny" parameters and/or expect it to
>> work for every tail case.
>>
>> Josef
>
> How about the boost reference? ?This is an existence proof of code that is
> supposed to be good quality. ?Refer to non_central_chi_squared_cdf in
> boost/math/distributions/non_central_chi_squared.hpp.

The code we have is also supposed to be good quality. Does the boost
code claim that it will be good in the particular domain of your
interest? Even good quality numerical software sometimes have gaps,
particularly way out in the tails of CDFs.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From robert.kern at gmail.com  Wed Jun 17 17:13:05 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 17 Jun 2009 16:13:05 -0500
Subject: [SciPy-dev] stats confusion
In-Reply-To: <847312.12794.qm@web52106.mail.re2.yahoo.com>
References: <847312.12794.qm@web52106.mail.re2.yahoo.com>
Message-ID: <3d375d730906171413g554ec476wcb33a69a9baa6b96@mail.gmail.com>

On Wed, Jun 17, 2009 at 16:08, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> OK, this is where I chime in: should the doc be clarified, or does this seem like enough of an arcane deviation from "naive" Python practice that we'll actually want to modify the code (and thus postpone modifying the doc 'til that's done)?

Clarify the documentation.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Wed Jun 17 17:23:43 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 17 Jun 2009 14:23:43 -0700 (PDT)
Subject: [SciPy-dev] stats confusion
Message-ID: <598819.23181.qm@web52106.mail.re2.yahoo.com>


Roger.

DG

--- On Wed, 6/17/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] stats confusion
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Wednesday, June 17, 2009, 2:13 PM
> On Wed, Jun 17, 2009 at 16:08, David
> Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > OK, this is where I chime in: should the doc be
> clarified, or does this seem like enough of an arcane
> deviation from "naive" Python practice that we'll actually
> want to modify the code (and thus postpone modifying the doc
> 'til that's done)?
> 
> Clarify the documentation.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Wed Jun 17 17:28:56 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 17 Jun 2009 14:28:56 -0700 (PDT)
Subject: [SciPy-dev] stats confusion
Message-ID: <471487.25864.qm@web52108.mail.re2.yahoo.com>


Oooops, just dawned on me: this is in SciPy, not NumPy - we don't have a Wiki-style editing interface set up for SciPy yet, do we?

DG
--- On Wed, 6/17/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] stats confusion
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Wednesday, June 17, 2009, 2:13 PM
> On Wed, Jun 17, 2009 at 16:08, David
> Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > OK, this is where I chime in: should the doc be
> clarified, or does this seem like enough of an arcane
> deviation from "naive" Python practice that we'll actually
> want to modify the code (and thus postpone modifying the doc
> 'til that's done)?
> 
> Clarify the documentation.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From robert.kern at gmail.com  Wed Jun 17 17:35:18 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 17 Jun 2009 16:35:18 -0500
Subject: [SciPy-dev] stats confusion
In-Reply-To: <471487.25864.qm@web52108.mail.re2.yahoo.com>
References: <471487.25864.qm@web52108.mail.re2.yahoo.com>
Message-ID: <3d375d730906171435r4f9fbcfeuc487375907fa82ea@mail.gmail.com>

On Wed, Jun 17, 2009 at 16:28, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> Oooops, just dawned on me: this is in SciPy, not NumPy - we don't have a Wiki-style editing interface set up for SciPy yet, do we?

http://docs.scipy.org/scipy/Front%20Page/

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From josef.pktd at gmail.com  Wed Jun 17 17:45:45 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 17:45:45 -0400
Subject: [SciPy-dev] stats confusion
In-Reply-To: <3d375d730906171413g554ec476wcb33a69a9baa6b96@mail.gmail.com>
References: <847312.12794.qm@web52106.mail.re2.yahoo.com>
	<3d375d730906171413g554ec476wcb33a69a9baa6b96@mail.gmail.com>
Message-ID: <1cd32cbb0906171445s5c791dc8yf2e2e854b6a5f72e@mail.gmail.com>

On Wed, Jun 17, 2009 at 5:13 PM, Robert Kern<robert.kern at gmail.com> wrote:
> On Wed, Jun 17, 2009 at 16:08, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>>
>> OK, this is where I chime in: should the doc be clarified, or does this seem like enough of an arcane deviation from "naive" Python practice that we'll actually want to modify the code (and thus postpone modifying the doc 'til that's done)?
>
> Clarify the documentation.
>

I don't see why we should need to document the usage of positional keywords.

The generated docstrings for the distribution in
http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2

is pretty dense, and we don't need to load it up with a description
how to use function arguments.

Josef


From robert.kern at gmail.com  Wed Jun 17 18:07:16 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 17 Jun 2009 17:07:16 -0500
Subject: [SciPy-dev] stats confusion
In-Reply-To: <1cd32cbb0906171445s5c791dc8yf2e2e854b6a5f72e@mail.gmail.com>
References: <847312.12794.qm@web52106.mail.re2.yahoo.com>
	<3d375d730906171413g554ec476wcb33a69a9baa6b96@mail.gmail.com> 
	<1cd32cbb0906171445s5c791dc8yf2e2e854b6a5f72e@mail.gmail.com>
Message-ID: <3d375d730906171507n1ecaeb17x9674e79b29563576@mail.gmail.com>

On Wed, Jun 17, 2009 at 16:45, <josef.pktd at gmail.com> wrote:
> On Wed, Jun 17, 2009 at 5:13 PM, Robert Kern<robert.kern at gmail.com> wrote:
>> On Wed, Jun 17, 2009 at 16:08, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>>>
>>> OK, this is where I chime in: should the doc be clarified, or does this seem like enough of an arcane deviation from "naive" Python practice that we'll actually want to modify the code (and thus postpone modifying the doc 'til that's done)?
>>
>> Clarify the documentation.
>
> I don't see why we should need to document the usage of positional keywords.
>
> The generated docstrings for the distribution in
> http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2
>
> is pretty dense, and we don't need to load it up with a description
> how to use function arguments.

The docstring for the scipy.stats.distributions module could use a
warning. The distributions are complicated and important enough that
they deserve some tutorial-style documentation, which would be the
ideal place for this information.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Wed Jun 17 20:08:10 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 17 Jun 2009 17:08:10 -0700 (PDT)
Subject: [SciPy-dev] stats confusion
Message-ID: <92723.30637.qm@web52108.mail.re2.yahoo.com>


Good "steerage," Robert, thanks!

DG

--- On Wed, 6/17/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] stats confusion
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Wednesday, June 17, 2009, 3:07 PM
> On Wed, Jun 17, 2009 at 16:45, <josef.pktd at gmail.com>
> wrote:
> > On Wed, Jun 17, 2009 at 5:13 PM, Robert Kern<robert.kern at gmail.com>
> wrote:
> >> On Wed, Jun 17, 2009 at 16:08, David
> Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >>>
> >>> OK, this is where I chime in: should the doc
> be clarified, or does this seem like enough of an arcane
> deviation from "naive" Python practice that we'll actually
> want to modify the code (and thus postpone modifying the doc
> 'til that's done)?
> >>
> >> Clarify the documentation.
> >
> > I don't see why we should need to document the usage
> of positional keywords.
> >
> > The generated docstrings for the distribution in
> > http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2
> >
> > is pretty dense, and we don't need to load it up with
> a description
> > how to use function arguments.
> 
> The docstring for the scipy.stats.distributions module
> could use a
> warning. The distributions are complicated and important
> enough that
> they deserve some tutorial-style documentation, which would
> be the
> ideal place for this information.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From njs at pobox.com  Wed Jun 17 19:59:00 2009
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 17 Jun 2009 16:59:00 -0700
Subject: [SciPy-dev] fix for ncx2 bug?
In-Reply-To: <h1begs$jd2$1@ger.gmane.org>
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
	<h1bai4$66i$1@ger.gmane.org>
	<1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com>
	<h1begs$jd2$1@ger.gmane.org>
Message-ID: <961fa2b40906171659t1d38faf5q42c000f0ca3d87ca@mail.gmail.com>

On Wed, Jun 17, 2009 at 12:00 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
> How about the boost reference? ?This is an existence proof of code that is
> supposed to be good quality. ?Refer to non_central_chi_squared_cdf in
> boost/math/distributions/non_central_chi_squared.hpp.

R's implementations of statistical functions may also a good
reference; certainly they've been pounded on by more real
statisticians than anything in scipy or boost. Also nice is that they
always include citations in their help files -- just type
help("pchisq") in R.

-- Nathaniel


From josef.pktd at gmail.com  Wed Jun 17 20:35:00 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 17 Jun 2009 20:35:00 -0400
Subject: [SciPy-dev] stats confusion
In-Reply-To: <92723.30637.qm@web52108.mail.re2.yahoo.com>
References: <92723.30637.qm@web52108.mail.re2.yahoo.com>
Message-ID: <1cd32cbb0906171735j61e51663pe1558d5ad09832b2@mail.gmail.com>

On Wed, Jun 17, 2009 at 8:08 PM, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> --- On Wed, 6/17/09, Robert Kern <robert.kern at gmail.com> wrote:
>
>> From: Robert Kern <robert.kern at gmail.com>
>> Subject: Re: [SciPy-dev] stats confusion
>> To: "SciPy Developers List" <scipy-dev at scipy.org>
>> Date: Wednesday, June 17, 2009, 3:07 PM
>> On Wed, Jun 17, 2009 at 16:45, <josef.pktd at gmail.com>
>> wrote:
>> > On Wed, Jun 17, 2009 at 5:13 PM, Robert Kern<robert.kern at gmail.com>
>> wrote:
>> >> On Wed, Jun 17, 2009 at 16:08, David
>> Goldsmith<d_l_goldsmith at yahoo.com>
>> wrote:
>> >>>
>> >>> OK, this is where I chime in: should the doc
>> be clarified, or does this seem like enough of an arcane
>> deviation from "naive" Python practice that we'll actually
>> want to modify the code (and thus postpone modifying the doc
>> 'til that's done)?
>> >>
>> >> Clarify the documentation.
>> >
>> > I don't see why we should need to document the usage
>> of positional keywords.
>> >
>> > The generated docstrings for the distribution in
>> > http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2
>> >
>> > is pretty dense, and we don't need to load it up with
>> a description
>> > how to use function arguments.
>>

>> The docstring for the scipy.stats.distributions module
>> could use a
>> warning. The distributions are complicated and important
>> enough that
>> they deserve some tutorial-style documentation, which would
>> be the
>> ideal place for this information.
>>
>
> Good "steerage," Robert, thanks!
>
> DG

Everybody is welcome to clean up my draft for a stats tutorial or
rewrite it to make it nicer
http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/stats.rst/

so that it can actually be included in the published docs.

Josef


From d_l_goldsmith at yahoo.com  Wed Jun 17 23:17:00 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Wed, 17 Jun 2009 20:17:00 -0700 (PDT)
Subject: [SciPy-dev] stats confusion
Message-ID: <935934.36841.qm@web52104.mail.re2.yahoo.com>


Thanks, Josef.

DG

--- On Wed, 6/17/09, josef.pktd at gmail.com <josef.pktd at gmail.com> wrote:

> From: josef.pktd at gmail.com <josef.pktd at gmail.com>
> Subject: Re: [SciPy-dev] stats confusion
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Wednesday, June 17, 2009, 5:35 PM
> On Wed, Jun 17, 2009 at 8:08 PM,
> David Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > --- On Wed, 6/17/09, Robert Kern <robert.kern at gmail.com>
> wrote:
> >
> >> From: Robert Kern <robert.kern at gmail.com>
> >> Subject: Re: [SciPy-dev] stats confusion
> >> To: "SciPy Developers List" <scipy-dev at scipy.org>
> >> Date: Wednesday, June 17, 2009, 3:07 PM
> >> On Wed, Jun 17, 2009 at 16:45, <josef.pktd at gmail.com>
> >> wrote:
> >> > On Wed, Jun 17, 2009 at 5:13 PM, Robert
> Kern<robert.kern at gmail.com>
> >> wrote:
> >> >> On Wed, Jun 17, 2009 at 16:08, David
> >> Goldsmith<d_l_goldsmith at yahoo.com>
> >> wrote:
> >> >>>
> >> >>> OK, this is where I chime in: should
> the doc
> >> be clarified, or does this seem like enough of an
> arcane
> >> deviation from "naive" Python practice that we'll
> actually
> >> want to modify the code (and thus postpone
> modifying the doc
> >> 'til that's done)?
> >> >>
> >> >> Clarify the documentation.
> >> >
> >> > I don't see why we should need to document
> the usage
> >> of positional keywords.
> >> >
> >> > The generated docstrings for the distribution
> in
> >> > http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chi2.html?highlight=chi2#scipy.stats.chi2
> >> >
> >> > is pretty dense, and we don't need to load it
> up with
> >> a description
> >> > how to use function arguments.
> >>
> 
> >> The docstring for the scipy.stats.distributions
> module
> >> could use a
> >> warning. The distributions are complicated and
> important
> >> enough that
> >> they deserve some tutorial-style documentation,
> which would
> >> be the
> >> ideal place for this information.
> >>
> >
> > Good "steerage," Robert, thanks!
> >
> > DG
> 
> Everybody is welcome to clean up my draft for a stats
> tutorial or
> rewrite it to make it nicer
> http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/stats.rst/
> 
> so that it can actually be included in the published docs.
> 
> Josef
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From ndbecker2 at gmail.com  Thu Jun 18 07:16:28 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 18 Jun 2009 07:16:28 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
	<h1bai4$66i$1@ger.gmane.org>
	<1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com>
	<h1begs$jd2$1@ger.gmane.org>
	<961fa2b40906171659t1d38faf5q42c000f0ca3d87ca@mail.gmail.com>
Message-ID: <h1d7mc$igu$1@ger.gmane.org>

Nathaniel Smith wrote:

> On Wed, Jun 17, 2009 at 12:00 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>> How about the boost reference?  This is an existence proof of code that
>> is supposed to be good quality.  Refer to non_central_chi_squared_cdf in
>> boost/math/distributions/non_central_chi_squared.hpp.
> 
> R's implementations of statistical functions may also a good
> reference; certainly they've been pounded on by more real
> statisticians than anything in scipy or boost. Also nice is that they
> always include citations in their help files -- just type
> help("pchisq") in R.
> 

R may be good too - I'm not familiar with it.

The boost ref has extensive test results including comparison against R.




From ndbecker2 at gmail.com  Thu Jun 18 07:18:28 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 18 Jun 2009 07:18:28 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
	<h1bai4$66i$1@ger.gmane.org>
	<1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com>
	<h1begs$jd2$1@ger.gmane.org>
	<961fa2b40906171659t1d38faf5q42c000f0ca3d87ca@mail.gmail.com>
Message-ID: <h1d7q4$igu$2@ger.gmane.org>

Nathaniel Smith wrote:

> On Wed, Jun 17, 2009 at 12:00 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>> How about the boost reference?  This is an existence proof of code that
>> is supposed to be good quality.  Refer to non_central_chi_squared_cdf in
>> boost/math/distributions/non_central_chi_squared.hpp.
> 
> R's implementations of statistical functions may also a good
> reference; certainly they've been pounded on by more real
> statisticians than anything in scipy or boost. Also nice is that they
> always include citations in their help files -- just type
> help("pchisq") in R.
> 

The boost ref has really excellent documentation.  Very impressive work, 
IMO.




From d_l_goldsmith at yahoo.com  Thu Jun 18 10:01:20 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 18 Jun 2009 07:01:20 -0700 (PDT)
Subject: [SciPy-dev] Last-minute reminder
Message-ID: <320362.83114.qm@web52101.mail.re2.yahoo.com>


Skypecon for Numpy doc summer marathon in 30 min.  Skype d.l.goldsmith to join in.

dg


      


From erik.tollerud at gmail.com  Thu Jun 18 17:43:29 2009
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Thu, 18 Jun 2009 16:43:29 -0500
Subject: [SciPy-dev] Requesting edit permissions
Message-ID: <fbab3e0d0906181443pcfa6710j7eb1beb6de0c04ed@mail.gmail.com>

I've registered the username 'eteq' on the docs page and am requesting
edit permissions.  I use numpy/scipy for nearly all of my research,
and would like to make change to docs as I encounter something that I
have to go figure out...


From gael.varoquaux at normalesup.org  Thu Jun 18 17:47:50 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 18 Jun 2009 23:47:50 +0200
Subject: [SciPy-dev] Requesting edit permissions
In-Reply-To: <fbab3e0d0906181443pcfa6710j7eb1beb6de0c04ed@mail.gmail.com>
References: <fbab3e0d0906181443pcfa6710j7eb1beb6de0c04ed@mail.gmail.com>
Message-ID: <20090618214750.GA3607@phare.normalesup.org>

On Thu, Jun 18, 2009 at 04:43:29PM -0500, Erik Tollerud wrote:
> I've registered the username 'eteq' on the docs page and am requesting
> edit permissions.  I use numpy/scipy for nearly all of my research,
> and would like to make change to docs as I encounter something that I
> have to go figure out...

Done. Thanks for your involvement.

Ga?l


From dwf at cs.toronto.edu  Thu Jun 18 19:45:31 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Thu, 18 Jun 2009 19:45:31 -0400
Subject: [SciPy-dev] fix for ncx2 bug?
In-Reply-To: <961fa2b40906171659t1d38faf5q42c000f0ca3d87ca@mail.gmail.com>
References: <h1avhs$tli$1@ger.gmane.org>
	<1cd32cbb0906170930k2144a1f4g9552d6e8fec52ac@mail.gmail.com>
	<h1b7u3$sa9$1@ger.gmane.org>
	<1cd32cbb0906171031h534ff655g9d3394b33c2aed08@mail.gmail.com>
	<h1bai4$66i$1@ger.gmane.org>
	<1cd32cbb0906171122ke9563a0ra9fb332afb402da9@mail.gmail.com>
	<h1begs$jd2$1@ger.gmane.org>
	<961fa2b40906171659t1d38faf5q42c000f0ca3d87ca@mail.gmail.com>
Message-ID: <7FB87407-5FC2-45FD-B15E-78AC9618019B@cs.toronto.edu>

On 17-Jun-09, at 7:59 PM, Nathaniel Smith wrote:

> R's implementations of statistical functions may also a good
> reference; certainly they've been pounded on by more real
> statisticians than anything in scipy or boost. Also nice is that they
> always include citations in their help files -- just type
> help("pchisq") in R.

Careful, though! R (the core package anyway) is GPL.

David


From gael.varoquaux at normalesup.org  Fri Jun 19 10:01:58 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 19 Jun 2009 16:01:58 +0200
Subject: [SciPy-dev] [ANN] SciPy 2009 conference opened up for registration
Message-ID: <20090619140158.GA12012@phare.normalesup.org>

We are finally opening the registration for the SciPy 2009 conference. It
took us time, but the reason is that we made careful budget estimations
to bring the registration cost down.

We are very happy to announce that this year registration to the
conference will be only $150, sprints $100, and students get half price!
We made this effort because we hope it will open up the conference to
more people, especially students that often have to finance this trip
with little budget. As a consequence, however, catering at noon is not
included.

This does not mean that we are getting a reduced conference. Quite on the
contrary, this year we have two keynote speakers. And what speakers:
Peter Norvig and Jon Guyer! Peter Norvig is the director of research at
Google and Jon Guyer is a research scientist at NIST, in the
Thermodynamics and Kinetics Group, where he leads a fiPy, a finite
element project in Python.

The SciPy 2009 Conference
==========================

SciPy 2009, the 8th Python in Science conference
(http://conference.scipy.org), will be held from
August 18-23, 2009 at Caltech in Pasadena, CA, USA.

Each year SciPy attracts leading figures in research and scientific
software development with Python from a wide range of scientific and
engineering disciplines. The focus of the conference is both on
scientific libraries and tools developed with Python and on scientific or
engineering achievements using Python.

Call for Papers
================

We welcome contributions from the industry as well as the academic world.
Indeed, industrial research and development as well academic research
face the challenge of mastering IT tools for exploration, modeling and
analysis.

We look forward to hearing your recent breakthroughs using Python! Please
read the full call for papers
(http://conference.scipy.org/call_for_papers).

Important Dates
================

    * Friday, June 26: Abstracts Due
    * Saturday, July 4: Announce accepted talks, post schedule
    * Friday, July 10: Early Registration ends
    * Tuesday-Wednesday, August 18-19: Tutorials
    * Thursday-Friday, August 20-21: Conference
    * Saturday-Sunday, August 22-23: Sprints
    * Friday, September 4: Papers for proceedings due


The SciPy 2009 executive committee
-----------------------------------

 * Jarrod Millman, UC Berkeley, USA (Conference Chair)
 * Ga?l Varoquaux, INRIA Saclay, France (Program Co-Chair)
 * St?fan van der Walt, University of Stellenbosch, South Africa
 * (Program Co-Chair)
 * Fernando P?rez, UC Berkeley, USA (Tutorial Chair)





From gael.varoquaux at normalesup.org  Fri Jun 19 12:15:16 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 19 Jun 2009 18:15:16 +0200
Subject: [SciPy-dev] [Correction] Re: [ANN] SciPy 2009 conference opened up
	for	registration
In-Reply-To: <20090619140158.GA12012@phare.normalesup.org>
References: <20090619140158.GA12012@phare.normalesup.org>
Message-ID: <20090619161516.GB16549@phare.normalesup.org>

Please excuse me for incorrect information in my announcement:

On Fri, Jun 19, 2009 at 04:01:58PM +0200, Gael Varoquaux wrote:
> We are very happy to announce that this year registration to the
> conference will be only $150, sprints $100, and students get half price!

This should read that the tutorials are $100, not the sprints. The
sprints are actually free, off course. We will be very please to see as
many people as possible willing to participate at the sprint in making
the SciPy ecosystem thrive.

Thanks to Travis Oliphant for pointing out the typo.

Ga?l Varoquaux


From d_l_goldsmith at yahoo.com  Fri Jun 19 23:40:20 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Fri, 19 Jun 2009 20:40:20 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <441749.90804.qm@web52102.mail.re2.yahoo.com>


Hi!  The template http://projects.scipy.org/numpy/browser/trunk/doc/example.py#L37 for documenting things doesn't seem like a very good template for documenting objects, e.g., ufunc, and data (as opposed to method) attributes of objects, e.g., ndarray.dtype.  Are there other templates for these elsewhere?  Thanks!

DG


      


From stefan at sun.ac.za  Sat Jun 20 02:19:44 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 20 Jun 2009 08:19:44 +0200
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <441749.90804.qm@web52102.mail.re2.yahoo.com>
References: <441749.90804.qm@web52102.mail.re2.yahoo.com>
Message-ID: <9457e7c80906192319t16a4a5d0s4b58b40cdfb320da@mail.gmail.com>

Hi David

2009/6/20 David Goldsmith <d_l_goldsmith at yahoo.com>:
> Hi! ?The template http://projects.scipy.org/numpy/browser/trunk/doc/example.py#L37 for documenting things doesn't seem like a very good template for documenting objects, e.g., ufunc, and data (as opposed to method) attributes of objects, e.g., ndarray.dtype. ?Are there other templates for these elsewhere? ?Thanks!

Have a look at

http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard

under the section "Documenting Classes".  Is that what you're looking for?

Regards
St?fan


From d_l_goldsmith at yahoo.com  Sat Jun 20 12:49:52 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sat, 20 Jun 2009 09:49:52 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <479453.42620.qm@web52101.mail.re2.yahoo.com>


Yup, thanks!

DG

--- On Fri, 6/19/09, St?fan van der Walt <stefan at sun.ac.za> wrote:

> From: St?fan van der Walt <stefan at sun.ac.za>
> Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Friday, June 19, 2009, 11:19 PM
> Hi David
> 
> 2009/6/20 David Goldsmith <d_l_goldsmith at yahoo.com>:
> > Hi! ?The template http://projects.scipy.org/numpy/browser/trunk/doc/example.py#L37
> for documenting things doesn't seem like a very good
> template for documenting objects, e.g., ufunc, and data (as
> opposed to method) attributes of objects, e.g.,
> ndarray.dtype. ?Are there other templates for these
> elsewhere? ?Thanks!
> 
> Have a look at
> 
> http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard
> 
> under the section "Documenting Classes".? Is that what
> you're looking for?
> 
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Sat Jun 20 19:23:39 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sat, 20 Jun 2009 16:23:39 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <202041.51408.qm@web52111.mail.re2.yahoo.com>


Ok, a couple follow-up questions: where precisely should documentation of __init__, and the Attributes and Methods sections (when needed) go?  In other words, docstringstandard says, "Use the same sections as outlined [for Functions]," but as Functions don't have __init__, Attributes, or Methods, it is unclear where in the "above" template these new items should go.  

Also, since __init__ is a method, I assume it should itself be documented like any other method, i.e., w/ a definition, one line desc., multi-line desc., parameters section, etc.  To my mind, to avoid clutter and excessively long docstrings, it seems like it should be documented separately; but then perhaps what is meant is that documenting the class is really documenting its __init__?

Thanks,

DG

--- On Fri, 6/19/09, St?fan van der Walt <stefan at sun.ac.za> wrote:

> From: St?fan van der Walt <stefan at sun.ac.za>
> Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Friday, June 19, 2009, 11:19 PM
> Hi David
> 
> 2009/6/20 David Goldsmith <d_l_goldsmith at yahoo.com>:
> > Hi! ?The template http://projects.scipy.org/numpy/browser/trunk/doc/example.py#L37
> for documenting things doesn't seem like a very good
> template for documenting objects, e.g., ufunc, and data (as
> opposed to method) attributes of objects, e.g.,
> ndarray.dtype. ?Are there other templates for these
> elsewhere? ?Thanks!
> 
> Have a look at
> 
> http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard
> 
> under the section "Documenting Classes".? Is that what
> you're looking for?
> 
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From jsseabold at gmail.com  Sat Jun 20 19:31:33 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Sat, 20 Jun 2009 19:31:33 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <202041.51408.qm@web52111.mail.re2.yahoo.com>
References: <202041.51408.qm@web52111.mail.re2.yahoo.com>
Message-ID: <c048da1c0906201631s70b2cc04ve0089b1611a2affe@mail.gmail.com>

On Sat, Jun 20, 2009 at 7:23 PM, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> Ok, a couple follow-up questions: where precisely should documentation of __init__, and the Attributes and Methods sections (when needed) go? ?In other words, docstringstandard says, "Use the same sections as outlined [for Functions]," but as Functions don't have __init__, Attributes, or Methods, it is unclear where in the "above" template these new items should go.
>
> Also, since __init__ is a method, I assume it should itself be documented like any other method, i.e., w/ a definition, one line desc., multi-line desc., parameters section, etc. ?To my mind, to avoid clutter and excessively long docstrings, it seems like it should be documented separately; but then perhaps what is meant is that documenting the class is really documenting its __init__?
>
> Thanks,
>
> DG
>

I've been having similar questions myself is there a good example in
the code of a class that is documented correctly or at least a best
practice way?  I've kind of been going off ODR and distributions in
stats as needed.

Skipper


From pgmdevlist at gmail.com  Sat Jun 20 20:06:48 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Sat, 20 Jun 2009 20:06:48 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <202041.51408.qm@web52111.mail.re2.yahoo.com>
References: <202041.51408.qm@web52111.mail.re2.yahoo.com>
Message-ID: <1A309088-B8EE-4FA9-B6F7-05D8EEC146A3@gmail.com>


On Jun 20, 2009, at 7:23 PM, David Goldsmith wrote:

>
> Ok, a couple follow-up questions: where precisely should  
> documentation of __init__, and the Attributes and Methods sections  
> (when needed) go?  In other words, docstringstandard says, "Use the  
> same sections as outlined [for Functions]," but as Functions don't  
> have __init__, Attributes, or Methods, it is unclear where in the  
> "above" template these new items should go.

My 2c:

* I don't document __init__, but I put a 'Parameters' section in the  
docstring of the class that describes all the input parameters of  
__init__
* Methods could be described in the docstring of the class, under a  
'Methods' entry, but it might be more appropriate to document them  
outside the class.
* Same thing for Attributes: you could have a small list in the  
docstring, but as soon as you start documenting an attribute in  
detail, you'd better have a separate section.

Check http://pytseries.sourceforge.net/core.timeseries.html for an  
example of application.




From d_l_goldsmith at yahoo.com  Sat Jun 20 20:41:43 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sat, 20 Jun 2009 17:41:43 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <620971.18765.qm@web52110.mail.re2.yahoo.com>


Thanks, Pierre, this is helpful, but the given example doesn't have any of the _other_ sections Functions have, though the docstring standard says "all but Returns are relevant," so I'm left wondering where to insert the "new" sections relative to the "old."  (I know that not _all_ Function sections will always be relevant for _all_ classes, but I assume at least some of them will be relevant for some classes, but your example doesn't clarify where to put them.)  But, FWIW, thanks.

DG

--- On Sat, 6/20/09, Pierre GM <pgmdevlist at gmail.com> wrote:

> From: Pierre GM <pgmdevlist at gmail.com>
> Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Saturday, June 20, 2009, 5:06 PM
> 
> On Jun 20, 2009, at 7:23 PM, David Goldsmith wrote:
> 
> >
> > Ok, a couple follow-up questions: where precisely
> should? 
> > documentation of __init__, and the Attributes and
> Methods sections? 
> > (when needed) go?? In other words,
> docstringstandard says, "Use the? 
> > same sections as outlined [for Functions]," but as
> Functions don't? 
> > have __init__, Attributes, or Methods, it is unclear
> where in the? 
> > "above" template these new items should go.
> 
> My 2c:
> 
> * I don't document __init__, but I put a 'Parameters'
> section in the? 
> docstring of the class that describes all the input
> parameters of? 
> __init__
> * Methods could be described in the docstring of the class,
> under a? 
> 'Methods' entry, but it might be more appropriate to
> document them? 
> outside the class.
> * Same thing for Attributes: you could have a small list in
> the? 
> docstring, but as soon as you start documenting an
> attribute in? 
> detail, you'd better have a separate section.
> 
> Check http://pytseries.sourceforge.net/core.timeseries.html
> for an? 
> example of application.
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From ralf.gommers at googlemail.com  Sat Jun 20 20:46:44 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 20 Jun 2009 20:46:44 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <620971.18765.qm@web52110.mail.re2.yahoo.com>
References: <620971.18765.qm@web52110.mail.re2.yahoo.com>
Message-ID: <dde7764a0906201746t6c85c723g823a60ac77eec6c5@mail.gmail.com>

On Sat, Jun 20, 2009 at 8:41 PM, David Goldsmith <d_l_goldsmith at yahoo.com>wrote:

>
> Thanks, Pierre, this is helpful, but the given example doesn't have any of
> the _other_ sections Functions have, though the docstring standard says "all
> but Returns are relevant," so I'm left wondering where to insert the "new"
> sections relative to the "old."  (I know that not _all_ Function sections
> will always be relevant for _all_ classes, but I assume at least some of
> them will be relevant for some classes, but your example doesn't clarify
> where to put them.)  But, FWIW, thanks.
>


Look at ndarray for an example:
http://docs.scipy.org/numpy/docs/numpy.ndarray/#numpy-ndarray
Documenting the class indeed means its __init__ function as far as
Parameters, See Also, Examples, etc. This is what has been done so far for
all classes I've looked at.

The Methods and Attributes sections show up automatically, and contain all
public methods/attributes, so don't worry about putting a list of those in.
Those methods/attributes do have their own docstrings.

Cheers,
Ralf



>
> DG
>
> --- On Sat, 6/20/09, Pierre GM <pgmdevlist at gmail.com> wrote:
>
> > From: Pierre GM <pgmdevlist at gmail.com>
> > Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> > To: "SciPy Developers List" <scipy-dev at scipy.org>
> > Date: Saturday, June 20, 2009, 5:06 PM
> >
> > On Jun 20, 2009, at 7:23 PM, David Goldsmith wrote:
> >
> > >
> > > Ok, a couple follow-up questions: where precisely
> > should
> > > documentation of __init__, and the Attributes and
> > Methods sections
> > > (when needed) go?  In other words,
> > docstringstandard says, "Use the
> > > same sections as outlined [for Functions]," but as
> > Functions don't
> > > have __init__, Attributes, or Methods, it is unclear
> > where in the
> > > "above" template these new items should go.
> >
> > My 2c:
> >
> > * I don't document __init__, but I put a 'Parameters'
> > section in the
> > docstring of the class that describes all the input
> > parameters of
> > __init__
> > * Methods could be described in the docstring of the class,
> > under a
> > 'Methods' entry, but it might be more appropriate to
> > document them
> > outside the class.
> > * Same thing for Attributes: you could have a small list in
> > the
> > docstring, but as soon as you start documenting an
> > attribute in
> > detail, you'd better have a separate section.
> >
> > Check http://pytseries.sourceforge.net/core.timeseries.html
> > for an
> > example of application.
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090620/8a878b65/attachment.html>

From d_l_goldsmith at yahoo.com  Sat Jun 20 23:08:57 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sat, 20 Jun 2009 20:08:57 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <576838.11758.qm@web52112.mail.re2.yahoo.com>


Excellent, Ralf, thanks!

DG

--- On Sat, 6/20/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:

> From: Ralf Gommers <ralf.gommers at googlemail.com>
> Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Saturday, June 20, 2009, 5:46 PM
> 
> 
> On Sat, Jun 20, 2009 at 8:41 PM,
> David Goldsmith <d_l_goldsmith at yahoo.com>
> wrote:
> 
> 
> 
> Thanks, Pierre, this is helpful, but the given example
> doesn't have any of the _other_ sections Functions have,
> though the docstring standard says "all but Returns are
> relevant," so I'm left wondering where to insert
> the "new" sections relative to the
> "old." ?(I know that not _all_ Function sections
> will always be relevant for _all_ classes, but I assume at
> least some of them will be relevant for some classes, but
> your example doesn't clarify where to put them.) ?But,
> FWIW, thanks.
> 
> 
> 
> 
> Look at ndarray for an example: http://docs.scipy.org/numpy/docs/numpy.ndarray/#numpy-ndarray
> 
> Documenting the class indeed means its __init__
> function as far as Parameters, See Also, Examples, etc. This
> is what has been done so far for all classes I've looked
> at. 
> 
> 
> 
> The Methods and Attributes sections show up automatically,
> and contain all public methods/attributes, so don't
> worry about putting a list of those in. Those
> methods/attributes do have their own docstrings.
> 
> Cheers,
> 
> Ralf
> 
> 
> ?
> 
> DG
> 
> 
> 
> --- On Sat, 6/20/09, Pierre GM <pgmdevlist at gmail.com>
> wrote:
> 
> 
> 
> > From: Pierre GM <pgmdevlist at gmail.com>
> 
> > Subject: Re: [SciPy-dev] Doc-ing
> classes and data attributes
> 
> > To: "SciPy Developers List" <scipy-dev at scipy.org>
> 
> > Date: Saturday, June 20, 2009, 5:06 PM
> 
> >
> 
> > On Jun 20, 2009, at 7:23 PM, David Goldsmith wrote:
> 
> >
> 
> > >
> 
> > > Ok, a couple follow-up questions: where
> precisely
> 
> > should?
> 
> > > documentation of __init__, and the Attributes
> and
> 
> > Methods sections?
> 
> > > (when needed) go?? In other words,
> 
> > docstringstandard says, "Use the?
> 
> > > same sections as outlined [for Functions],"
> but as
> 
> > Functions don't?
> 
> > > have __init__, Attributes, or Methods, it is
> unclear
> 
> > where in the?
> 
> > > "above" template these new items should
> go.
> 
> >
> 
> > My 2c:
> 
> >
> 
> > * I don't document __init__, but I put a
> 'Parameters'
> 
> > section in the?
> 
> > docstring of the class that describes all the input
> 
> > parameters of?
> 
> > __init__
> 
> > * Methods could be described in the docstring of the
> class,
> 
> > under a?
> 
> > 'Methods' entry, but it might be more
> appropriate to
> 
> > document them?
> 
> > outside the class.
> 
> > * Same thing for Attributes: you could have a small
> list in
> 
> > the?
> 
> > docstring, but as soon as you start documenting an
> 
> > attribute in?
> 
> > detail, you'd better have a separate section.
> 
> >
> 
> > Check http://pytseries.sourceforge.net/core.timeseries.html
> 
> > for an?
> 
> > example of application.
> 
> >
> 
> >
> 
> > _______________________________________________
> 
> > 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
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Sat Jun 20 23:12:52 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sat, 20 Jun 2009 20:12:52 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <76601.5227.qm@web52105.mail.re2.yahoo.com>


--- On Sat, 6/20/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:

> On Sat, Jun 20, 2009 at 8:41 PM,
> David Goldsmith <d_l_goldsmith at yahoo.com>
> wrote:
> 
> Thanks, Pierre, this is helpful, but the given example
> doesn't have any of the _other_ sections Functions have,
> though the docstring standard says "all but Returns are
> relevant," so I'm left wondering where to insert
> the "new" sections relative to the
> "old." ?(I know that not _all_ Function sections
> will always be relevant for _all_ classes, but I assume at
> least some of them will be relevant for some classes, but
> your example doesn't clarify where to put them.) ?But,
> FWIW, thanks.
> 
> Look at ndarray for an example: http://docs.scipy.org/numpy/docs/numpy.ndarray/#numpy-ndarray
> 
> Documenting the class indeed means its __init__
> function as far as Parameters, See Also, Examples, etc. This
> is what has been done so far for all classes I've looked
> at. 
> 
> The Methods and Attributes sections show up automatically,
> and contain all public methods/attributes, so don't
> worry about putting a list of those in. Those
> methods/attributes do have their own docstrings.

If I may have edit privileges at http://projects.scipy.org/numpy/wiki/ I can add these clarifications there myself; otherwise, I'll file a ticket at pydocweb.

DG

> Cheers,
> 
> Ralf
> 
> 
> ?
> 
> DG
> 
> 
> 
> --- On Sat, 6/20/09, Pierre GM <pgmdevlist at gmail.com>
> wrote:
> 
> 
> 
> > From: Pierre GM <pgmdevlist at gmail.com>
> 
> > Subject: Re: [SciPy-dev] Doc-ing
> classes and data attributes
> 
> > To: "SciPy Developers List" <scipy-dev at scipy.org>
> 
> > Date: Saturday, June 20, 2009, 5:06 PM
> 
> >
> 
> > On Jun 20, 2009, at 7:23 PM, David Goldsmith wrote:
> 
> >
> 
> > >
> 
> > > Ok, a couple follow-up questions: where
> precisely
> 
> > should?
> 
> > > documentation of __init__, and the Attributes
> and
> 
> > Methods sections?
> 
> > > (when needed) go?? In other words,
> 
> > docstringstandard says, "Use the?
> 
> > > same sections as outlined [for Functions],"
> but as
> 
> > Functions don't?
> 
> > > have __init__, Attributes, or Methods, it is
> unclear
> 
> > where in the?
> 
> > > "above" template these new items should
> go.
> 
> >
> 
> > My 2c:
> 
> >
> 
> > * I don't document __init__, but I put a
> 'Parameters'
> 
> > section in the?
> 
> > docstring of the class that describes all the input
> 
> > parameters of?
> 
> > __init__
> 
> > * Methods could be described in the docstring of the
> class,
> 
> > under a?
> 
> > 'Methods' entry, but it might be more
> appropriate to
> 
> > document them?
> 
> > outside the class.
> 
> > * Same thing for Attributes: you could have a small
> list in
> 
> > the?
> 
> > docstring, but as soon as you start documenting an
> 
> > attribute in?
> 
> > detail, you'd better have a separate section.
> 
> >
> 
> > Check http://pytseries.sourceforge.net/core.timeseries.html
> 
> > for an?
> 
> > example of application.
> 
> >
> 
> >
> 
> > _______________________________________________
> 
> > 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
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From ralf.gommers at googlemail.com  Sun Jun 21 00:47:04 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 21 Jun 2009 00:47:04 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <76601.5227.qm@web52105.mail.re2.yahoo.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
Message-ID: <dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>

On Sat, Jun 20, 2009 at 11:12 PM, David Goldsmith
<d_l_goldsmith at yahoo.com>wrote:

>
> --- On Sat, 6/20/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
>
> > On Sat, Jun 20, 2009 at 8:41 PM,
> > David Goldsmith <d_l_goldsmith at yahoo.com>
> > wrote:
> >
> > Thanks, Pierre, this is helpful, but the given example
> > doesn't have any of the _other_ sections Functions have,
> > though the docstring standard says "all but Returns are
> > relevant," so I'm left wondering where to insert
> > the "new" sections relative to the
> > "old."  (I know that not _all_ Function sections
> > will always be relevant for _all_ classes, but I assume at
> > least some of them will be relevant for some classes, but
> > your example doesn't clarify where to put them.)  But,
> > FWIW, thanks.
> >
> > Look at ndarray for an example:
> http://docs.scipy.org/numpy/docs/numpy.ndarray/#numpy-ndarray
> >
> > Documenting the class indeed means its __init__
> > function as far as Parameters, See Also, Examples, etc. This
> > is what has been done so far for all classes I've looked
> > at.
> >
> > The Methods and Attributes sections show up automatically,
> > and contain all public methods/attributes, so don't
> > worry about putting a list of those in. Those
> > methods/attributes do have their own docstrings.
>
> If I may have edit privileges at http://projects.scipy.org/numpy/wiki/ I
> can add these clarifications there myself; otherwise, I'll file a ticket at
> pydocweb.
>

The CodingStyleGuidelines page is generated from
/trunk/doc/HOWTO_DOCUMENT.txt so editing on Trac is not what you want. The
page is already in reST format, so can we add it to the doc editor and edit
it there?

I'd like to be able to make changes to it as well, a few I can think of
right away are
- documenting class instances
- documenting constants
- the [out] parameter

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090621/1731209b/attachment.html>

From d_l_goldsmith at yahoo.com  Sun Jun 21 02:05:57 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Sat, 20 Jun 2009 23:05:57 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <34972.99747.qm@web52105.mail.re2.yahoo.com>


--- On Sat, 6/20/09, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
<big snip>
> > Look at ndarray for an example: http://docs.scipy.org/numpy/docs/numpy.ndarray/#numpy-ndarray
> 
> > Documenting the class indeed means its __init__
> 
> > function as far as Parameters, See Also, Examples,
> etc. This
> 
> > is what has been done so far for all classes I've
> looked
> 
> > at.
> 
> > The Methods and Attributes sections show up
> automatically,
> 
> > and contain all public methods/attributes, so
> don't
> 
> > worry about putting a list of those in. Those
> 
> > methods/attributes do have their own docstrings.
> 
> If I may have edit privileges at http://projects.scipy.org/numpy/wiki/
> I can add these clarifications there myself; otherwise,
> I'll file a ticket at pydocweb.
> 
> The CodingStyleGuidelines page is generated from
> /trunk/doc/HOWTO_DOCUMENT.txt so editing on Trac is not what
> you want. The page is already in reST format, so can we add
> it to the doc editor and edit it there?? 
> 
> I'd like to be able to make changes to it as well, a

Glad to see I'm not the only one. ;-)

> few I can think of right away are 
> - documenting class instances
> - documenting constants
> - the [out] parameter

Regarding this last, as per a suggestion from Pauli in the Discussion following ndarray.rst, I just now finished adding a "See also, numpy.doc.ufuncs, 'Output arguments' section" to the ndarray methods possessing the [out] parameter (actually, I added it to the docstrings of their equivalent functions outside of the ndarray namespace), so keep this in mind when contemplating what to add in the HOWTO_DOCUMENT.txt. :-)

DG

> Ralf
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From stefan at sun.ac.za  Sun Jun 21 10:32:12 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 21 Jun 2009 16:32:12 +0200
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
Message-ID: <9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>

2009/6/21 Ralf Gommers <ralf.gommers at googlemail.com>:
> The CodingStyleGuidelines page is generated from
> /trunk/doc/HOWTO_DOCUMENT.txt so editing on Trac is not what you want. The
> page is already in reST format, so can we add it to the doc editor and edit
> it there?

The documentation standard should not be open to editing.  You are, of
course, welcome to provide patches that we can apply after discussion,
but this document cannot be in a state of flux.

Regards
St?fan


From d_l_goldsmith at yahoo.com  Sun Jun 21 11:43:14 2009
From: d_l_goldsmith at yahoo.com (d_l_goldsmith at yahoo.com)
Date: Sun, 21 Jun 2009 08:43:14 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <52796.74152.qm@web52107.mail.re2.yahoo.com>


OK, ticket (#1146) filed.

DG

--- On Sun, 6/21/09, St?fan van der Walt <stefan at sun.ac.za> wrote:

> From: St?fan van der Walt <stefan at sun.ac.za>
> Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Sunday, June 21, 2009, 7:32 AM
> 2009/6/21 Ralf Gommers <ralf.gommers at googlemail.com>:
> > The CodingStyleGuidelines page is generated from
> > /trunk/doc/HOWTO_DOCUMENT.txt so editing on Trac is
> not what you want. The
> > page is already in reST format, so can we add it to
> the doc editor and edit
> > it there?
> 
> The documentation standard should not be open to
> editing.? You are, of
> course, welcome to provide patches that we can apply after
> discussion,
> but this document cannot be in a state of flux.
> 
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



      


From stefan at sun.ac.za  Sun Jun 21 12:26:05 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 21 Jun 2009 18:26:05 +0200
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <52796.74152.qm@web52107.mail.re2.yahoo.com>
References: <52796.74152.qm@web52107.mail.re2.yahoo.com>
Message-ID: <9457e7c80906210926p25898a6dh45c0c885756af629@mail.gmail.com>

2009/6/21  <d_l_goldsmith at yahoo.com>:
>
> OK, ticket (#1146) filed.

David, I'm not sure what you want me to do with that ticket?  There
are no patches or concrete suggestions attached.

St?fan


From ondrej at certik.cz  Sun Jun 21 19:10:17 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Sun, 21 Jun 2009 17:10:17 -0600
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened up
	for registration
In-Reply-To: <20090619140158.GA12012@phare.normalesup.org>
References: <20090619140158.GA12012@phare.normalesup.org>
Message-ID: <85b5c3130906211610t28a31462o6513c43f217ac66e@mail.gmail.com>

On Fri, Jun 19, 2009 at 8:01 AM, Gael
Varoquaux<gael.varoquaux at normalesup.org> wrote:
> We are finally opening the registration for the SciPy 2009 conference. It
> took us time, but the reason is that we made careful budget estimations
> to bring the registration cost down.
>
> We are very happy to announce that this year registration to the
> conference will be only $150, sprints $100, and students get half price!
> We made this effort because we hope it will open up the conference to
> more people, especially students that often have to finance this trip
> with little budget. As a consequence, however, catering at noon is not
> included.
>
> This does not mean that we are getting a reduced conference. Quite on the
> contrary, this year we have two keynote speakers. And what speakers:
> Peter Norvig and Jon Guyer! Peter Norvig is the director of research at
> Google and Jon Guyer is a research scientist at NIST, in the
> Thermodynamics and Kinetics Group, where he leads a fiPy, a finite
> element project in Python.

As far as I know, it's actually a finite *volume* solver.

Ondrej


From ondrej at certik.cz  Sun Jun 21 19:20:08 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Sun, 21 Jun 2009 17:20:08 -0600
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened up
	for registration
In-Reply-To: <20090619140158.GA12012@phare.normalesup.org>
References: <20090619140158.GA12012@phare.normalesup.org>
Message-ID: <85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>

On Fri, Jun 19, 2009 at 8:01 AM, Gael
Varoquaux<gael.varoquaux at normalesup.org> wrote:
> We are finally opening the registration for the SciPy 2009 conference. It
> took us time, but the reason is that we made careful budget estimations
> to bring the registration cost down.
>
> We are very happy to announce that this year registration to the
> conference will be only $150, sprints $100, and students get half price!
> We made this effort because we hope it will open up the conference to
> more people, especially students that often have to finance this trip
> with little budget. As a consequence, however, catering at noon is not
> included.

One more question -- how can I actually register for the conference? I went to:

http://conference.scipy.org/

registered and sent the abstract (some time ago already). So today I
logged in and clicked "registration":

http://conference.scipy.org/to_register

which says "To register to the conference, create an account on this
site and log in. Go to your profile page, you can submit an abstract
or register to the conference.", so I clicked on my profile page:

http://conference.scipy.org/profile

which shows my abstract, but it says "The conference is not yet open
for registration.". So how can I pay the conference fees and register?

Thanks,
Ondrej


From gael.varoquaux at normalesup.org  Sun Jun 21 19:50:28 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 22 Jun 2009 01:50:28 +0200
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened	up
	for registration
In-Reply-To: <85b5c3130906211610t28a31462o6513c43f217ac66e@mail.gmail.com>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211610t28a31462o6513c43f217ac66e@mail.gmail.com>
Message-ID: <20090621235028.GA14395@phare.normalesup.org>

On Sun, Jun 21, 2009 at 05:10:17PM -0600, Ondrej Certik wrote:
> On Fri, Jun 19, 2009 at 8:01 AM, Gael
> Varoquaux<gael.varoquaux at normalesup.org> wrote:
> > We are finally opening the registration for the SciPy 2009 conference. It
> > took us time, but the reason is that we made careful budget estimations
> > to bring the registration cost down.

> > We are very happy to announce that this year registration to the
> > conference will be only $150, sprints $100, and students get half price!
> > We made this effort because we hope it will open up the conference to
> > more people, especially students that often have to finance this trip
> > with little budget. As a consequence, however, catering at noon is not
> > included.

> > This does not mean that we are getting a reduced conference. Quite on the
> > contrary, this year we have two keynote speakers. And what speakers:
> > Peter Norvig and Jon Guyer! Peter Norvig is the director of research at
> > Google and Jon Guyer is a research scientist at NIST, in the
> > Thermodynamics and Kinetics Group, where he leads a fiPy, a finite
> > element project in Python.

> As far as I know, it's actually a finite *volume* solver.

Darn, I did it again. Although I know the difference[*], I keep mixing up
the words. Thanks for correcting (and making me look ridiculous), Ondrej.

Ga?l

[*] Thanks to my girlfriend ;)


From gael.varoquaux at normalesup.org  Sun Jun 21 19:55:40 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 22 Jun 2009 01:55:40 +0200
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened	up
	for registration
In-Reply-To: <85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
Message-ID: <20090621235540.GB14395@phare.normalesup.org>

On Sun, Jun 21, 2009 at 05:20:08PM -0600, Ondrej Certik wrote:
> On Fri, Jun 19, 2009 at 8:01 AM, Gael
> Varoquaux<gael.varoquaux at normalesup.org> wrote:
> > We are finally opening the registration for the SciPy 2009 conference. It
> > took us time, but the reason is that we made careful budget estimations
> > to bring the registration cost down.

> > We are very happy to announce that this year registration to the
> > conference will be only $150, sprints $100, and students get half price!
> > We made this effort because we hope it will open up the conference to
> > more people, especially students that often have to finance this trip
> > with little budget. As a consequence, however, catering at noon is not
> > included.

> One more question -- how can I actually register for the conference? I went to:

> http://conference.scipy.org/

> registered and sent the abstract (some time ago already). So today I
> logged in and clicked "registration":

> http://conference.scipy.org/to_register

> which says "To register to the conference, create an account on this
> site and log in. Go to your profile page, you can submit an abstract
> or register to the conference.", so I clicked on my profile page:

> http://conference.scipy.org/profile

> which shows my abstract, but it says "The conference is not yet open
> for registration.". So how can I pay the conference fees and register?

Well, well. Looks like I did things too quickly, or too jet-lagged. I
had forgotten to pull the setting on the server. That's why we where not
observing any registration. Thank you for signaling it, I wonder how many
people had tried and failed.

Ga?l


From ralf.gommers at googlemail.com  Sun Jun 21 20:59:39 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 21 Jun 2009 20:59:39 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
Message-ID: <dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>

2009/6/21 St?fan van der Walt <stefan at sun.ac.za>

> 2009/6/21 Ralf Gommers <ralf.gommers at googlemail.com>:
> > The CodingStyleGuidelines page is generated from
> > /trunk/doc/HOWTO_DOCUMENT.txt so editing on Trac is not what you want.
> The
> > page is already in reST format, so can we add it to the doc editor and
> edit
> > it there?
>
> The documentation standard should not be open to editing.  You are, of
> course, welcome to provide patches that we can apply after discussion,
> but this document cannot be in a state of flux.


You're right that it should not be in a state of flux. I attached a patch to
#1146 for review.

I suggested the wiki because there needs to be a place where design
decisions that are taken on mailing list or in doc editor comments can be
collected and reviewed. Maybe we can have such a page on the wiki, and then
after some collaborative editing and everyone agreeing, coming up with a
patch for /trunk/doc/HOWTO_DOCUMENT.txt (which should be the gold standard).

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090621/523eacae/attachment.html>

From stefan at sun.ac.za  Mon Jun 22 03:42:21 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 22 Jun 2009 09:42:21 +0200
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com> 
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com> 
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
Message-ID: <9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>

Hi Ralf

Thanks for the patch!  I committed your fixes up to the point where
you start discussing class documentation.

We have to decide: is it OK to document the class constructor in
__init__?  We used to put this in the class docstring itself so that
"help" and IPython's "?" would find it, but I don't think this is
longer necessary.  On the other hand, it makes sense: you call "x =
MyClass()" to construct, not "x = MyClass.__init__()".  Comments
welcome.

A couple of questions and comments about the patch:

 	326	   Not all examples will run though, due to them including blank lines
 	327	   in the output. Do not put in doctest-specific markup like
 	328	   ``<BLANKLINE>`` or ``#doctest: +SKIP``, readability is more important
 	329	   here than being able to execute the doctests in a testing framework.

What is the plan here?  We must be able to execute the doctests in some way.

 	409	Class instances normally take the docstring of the class. In the Numpy
 	410	namespace some class instances are made available to expose certain
 	411	functionality.

I know what you mean by the above, but I think these sentences are a
bit confusing.

 	419	Documenting constants

To which constants are you referring?  Give an example to clarify.

 	436	* [,out] : All ufuncs accept an optional `out` argument. This is
 	437	  documented in the **Output arguments** section of `doc.ufuncs`. In the
 	438	  docstring this argument should be documented like this::
 	439	
 	440	    out : ndarray, optional
 	441	        Array into which the output is placed. Its type is preserved and
 	442	        it must be of the right shape to hold the output. See
`doc.ufuncs`.

I think we can leave this out of the standard, since it pertains to a
very specific part of numpy.

Regards
St?fan

2009/6/22 Ralf Gommers <ralf.gommers at googlemail.com>:
>
>
> 2009/6/21 St?fan van der Walt <stefan at sun.ac.za>
>>
>> 2009/6/21 Ralf Gommers <ralf.gommers at googlemail.com>:
>> > The CodingStyleGuidelines page is generated from
>> > /trunk/doc/HOWTO_DOCUMENT.txt so editing on Trac is not what you want.
>> > The
>> > page is already in reST format, so can we add it to the doc editor and
>> > edit
>> > it there?
>>
>> The documentation standard should not be open to editing. ?You are, of
>> course, welcome to provide patches that we can apply after discussion,
>> but this document cannot be in a state of flux.
>
> You're right that it should not be in a state of flux. I attached a patch to
> #1146 for review.


From pav at iki.fi  Mon Jun 22 05:15:20 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 22 Jun 2009 09:15:20 +0000 (UTC)
Subject: [SciPy-dev] Doc-ing classes and data attributes
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
Message-ID: <h1ni38$bqi$1@ger.gmane.org>

Mon, 22 Jun 2009 09:42:21 +0200, St?fan van der Walt kirjoitti:
>
> Thanks for the patch!  I committed your fixes up to the point where you
> start discussing class documentation.
> 
> We have to decide: is it OK to document the class constructor in
> __init__?  We used to put this in the class docstring itself so that
> "help" and IPython's "?" would find it, but I don't think this is longer
> necessary.  On the other hand, it makes sense: you call "x = MyClass()"
> to construct, not "x = MyClass.__init__()".  Comments welcome.

IMHO, it would be clearer if the __init__ method was documented 
separately. It can be included on the same page in the Sphinx output as 
the class quite easily. This would allow separate referring to the class 
constructor via eg. :ref:`ndarray <ndarray.__init__>` which might result 
to cleaner documentation.

This may require some changes to the doc editor, too. I guess currently 
__init__ is not available there.

In addition to clarifying these guidelines, I think someone (me?) needs 
to spend some time on making Sphinx generate acceptable documentation for 
classes. Right now, I'd suppose that what needs to be done is 
automatically transforming the "Attributes" and "Methods" sections to 
(autosummary?) tables and placing them to the bottom of the class 
documentation pages.

We may have to implement some custom pre-generation for this, or write 
the corresponding RST files by hand. I'm not sure it's possible to do the 
above via docstring mangling. The question is mainly whether Sphinx 
tolerates toctree nodes inside class nodes. In the manual alternative, we 
write RST files for each class manually,

	.. currentmodule:: numpy

	.. autoclass:: ndarray

	   .. automethod:: __init__

	Methods
	-------

	.. autosummary::
	   :toctree:

	   ~ndarray.sum
	   ~ndarray.prod

	Attributes
	----------

	.. autosummary::
	   :toctree:

	   ~ndarray.T
	   ~ndarray.flags

or just have the Makefile pre-generate these files for us. This would be 
simpler than mucking with docutils toctrees.

One technical question here is also where the method and attribute pages 
should go in the Sphinx toctree. This has relevance for the PDF output. 
The optimal approach here seems to be the one shown above, ie., make the 
autosummary directives to be generated from the class docstrings to 
be :toctree:-ful. The method and attribute descriptions would then 
immediately follow the class description. This requires some changes to 
the workings of the stub page generation (ie. it should call the 
docstring mangling hooks also when generating), but I guess there is 
still get these changes included in Sphinx 1.0.

The intent of the Methods and Attributes sections in the above scenario 
would mostly be listing the class members that form the API. Descriptions 
given in the Methods and Attributes sections would be ignored in the 
final documentation -- at least for those members that have their own 
docstrings. I wonder if we should allow "See Also"-styled abbreviated 
description lists in these sections?

> A couple of questions and comments about the patch:
> 
>  	326	   Not all examples will run though, due to them 
>                  including blank lines 
>       327	   in the output. Do not put in doctest-specific 
>                  markup like
>  	328	   ``<BLANKLINE>`` or ``#doctest: +SKIP``, readability 
>                  is more important 
>       329	   here than being able to execute the doctests 
>                  in a testing framework.
> 
> What is the plan here?  We must be able to execute the doctests in some
> way.

We mostly are: WHITESPACE skipping is enabled by default in the doctests, 
so using <BLANKLINE> is never necessary -- just omit the empty line.

I'm not so sure about #doctest: +SKIP lines.

>  	409	Class instances normally take the docstring of the class. 
>               In the Numpy 
>       410	namespace some class instances are made available 
>               to expose certain 
>       411	functionality.
> 
> I know what you mean by the above, but I think these sentences are a bit
> confusing.

This probably is clarified by giving examples.

>  	419	Documenting constants
> 
> To which constants are you referring?  Give an example to clarify.

numpy.nan, numpy.inf, numpy.PZERO, numpy.e. Currently, the docstrings for 
these live in numpy.doc.constants. Not yet included in the Sphinx-
generated docs, though.

-- 
Pauli Virtanen



From stefan at sun.ac.za  Mon Jun 22 06:23:18 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 22 Jun 2009 12:23:18 +0200
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <h1ni38$bqi$1@ger.gmane.org>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com> 
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com> 
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com> 
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com> 
	<h1ni38$bqi$1@ger.gmane.org>
Message-ID: <9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>

2009/6/22 Pauli Virtanen <pav at iki.fi>:
>> We have to decide: is it OK to document the class constructor in
>> __init__? ?We used to put this in the class docstring itself so that
>> "help" and IPython's "?" would find it, but I don't think this is longer
>> necessary. ?On the other hand, it makes sense: you call "x = MyClass()"
>> to construct, not "x = MyClass.__init__()". ?Comments welcome.
>
> IMHO, it would be clearer if the __init__ method was documented
> separately. It can be included on the same page in the Sphinx output as
> the class quite easily. This would allow separate referring to the class
> constructor via eg. :ref:`ndarray <ndarray.__init__>` which might result
> to cleaner documentation.

I wouldn't mind changing this part of the standard.  Robert, I
remember you had a preference last time, do you want to comment?

> The intent of the Methods and Attributes sections in the above scenario
> would mostly be listing the class members that form the API. Descriptions
> given in the Methods and Attributes sections would be ignored in the
> final documentation -- at least for those members that have their own
> docstrings. I wonder if we should allow "See Also"-styled abbreviated
> description lists in these sections?

It's unfortunate that we need to fill these sections in by hand.  We
could auto-generate them for the Sphinx docs, but then the terminal
users would still be stuck.

> I'm not so sure about #doctest: +SKIP lines.

I reverted that change in HOWOT_DOCUMENT.txt for now.

Regards
St?fan


From pav at iki.fi  Mon Jun 22 07:40:03 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 22 Jun 2009 11:40:03 +0000 (UTC)
Subject: [SciPy-dev] Doc-ing classes and data attributes
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
Message-ID: <h1nqij$7hf$1@ger.gmane.org>

Mon, 22 Jun 2009 12:23:18 +0200, St?fan van der Walt kirjoitti:
[clip: Attributes, Methods]
> It's unfortunate that we need to fill these sections in by hand.  We
> could auto-generate them for the Sphinx docs, but then the terminal
> users would still be stuck.

help(ndarray) does list all the methods and properties, though not 
necessarily all attributes.

Not all visible attributes or methods in a class are a part of the API, 
though, and some are unimportant for the use of the class. Also, some but 
not all __special__ methods may be important. I don't think there is an 
easy way to automatically decide which methods to include and which not, 
so IMHO writing this part manually is an important element in making sure 
that the documentation makes sense. (As opposed to eg. epydoc-generated 
lists full of irrelevant details.)

I wonder: should the format allow lists to be interspersed with 
commentary, so that attributes etc. could be grouped sensibly?

-- 
Pauli Virtanen



From robert.kern at gmail.com  Mon Jun 22 12:19:14 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 22 Jun 2009 11:19:14 -0500
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com> 
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com> 
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com> 
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com> 
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
Message-ID: <3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>

2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
>
> 2009/6/22 Pauli Virtanen <pav at iki.fi>:
> >> We have to decide: is it OK to document the class constructor in
> >> __init__? ?We used to put this in the class docstring itself so that
> >> "help" and IPython's "?" would find it, but I don't think this is longer
> >> necessary. ?On the other hand, it makes sense: you call "x = MyClass()"
> >> to construct, not "x = MyClass.__init__()". ?Comments welcome.
> >
> > IMHO, it would be clearer if the __init__ method was documented
> > separately. It can be included on the same page in the Sphinx output as
> > the class quite easily. This would allow separate referring to the class
> > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might result
> > to cleaner documentation.
>
> I wouldn't mind changing this part of the standard. ?Robert, I
> remember you had a preference last time, do you want to comment?

I have always preferred documenting the __init__'s Parameters in the
class docstring because one calls the class object itself.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
?-- Umberto Eco


From d_l_goldsmith at yahoo.com  Mon Jun 22 12:27:43 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 22 Jun 2009 09:27:43 -0700 (PDT)
Subject: [SciPy-dev] Doc-ing classes and data attributes
Message-ID: <909002.75242.qm@web52103.mail.re2.yahoo.com>


Boy, did I open a can of worms! :-(

DG

--- On Mon, 6/22/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] Doc-ing classes and data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Monday, June 22, 2009, 9:19 AM
> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
> >
> > 2009/6/22 Pauli Virtanen <pav at iki.fi>:
> > >> We have to decide: is it OK to document the
> class constructor in
> > >> __init__? ?We used to put this in the class
> docstring itself so that
> > >> "help" and IPython's "?" would find it, but I
> don't think this is longer
> > >> necessary. ?On the other hand, it makes
> sense: you call "x = MyClass()"
> > >> to construct, not "x = MyClass.__init__()".
> ?Comments welcome.
> > >
> > > IMHO, it would be clearer if the __init__ method
> was documented
> > > separately. It can be included on the same page
> in the Sphinx output as
> > > the class quite easily. This would allow separate
> referring to the class
> > > constructor via eg. :ref:`ndarray
> <ndarray.__init__>` which might result
> > > to cleaner documentation.
> >
> > I wouldn't mind changing this part of the standard.
> ?Robert, I
> > remember you had a preference last time, do you want
> to comment?
> 
> I have always preferred documenting the __init__'s
> Parameters in the
> class docstring because one calls the class object itself.
> 
> --
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ?-- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From robert.kern at gmail.com  Mon Jun 22 12:29:20 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 22 Jun 2009 11:29:20 -0500
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <909002.75242.qm@web52103.mail.re2.yahoo.com>
References: <909002.75242.qm@web52103.mail.re2.yahoo.com>
Message-ID: <3d375d730906220929gbd62b0bmcc788a849f4878c@mail.gmail.com>

On Mon, Jun 22, 2009 at 11:27, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:
>
> Boy, did I open a can of worms! :-(

Welcome to Open Source(TM)! No issue is so small that we can't bicker
about it endlessly.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
?-- Umberto Eco


From stefan at sun.ac.za  Mon Jun 22 12:41:48 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 22 Jun 2009 18:41:48 +0200
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <3d375d730906220929gbd62b0bmcc788a849f4878c@mail.gmail.com>
References: <909002.75242.qm@web52103.mail.re2.yahoo.com>
	<3d375d730906220929gbd62b0bmcc788a849f4878c@mail.gmail.com>
Message-ID: <9457e7c80906220941x76505158n332d980db2f64f34@mail.gmail.com>

2009/6/22 Robert Kern <robert.kern at gmail.com>:
> On Mon, Jun 22, 2009 at 11:27, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:
>>
>> Boy, did I open a can of worms! :-(
>
> Welcome to Open Source(TM)! No issue is so small that we can't bicker
> about it endlessly.

Like they say in the university world: "The competition is so fierce,
because the stakes are so low."

St?fan


From d_l_goldsmith at yahoo.com  Mon Jun 22 12:45:36 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 22 Jun 2009 09:45:36 -0700 (PDT)
Subject: [SciPy-dev] Minutes from last week's Marathon Skypecon and Reminder
	for next one
Message-ID: <839270.70746.qm@web52112.mail.re2.yahoo.com>


Hi, folks!  This week's Numpy Doc Summer Marathon Skypecon will be Wednesday, June 24, 19:00 UTC (15:00 EDT, for example).  And below are Minutes of the last week's.  Bye,

DG

Numpy Doc Summer '09 Marathon
June 18, 2009 Skypecon Minutes

Start: 12:30 UTC
End: 13:15 UTC

Present:
David Goldsmith, Secretary
Joe Harrington
Stefan van der Walt

Discussions:

Low recruitment

    Stefan suggested putting out very specific, small goals as less intimidating
    Joe suggested a weekly goal, e.g., a particular category each week to try to finish off
    Joe suggested appealing to prominent individuals in target constituencies, asking them to appeal to their constituencies for volunteers
    Joe also noted that low production so far can be interpreted by the volunteer pool as low general interest, i.e., show some production and we may see greater recruitment

Low Skypecon participation

    discussed time zone differences and tried to come up w/ a time that might be more universally "user-friendly"; arrived at Wednesday's, 19:00 UTC
    decided to check this time w/ VIP's

Review procedure

    Discussed dividing the review requirement into two separate reviews, a technical review and a presentation review, both of which need to pass before the item can be passed on to the proof stage
    Decided that this should be vetted by the scipy-dev community before making implementation of it an "issue" on pydocweb

Wiki features

    Discussed addition of a "click on a name, get a list of that person's work" feature to the Wiki; subsequently added as an issue on pydocweb

    Discussed auto-updating and caching the Milestones page periodically to reduce load times; subsequently added as an issue on pydocweb

Relationship between the docstrings, the reference rst files, and the Wiki

    This discussion became rather fragmented - uncertain if any real "center" coalesced

Notes:

    Had technical difficulties, primarily w/ DG being dropped, ultimately had to resort to group text messaging, which was awkward


      


From ralf.gommers at googlemail.com  Mon Jun 22 15:03:29 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 22 Jun 2009 15:03:29 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
Message-ID: <dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>

2009/6/22 St?fan van der Walt <stefan at sun.ac.za>

> Hi Ralf
>
> Thanks for the patch!  I committed your fixes up to the point where
> you start discussing class documentation.
>
> We have to decide: is it OK to document the class constructor in
> __init__?  We used to put this in the class docstring itself so that
> "help" and IPython's "?" would find it, but I don't think this is
> longer necessary.  On the other hand, it makes sense: you call "x =
> MyClass()" to construct, not "x = MyClass.__init__()".  Comments
> welcome.
>
> A couple of questions and comments about the patch:
>
>        326        Not all examples will run though, due to them including
> blank lines
>        327        in the output. Do not put in doctest-specific markup like
>        328        ``<BLANKLINE>`` or ``#doctest: +SKIP``, readability is
> more important
>        329        here than being able to execute the doctests in a testing
> framework.
>
> What is the plan here?  We must be able to execute the doctests in some
> way.
>

>From previous emails on the list (from Robert) I learned that we do not
execute these doctests, and do not even have a way of doing that at the
moment. If that's not correct then the ``#doctest: +SKIP`` should stay. If
it is correct, then doctest directives are just noise that the user should
not see.


>        409     Class instances normally take the docstring of the class. In
> the Numpy
>        410     namespace some class instances are made available to expose
> certain
>        411     functionality.
>
> I know what you mean by the above, but I think these sentences are a
> bit confusing.
>

I'll rephrase and give a concrete example.


>
>        419     Documenting constants
>
> To which constants are you referring?  Give an example to clarify.
>
>        436     * [,out] : All ufuncs accept an optional `out` argument.
> This is
>        437       documented in the **Output arguments** section of
> `doc.ufuncs`. In the
>        438       docstring this argument should be documented like this::
>        439
>        440         out : ndarray, optional
>        441             Array into which the output is placed. Its type is
> preserved and
>        442             it must be of the right shape to hold the output.
> See
> `doc.ufuncs`.
>
> I think we can leave this out of the standard, since it pertains to a
> very specific part of numpy.


Maybe it doesn't belong in the standard, but it should be somewhere so we
get these things done as uniformly as possible. I'd be happy with a wiki
page for points like this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090622/b6623346/attachment.html>

From ralf.gommers at googlemail.com  Mon Jun 22 15:11:29 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 22 Jun 2009 15:11:29 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
Message-ID: <dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>

On Mon, Jun 22, 2009 at 12:19 PM, Robert Kern <robert.kern at gmail.com> wrote:

> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
> >
> > 2009/6/22 Pauli Virtanen <pav at iki.fi>:
> > >> We have to decide: is it OK to document the class constructor in
> > >> __init__?  We used to put this in the class docstring itself so that
> > >> "help" and IPython's "?" would find it, but I don't think this is
> longer
> > >> necessary.  On the other hand, it makes sense: you call "x =
> MyClass()"
> > >> to construct, not "x = MyClass.__init__()".  Comments welcome.
> > >
> > > IMHO, it would be clearer if the __init__ method was documented
> > > separately. It can be included on the same page in the Sphinx output as
> > > the class quite easily. This would allow separate referring to the
> class
> > > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might
> result
> > > to cleaner documentation.
> >
> > I wouldn't mind changing this part of the standard.  Robert, I
> > remember you had a preference last time, do you want to comment?
>
> I have always preferred documenting the __init__'s Parameters in the
> class docstring because one calls the class object itself.
>

I prefer this as well. Why make it more complicated unless there's a good
reason?
Also, IPython will maybe still be able to do the right thing if both class
and __init__ are documented, but the standard Python prompt's help()
function will not. And there are still a lot of users of the standard
prompt, simply because it's the standard.


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090622/77d57d54/attachment.html>

From josef.pktd at gmail.com  Mon Jun 22 16:41:38 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 22 Jun 2009 16:41:38 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
	<dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>
Message-ID: <1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com>

On Mon, Jun 22, 2009 at 3:11 PM, Ralf
Gommers<ralf.gommers at googlemail.com> wrote:
>
>
> On Mon, Jun 22, 2009 at 12:19 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
>> >
>> > 2009/6/22 Pauli Virtanen <pav at iki.fi>:
>> > >> We have to decide: is it OK to document the class constructor in
>> > >> __init__? ?We used to put this in the class docstring itself so that
>> > >> "help" and IPython's "?" would find it, but I don't think this is
>> > >> longer
>> > >> necessary. ?On the other hand, it makes sense: you call "x =
>> > >> MyClass()"
>> > >> to construct, not "x = MyClass.__init__()". ?Comments welcome.
>> > >
>> > > IMHO, it would be clearer if the __init__ method was documented
>> > > separately. It can be included on the same page in the Sphinx output
>> > > as
>> > > the class quite easily. This would allow separate referring to the
>> > > class
>> > > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might
>> > > result
>> > > to cleaner documentation.
>> >
>> > I wouldn't mind changing this part of the standard. ?Robert, I
>> > remember you had a preference last time, do you want to comment?
>>
>> I have always preferred documenting the __init__'s Parameters in the
>> class docstring because one calls the class object itself.
>
> I prefer this as well. Why make it more complicated unless there's a good
> reason?
> Also, IPython will maybe still be able to do the right thing if both class
> and __init__ are documented, but the standard Python prompt's help()
> function will not. And there are still a lot of users of the standard
> prompt, simply because it's the standard.


pythons help is actually very informative but our documentation is
not. Whatever the decision, we should adjust the current docstrings so
that they actually get included in the generated docs.
E.g. scipy.interpolate: after last years discussion a large part of
the information is only available as docstring to the __init__ method.
If we stick with documenting the constructor in the class docstring,
then we should move them.

As an enhancement to the doc editor, it would be nice if it would also
show the generated documentation from an autoclass directive. This
would reduce the guessing about whether and how the docstrings will
show up.

How do we treat other class specific headers?
e.g "Internal Methods" in
http://docs.scipy.org/scipy/docs/scipy.stats.kde.gaussian_kde/

I hope some nice examples come out of this, so we can include some of
the left out class documentation in scipy without a lot of guessing.

Josef

>
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whole world is an enigma, a harmless
>> enigma that is made terrible by our own mad attempt to interpret it as
>> though it had an underlying truth."
>> ?-- Umberto Eco
>> _______________________________________________
>> 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
>
>


From charlesr.harris at gmail.com  Mon Jun 22 16:59:13 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 22 Jun 2009 14:59:13 -0600
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
Message-ID: <e06186140906221359k75c2e688xda30e5b710543ef6@mail.gmail.com>

On Mon, Jun 22, 2009 at 10:19 AM, Robert Kern<robert.kern at gmail.com> wrote:
> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
>>
>> 2009/6/22 Pauli Virtanen <pav at iki.fi>:
>> >> We have to decide: is it OK to document the class constructor in
>> >> __init__? ?We used to put this in the class docstring itself so that
>> >> "help" and IPython's "?" would find it, but I don't think this is longer
>> >> necessary. ?On the other hand, it makes sense: you call "x = MyClass()"
>> >> to construct, not "x = MyClass.__init__()". ?Comments welcome.
>> >
>> > IMHO, it would be clearer if the __init__ method was documented
>> > separately. It can be included on the same page in the Sphinx output as
>> > the class quite easily. This would allow separate referring to the class
>> > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might result
>> > to cleaner documentation.
>>
>> I wouldn't mind changing this part of the standard. ?Robert, I
>> remember you had a preference last time, do you want to comment?
>
> I have always preferred documenting the __init__'s Parameters in the
> class docstring because one calls the class object itself.
>

Same here.

Chuck


From ralf.gommers at googlemail.com  Mon Jun 22 17:32:04 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 22 Jun 2009 17:32:04 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
	<dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>
	<1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com>
Message-ID: <dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>

On Mon, Jun 22, 2009 at 4:41 PM, <josef.pktd at gmail.com> wrote:

> On Mon, Jun 22, 2009 at 3:11 PM, Ralf
> Gommers<ralf.gommers at googlemail.com> wrote:
> >
> >
> > On Mon, Jun 22, 2009 at 12:19 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
> >>
> >> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
> >> >
> >> > 2009/6/22 Pauli Virtanen <pav at iki.fi>:
> >> > >> We have to decide: is it OK to document the class constructor in
> >> > >> __init__?  We used to put this in the class docstring itself so
> that
> >> > >> "help" and IPython's "?" would find it, but I don't think this is
> >> > >> longer
> >> > >> necessary.  On the other hand, it makes sense: you call "x =
> >> > >> MyClass()"
> >> > >> to construct, not "x = MyClass.__init__()".  Comments welcome.
> >> > >
> >> > > IMHO, it would be clearer if the __init__ method was documented
> >> > > separately. It can be included on the same page in the Sphinx output
> >> > > as
> >> > > the class quite easily. This would allow separate referring to the
> >> > > class
> >> > > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might
> >> > > result
> >> > > to cleaner documentation.
> >> >
> >> > I wouldn't mind changing this part of the standard.  Robert, I
> >> > remember you had a preference last time, do you want to comment?
> >>
> >> I have always preferred documenting the __init__'s Parameters in the
> >> class docstring because one calls the class object itself.
> >
> > I prefer this as well. Why make it more complicated unless there's a good
> > reason?
> > Also, IPython will maybe still be able to do the right thing if both
> class
> > and __init__ are documented, but the standard Python prompt's help()
> > function will not. And there are still a lot of users of the standard
> > prompt, simply because it's the standard.
>
>
> pythons help is actually very informative but our documentation is
> not. Whatever the decision, we should adjust the current docstrings so
> that they actually get included in the generated docs.
> E.g. scipy.interpolate: after last years discussion a large part of
> the information is only available as docstring to the __init__ method.
> If we stick with documenting the constructor in the class docstring,
> then we should move them.
>

scipy.interpolate is a module, so I assume you mean the classes in it. For
some classes it is done correctly (see interp2d), other classes have both
class and constructor documented (see interp1d). Doc writing has mainly
concentrated on numpy so far, and there I have not come across classes with
both class and constructor being documented.
I agree it would be very useful for someone to go through scipy modules and
move things around.


> As an enhancement to the doc editor, it would be nice if it would also
> show the generated documentation from an autoclass directive. This
> would reduce the guessing about whether and how the docstrings will
> show up.


agreed

>
>
> How do we treat other class specific headers?
> e.g "Internal Methods" in
> http://docs.scipy.org/scipy/docs/scipy.stats.kde.gaussian_kde/


Internal Methods is not a part of the documentation standard. Was this
discussed on the list last year? I thought the consensus was that methods
that are part of the API go under Methods, the rest is not listed in the
class docstring.

Ralf


>
> I hope some nice examples come out of this, so we can include some of
> the left out class documentation in scipy without a lot of guessing.
>
> Josef
>
> >
> >>
> >> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090622/d66107a9/attachment.html>

From robert.kern at gmail.com  Mon Jun 22 17:33:55 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 22 Jun 2009 16:33:55 -0500
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com> 
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com> 
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com> 
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com> 
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com> 
	<dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com> 
	<1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com> 
	<dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>
Message-ID: <3d375d730906221433s5714ecdfo473c53b794892ed2@mail.gmail.com>

On Mon, Jun 22, 2009 at 16:32, Ralf Gommers<ralf.gommers at googlemail.com> wrote:
>
> On Mon, Jun 22, 2009 at 4:41 PM, <josef.pktd at gmail.com> wrote:

>> How do we treat other class specific headers?
>> e.g "Internal Methods" in
>> http://docs.scipy.org/scipy/docs/scipy.stats.kde.gaussian_kde/
>
> Internal Methods is not a part of the documentation standard. Was this
> discussed on the list last year? I thought the consensus was that methods
> that are part of the API go under Methods, the rest is not listed in the
> class docstring.

It's just an incredibly old docstring from long before we bothered to
standardize anything.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From ralf.gommers at googlemail.com  Mon Jun 22 17:42:26 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 22 Jun 2009 17:42:26 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <3d375d730906221433s5714ecdfo473c53b794892ed2@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
	<dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>
	<1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com>
	<dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>
	<3d375d730906221433s5714ecdfo473c53b794892ed2@mail.gmail.com>
Message-ID: <dde7764a0906221442vf4b36b8qf7e491c413deae0d@mail.gmail.com>

On Mon, Jun 22, 2009 at 5:33 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Mon, Jun 22, 2009 at 16:32, Ralf Gommers<ralf.gommers at googlemail.com>
> wrote:
> >
> > On Mon, Jun 22, 2009 at 4:41 PM, <josef.pktd at gmail.com> wrote:
>
> >> How do we treat other class specific headers?
> >> e.g "Internal Methods" in
> >> http://docs.scipy.org/scipy/docs/scipy.stats.kde.gaussian_kde/
> >
> > Internal Methods is not a part of the documentation standard. Was this
> > discussed on the list last year? I thought the consensus was that methods
> > that are part of the API go under Methods, the rest is not listed in the
> > class docstring.
>
> It's just an incredibly old docstring from long before we bothered to
> standardize anything.
>

Great, thanks. I guess in that case the answer to Josef's question is:
There should be no other class-specific headers, if you come across any,
remove them.

Ralf


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090622/deb965a6/attachment.html>

From josef.pktd at gmail.com  Mon Jun 22 18:45:32 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 22 Jun 2009 18:45:32 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
	<dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>
	<1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com>
	<dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>
Message-ID: <1cd32cbb0906221545g4ff2ccc3w7315dc847b6d01b6@mail.gmail.com>

On Mon, Jun 22, 2009 at 5:32 PM, Ralf
Gommers<ralf.gommers at googlemail.com> wrote:
>
>
> On Mon, Jun 22, 2009 at 4:41 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Mon, Jun 22, 2009 at 3:11 PM, Ralf
>> Gommers<ralf.gommers at googlemail.com> wrote:
>> >
>> >
>> > On Mon, Jun 22, 2009 at 12:19 PM, Robert Kern <robert.kern at gmail.com>
>> > wrote:
>> >>
>> >> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
>> >> >
>> >> > 2009/6/22 Pauli Virtanen <pav at iki.fi>:
>> >> > >> We have to decide: is it OK to document the class constructor in
>> >> > >> __init__? ?We used to put this in the class docstring itself so
>> >> > >> that
>> >> > >> "help" and IPython's "?" would find it, but I don't think this is
>> >> > >> longer
>> >> > >> necessary. ?On the other hand, it makes sense: you call "x =
>> >> > >> MyClass()"
>> >> > >> to construct, not "x = MyClass.__init__()". ?Comments welcome.
>> >> > >
>> >> > > IMHO, it would be clearer if the __init__ method was documented
>> >> > > separately. It can be included on the same page in the Sphinx
>> >> > > output
>> >> > > as
>> >> > > the class quite easily. This would allow separate referring to the
>> >> > > class
>> >> > > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might
>> >> > > result
>> >> > > to cleaner documentation.
>> >> >
>> >> > I wouldn't mind changing this part of the standard. ?Robert, I
>> >> > remember you had a preference last time, do you want to comment?
>> >>
>> >> I have always preferred documenting the __init__'s Parameters in the
>> >> class docstring because one calls the class object itself.
>> >
>> > I prefer this as well. Why make it more complicated unless there's a
>> > good
>> > reason?
>> > Also, IPython will maybe still be able to do the right thing if both
>> > class
>> > and __init__ are documented, but the standard Python prompt's help()
>> > function will not. And there are still a lot of users of the standard
>> > prompt, simply because it's the standard.
>>
>>
>> pythons help is actually very informative but our documentation is
>> not. Whatever the decision, we should adjust the current docstrings so
>> that they actually get included in the generated docs.
>> E.g. scipy.interpolate: after last years discussion a large part of
>> the information is only available as docstring to the __init__ method.
>> If we stick with documenting the constructor in the class docstring,
>> then we should move them.
>
> scipy.interpolate is a module, so I assume you mean the classes in it. For
> some classes it is done correctly (see interp2d), other classes have both
> class and constructor documented (see interp1d). Doc writing has mainly
> concentrated on numpy so far, and there I have not come across classes with
> both class and constructor being documented.
> I agree it would be very useful for someone to go through scipy modules and
> move things around.

interp1d, KroghInterpolator and family, UnivariateSpline and family:
all the constructor information is in the __init__ docstring.

I'm going through scipy myself, but I haven't seen any clear pattern
for good class documentation yet. But if the consensus is to stick
with adding all information into the class docstring, I will start to
move them in interpolate, and clean up the others as I stumble upon
them.

just another random choice for class documentation: I just tried to
understand what numpy.poly1d is as a class, e.g. attributes and
methods.
It has good examples in the class docstring, but what are the methods,
what is p.r and p.c? (try to find it without looking at the source)


What if we want to document some private methods? What's the
corresponding header to "Other Parameters" for other methods?

And I would still like to see heavier use of autoclass at least in the
html and htmlhelp doc, with classes and methods on one page.

I hope your effort on the numpy docs will create some improvement to
the class documentation, so I can use the help file also for classes
instead of reading the source.

Just to emphasize it again, the htmlhelp for numpy and scipy is really
great, instantaneous access to most of the documentation. (I wish some
other packages, like matplotlib, would provide it also, instead of
(*args, *kwargs) popup signatures.)

Josef


>
>>
>> As an enhancement to the doc editor, it would be nice if it would also
>> show the generated documentation from an autoclass directive. This
>> would reduce the guessing about whether and how the docstrings will
>> show up.
>
> agreed
>>
>>
>> How do we treat other class specific headers?
>> e.g "Internal Methods" in
>> http://docs.scipy.org/scipy/docs/scipy.stats.kde.gaussian_kde/
>
> Internal Methods is not a part of the documentation standard. Was this
> discussed on the list last year? I thought the consensus was that methods
> that are part of the API go under Methods, the rest is not listed in the
> class docstring.
>
> Ralf
>
>>
>>
>> I hope some nice examples come out of this, so we can include some of
>> the left out class documentation in scipy without a lot of guessing.
>>
>> Josef
>>
>> >
>> >>
>> >> --
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Mon Jun 22 22:14:13 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 22 Jun 2009 22:14:13 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <1cd32cbb0906221545g4ff2ccc3w7315dc847b6d01b6@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<h1ni38$bqi$1@ger.gmane.org>
	<9457e7c80906220323p57e0db7fna8cefc2da367e93@mail.gmail.com>
	<3d375d730906220919i47d1930ap192331f499980f5f@mail.gmail.com>
	<dde7764a0906221211j843fae6pcbaec944f5f12ab8@mail.gmail.com>
	<1cd32cbb0906221341v16177778xac4fc171c6548b73@mail.gmail.com>
	<dde7764a0906221432g49749938p39ca313f78eeda6@mail.gmail.com>
	<1cd32cbb0906221545g4ff2ccc3w7315dc847b6d01b6@mail.gmail.com>
Message-ID: <dde7764a0906221914o24530cf0xd6968b91b729fb43@mail.gmail.com>

On Mon, Jun 22, 2009 at 6:45 PM, <josef.pktd at gmail.com> wrote:

> On Mon, Jun 22, 2009 at 5:32 PM, Ralf
> Gommers<ralf.gommers at googlemail.com> wrote:
> >
> >
> > On Mon, Jun 22, 2009 at 4:41 PM, <josef.pktd at gmail.com> wrote:
> >>
> >> On Mon, Jun 22, 2009 at 3:11 PM, Ralf
> >> Gommers<ralf.gommers at googlemail.com> wrote:
> >> >
> >> >
> >> > On Mon, Jun 22, 2009 at 12:19 PM, Robert Kern <robert.kern at gmail.com>
> >> > wrote:
> >> >>
> >> >> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
> >> >> >
> >> >> > 2009/6/22 Pauli Virtanen <pav at iki.fi>:
> >> >> > >> We have to decide: is it OK to document the class constructor in
> >> >> > >> __init__?  We used to put this in the class docstring itself so
> >> >> > >> that
> >> >> > >> "help" and IPython's "?" would find it, but I don't think this
> is
> >> >> > >> longer
> >> >> > >> necessary.  On the other hand, it makes sense: you call "x =
> >> >> > >> MyClass()"
> >> >> > >> to construct, not "x = MyClass.__init__()".  Comments welcome.
> >> >> > >
> >> >> > > IMHO, it would be clearer if the __init__ method was documented
> >> >> > > separately. It can be included on the same page in the Sphinx
> >> >> > > output
> >> >> > > as
> >> >> > > the class quite easily. This would allow separate referring to
> the
> >> >> > > class
> >> >> > > constructor via eg. :ref:`ndarray <ndarray.__init__>` which might
> >> >> > > result
> >> >> > > to cleaner documentation.
> >> >> >
> >> >> > I wouldn't mind changing this part of the standard.  Robert, I
> >> >> > remember you had a preference last time, do you want to comment?
> >> >>
> >> >> I have always preferred documenting the __init__'s Parameters in the
> >> >> class docstring because one calls the class object itself.
> >> >
> >> > I prefer this as well. Why make it more complicated unless there's a
> >> > good
> >> > reason?
> >> > Also, IPython will maybe still be able to do the right thing if both
> >> > class
> >> > and __init__ are documented, but the standard Python prompt's help()
> >> > function will not. And there are still a lot of users of the standard
> >> > prompt, simply because it's the standard.
> >>
> >>
> >> pythons help is actually very informative but our documentation is
> >> not. Whatever the decision, we should adjust the current docstrings so
> >> that they actually get included in the generated docs.
> >> E.g. scipy.interpolate: after last years discussion a large part of
> >> the information is only available as docstring to the __init__ method.
> >> If we stick with documenting the constructor in the class docstring,
> >> then we should move them.
> >
> > scipy.interpolate is a module, so I assume you mean the classes in it.
> For
> > some classes it is done correctly (see interp2d), other classes have both
> > class and constructor documented (see interp1d). Doc writing has mainly
> > concentrated on numpy so far, and there I have not come across classes
> with
> > both class and constructor being documented.
> > I agree it would be very useful for someone to go through scipy modules
> and
> > move things around.
>
> interp1d, KroghInterpolator and family, UnivariateSpline and family:
> all the constructor information is in the __init__ docstring.
>
> I'm going through scipy myself, but I haven't seen any clear pattern
> for good class documentation yet. But if the consensus is to stick
> with adding all information into the class docstring, I will start to
> move them in interpolate, and clean up the others as I stumble upon
> them.


There are very few classes that have made it to "Needs review" yet, and most
of the ones that did are quite simple. For one of the better examples, see
http://docs.scipy.org/numpy/docs/numpy.ndarray/ It's not done yet, but when
the list of attributes is removed (it is the same as Properties at the
bottom) and the Methods and Properties would show the one-line summary (with
some preprocessor magic), I would consider it a good example.


>
>
> just another random choice for class documentation: I just tried to
> understand what numpy.poly1d is as a class, e.g. attributes and
> methods.
> It has good examples in the class docstring, but what are the methods,
> what is p.r and p.c? (try to find it without looking at the source)
>

Wow, that is obscure. The two public methods are "deriv" and integ". As for
p.c and p.r, I had to look for a while in the source even. They also don't
show up in IPython with tab completion, because of the way it is coded with
__getattr__ magic. I think the message is: do not code it like this unless
there is a very good reason. Why not just:

def roots(self):
    return roots(self.coeffs)

The alias 'r' for 'roots' is not very helpful (but is maybe there for
historical reasons). If it would be coded like the above, it would
automatically show up in the list of methods.

>
>
> What if we want to document some private methods? What's the
> corresponding header to "Other Parameters" for other methods?
>

Private methods have docstrings, which is where they are explained. If you
document them in the class docstring, they show up for the user. Why would
you want to do that (they are private for a reason)?


> And I would still like to see heavier use of autoclass at least in the
> html and htmlhelp doc, with classes and methods on one page.
>

agreed. maybe not the full method docstrings but at least the summary.

>
> I hope your effort on the numpy docs will create some improvement to
> the class documentation, so I can use the help file also for classes
> instead of reading the source.


I hope so too.

>
>
> Just to emphasize it again, the htmlhelp for numpy and scipy is really
> great, instantaneous access to most of the documentation. (I wish some
> other packages, like matplotlib, would provide it also, instead of
> (*args, *kwargs) popup signatures.)
>
> Josef
>
>
> >
> >>
> >> As an enhancement to the doc editor, it would be nice if it would also
> >> show the generated documentation from an autoclass directive. This
> >> would reduce the guessing about whether and how the docstrings will
> >> show up.
> >
> > agreed
> >>
> >>
> >> How do we treat other class specific headers?
> >> e.g "Internal Methods" in
> >> http://docs.scipy.org/scipy/docs/scipy.stats.kde.gaussian_kde/
> >
> > Internal Methods is not a part of the documentation standard. Was this
> > discussed on the list last year? I thought the consensus was that methods
> > that are part of the API go under Methods, the rest is not listed in the
> > class docstring.
> >
> > Ralf
> >
> >>
> >>
> >> I hope some nice examples come out of this, so we can include some of
> >> the left out class documentation in scipy without a lot of guessing.
> >>
> >> Josef
> >>
> >> >
> >> >>
> >> >> --
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090622/f89b0782/attachment.html>

From ralf.gommers at googlemail.com  Tue Jun 23 11:15:02 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 23 Jun 2009 11:15:02 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>
Message-ID: <dde7764a0906230815i33f4e136l88efb188fb6201c8@mail.gmail.com>

On Mon, Jun 22, 2009 at 3:03 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> 2009/6/22 St?fan van der Walt <stefan at sun.ac.za>
>
>> Hi Ralf
>>
>> Thanks for the patch!  I committed your fixes up to the point where
>> you start discussing class documentation.
>>
>> We have to decide: is it OK to document the class constructor in
>> __init__?  We used to put this in the class docstring itself so that
>> "help" and IPython's "?" would find it, but I don't think this is
>> longer necessary.  On the other hand, it makes sense: you call "x =
>> MyClass()" to construct, not "x = MyClass.__init__()".  Comments
>> welcome.
>>
>> A couple of questions and comments about the patch:
>>
>>        326        Not all examples will run though, due to them including
>> blank lines
>>        327        in the output. Do not put in doctest-specific markup
>> like
>>        328        ``<BLANKLINE>`` or ``#doctest: +SKIP``, readability is
>> more important
>>        329        here than being able to execute the doctests in a
>> testing framework.
>>
>> What is the plan here?  We must be able to execute the doctests in some
>> way.
>>
>
> From previous emails on the list (from Robert) I learned that we do not
> execute these doctests, and do not even have a way of doing that at the
> moment. If that's not correct then the ``#doctest: +SKIP`` should stay. If
> it is correct, then doctest directives are just noise that the user should
> not see.
>


Okay, I tried running doctests. I chose polynomial.py as an example.
Executing:
$ nosetests --with-doctest numpy/lib/polynomial.py
first gives all errors, because ``import numpy as np`` is missing. Adding
that, I still get errors:

$ nosetests --with-doctest numpy/lib/polynomial.py
.F.F/usr/lib/python2.6/dist-packages/matplotlib/texmanager.py:55:
DeprecationWarning: os.popen4 is deprecated.  Use the subprocess
module.

  stdin, stdout = os.popen4('dvipng
-version')

FF...


======================================================================
FAIL: Doctest: numpy.lib.polynomial.polydiv
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/doctest.py", line 2145, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for numpy.lib.polynomial.polydiv
  File "/home/ralf/python/numpy/numpy/lib/polynomial.py", line 680, in
polydiv

----------------------------------------------------------------------
File "/home/ralf/python/numpy/numpy/lib/polynomial.py", line 712, in
numpy.lib.polynomial.polydiv
Failed
example:

    np.polydiv(x,
y)

Expected
nothing

Got:

    (array([ 1.5 ,  1.75]), array([
0.25]))


(...lots more errors here...)


Ran 9 tests in 5.643s

FAILED (failures=4)



It looks like these doctests have not worked in a long time. There is also a
conceptual problem, do you really want everyone who signs up in the doc
editor to be able to produce test failures because they wrote an example
that doctest does not like?

It seems like removing the part about running doctests from the
documentation standard is the way to go.

Cheers,
Ralf



>
>>        409     Class instances normally take the docstring of the class.
>> In the Numpy
>>        410     namespace some class instances are made available to expose
>> certain
>>        411     functionality.
>>
>> I know what you mean by the above, but I think these sentences are a
>> bit confusing.
>>
>
> I'll rephrase and give a concrete example.
>
>
>>
>>        419     Documenting constants
>>
>> To which constants are you referring?  Give an example to clarify.
>>
>>        436     * [,out] : All ufuncs accept an optional `out` argument.
>> This is
>>        437       documented in the **Output arguments** section of
>> `doc.ufuncs`. In the
>>        438       docstring this argument should be documented like this::
>>        439
>>        440         out : ndarray, optional
>>        441             Array into which the output is placed. Its type is
>> preserved and
>>        442             it must be of the right shape to hold the output.
>> See
>> `doc.ufuncs`.
>>
>> I think we can leave this out of the standard, since it pertains to a
>> very specific part of numpy.
>
>
> Maybe it doesn't belong in the standard, but it should be somewhere so we
> get these things done as uniformly as possible. I'd be happy with a wiki
> page for points like this.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090623/e0482216/attachment.html>

From pav at iki.fi  Tue Jun 23 11:44:12 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 23 Jun 2009 15:44:12 +0000 (UTC)
Subject: [SciPy-dev] Doc-ing classes and data attributes
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>
	<dde7764a0906230815i33f4e136l88efb188fb6201c8@mail.gmail.com>
Message-ID: <h1qt8b$vvk$1@ger.gmane.org>

Tue, 23 Jun 2009 11:15:02 -0400, Ralf Gommers kirjoitti:

> Okay, I tried running doctests. I chose polynomial.py as an example.
> Executing:
> $ nosetests --with-doctest numpy/lib/polynomial.py first gives all
> errors,

Run them with 'numpy.test(doctests=True)'.

There was a lot of discussion about this thing last year on this list.

-- 
Pauli Virtanen



From ralf.gommers at googlemail.com  Tue Jun 23 15:07:37 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 23 Jun 2009 15:07:37 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <h1qt8b$vvk$1@ger.gmane.org>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>
	<dde7764a0906230815i33f4e136l88efb188fb6201c8@mail.gmail.com>
	<h1qt8b$vvk$1@ger.gmane.org>
Message-ID: <dde7764a0906231207t2d368f7eq6258e2e6456c8e15@mail.gmail.com>

On Tue, Jun 23, 2009 at 11:44 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Tue, 23 Jun 2009 11:15:02 -0400, Ralf Gommers kirjoitti:
>
> > Okay, I tried running doctests. I chose polynomial.py as an example.
> > Executing:
> > $ nosetests --with-doctest numpy/lib/polynomial.py first gives all
> > errors,
>
> Run them with 'numpy.test(doctests=True)'.
>
> There was a lot of discussion about this thing last year on this list.
>

Thanks Pauli, I was just following the instructions in the docstandard.
Please ignore my previous email.

I will incorporate this into a new patch.

Cheers,
Ralf



> --
> Pauli Virtanen
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090623/5de4c1f2/attachment.html>

From pav at iki.fi  Tue Jun 23 15:18:46 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 23 Jun 2009 19:18:46 +0000 (UTC)
Subject: [SciPy-dev] Doc-ing classes and data attributes
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>
	<dde7764a0906230815i33f4e136l88efb188fb6201c8@mail.gmail.com>
Message-ID: <h1r9qm$uiq$1@ger.gmane.org>

On 2009-06-23, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
[clip]
> It looks like these doctests have not worked in a long time. There is also
> a conceptual problem, do you really want everyone who signs up in the doc
> editor to be able to produce test failures because they wrote an example
> that doctest does not like?
[clip]

Yeah, it's quite likely that several of the doctests/examples 
there currently fail. But I think that in many cases a failure to 
doctest indicates also that the example is somehow wrong, and 
someone trying to follow it would run into the same problem.

The doctests are not run by default, and are not included in the 
test suite. The features that allow running them are mostly meant 
to make it easier to ensure that all of the examples actually 
work. (Though AFAIK nobody has vetted them through :)

-- 
Pauli Virtanen



From ralf.gommers at googlemail.com  Tue Jun 23 16:19:21 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 23 Jun 2009 16:19:21 -0400
Subject: [SciPy-dev] Doc-ing classes and data attributes
In-Reply-To: <h1r9qm$uiq$1@ger.gmane.org>
References: <76601.5227.qm@web52105.mail.re2.yahoo.com>
	<dde7764a0906202147u551976bey7b20d69e14cdb21e@mail.gmail.com>
	<9457e7c80906210732r3ec238cen1ec01e8e78f9fb42@mail.gmail.com>
	<dde7764a0906211759s47f41b73qcfd43f92079d1af0@mail.gmail.com>
	<9457e7c80906220042x1ca2fb38n31c3222afcc295e3@mail.gmail.com>
	<dde7764a0906221203w3c61a30bh6abe4d0cd818aa6e@mail.gmail.com>
	<dde7764a0906230815i33f4e136l88efb188fb6201c8@mail.gmail.com>
	<h1r9qm$uiq$1@ger.gmane.org>
Message-ID: <dde7764a0906231319m2a7e92d2ma6da8af42c19f626@mail.gmail.com>

On Tue, Jun 23, 2009 at 3:18 PM, Pauli Virtanen <pav at iki.fi> wrote:

> On 2009-06-23, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
> [clip]
> > It looks like these doctests have not worked in a long time. There is
> also
> > a conceptual problem, do you really want everyone who signs up in the doc
> > editor to be able to produce test failures because they wrote an example
> > that doctest does not like?
> [clip]
>
> Yeah, it's quite likely that several of the doctests/examples
> there currently fail. But I think that in many cases a failure to
> doctest indicates also that the example is somehow wrong, and
> someone trying to follow it would run into the same problem.
>
> The doctests are not run by default, and are not included in the
> test suite. The features that allow running them are mostly meant
> to make it easier to ensure that all of the examples actually
> work. (Though AFAIK nobody has vetted them through :)


That makes sense.

I updated the patch attached to #1146, changes are:

   - added note on 75 character per line limit
   - documented the correct way to run doctests, and that this is meant to
   check if the examples work
   - documenting private methods in classes (not sure if there is full
   agreement on this)
   - documenting class instances
   - documenting constants

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090623/b493bb77/attachment.html>

From d_l_goldsmith at yahoo.com  Tue Jun 23 23:45:58 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 23 Jun 2009 20:45:58 -0700 (PDT)
Subject: [SciPy-dev] Final reminder: Numpy Doc Summer Marathon Skypecon
	tomorrow
Message-ID: <392821.2177.qm@web52102.mail.re2.yahoo.com>


i.e., Wednesday, June 24th, 19:00 UTC.  Please get me your Skype ID prior to that if you want to participate.  Thanks!

DG


      


From d_l_goldsmith at yahoo.com  Thu Jun 25 16:39:32 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 25 Jun 2009 13:39:32 -0700 (PDT)
Subject: [SciPy-dev] Summer Marathon: targeting a category per week
Message-ID: <10543.59260.qm@web52109.mail.re2.yahoo.com>


Hi, folks!  So, one of the ideas that came out of last week's Skypecon for increasing participation in the Marathon is to pick a category each week to target for "completion" (meaning Marathon goal met = getting every function to at least the "needs first review" stage) by the following week's Skypecon.  No one nominated any categories last week, but I'm not giving up that easily ;-).  I hereby call for suggestions for a target category for this week (i.e., to be completed by next Wed. July 1) but if I don't receive any by tomorrow morning my time (UTC-7), I'll just choose. :-)  Thanks!

DG


      


From d_l_goldsmith at yahoo.com  Thu Jun 25 16:49:51 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 25 Jun 2009 13:49:51 -0700 (PDT)
Subject: [SciPy-dev] Documenting data attributes
Message-ID: <539406.59181.qm@web52104.mail.re2.yahoo.com>


Hi!  For the purposes of meeting the documentation standard, are data attributes regarded has "returning" something, i.e., should ndarray.itemsize, for example, have a Returns section?

DG


      


From robert.kern at gmail.com  Thu Jun 25 16:55:46 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Jun 2009 15:55:46 -0500
Subject: [SciPy-dev] Documenting data attributes
In-Reply-To: <539406.59181.qm@web52104.mail.re2.yahoo.com>
References: <539406.59181.qm@web52104.mail.re2.yahoo.com>
Message-ID: <3d375d730906251355v73a3b5b4o822bb62ba77913a7@mail.gmail.com>

On Thu, Jun 25, 2009 at 15:49, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> Hi! ?For the purposes of meeting the documentation standard, are data attributes regarded has "returning" something, i.e., should ndarray.itemsize, for example, have a Returns section?

I would describe them in an Attributes section of the class's
docstring. See MachAr for an example I did some time ago.

  http://docs.scipy.org/numpy/docs/numpy.lib.machar.MachAr/

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Thu Jun 25 17:10:47 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 25 Jun 2009 14:10:47 -0700 (PDT)
Subject: [SciPy-dev] Documenting data attributes
Message-ID: <59548.7588.qm@web52101.mail.re2.yahoo.com>


Well, they're already being documented separately (see, e.g., http://docs.scipy.org/numpy/Milestones/#ndarray-ii-status-63-done-leader-your-name-here, under which several data attributes are listed as needing documentation, independent of the separate listing of numpy.ndarray under http://docs.scipy.org/numpy/Milestones/#ndarray-ii-status-63-done-leader-your-name-here).

DG

--- On Thu, 6/25/09, Robert Kern <robert.kern at gmail.com> wrote:

> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-dev] Documenting data attributes
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Thursday, June 25, 2009, 1:55 PM
> On Thu, Jun 25, 2009 at 15:49, David
> Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > Hi! ?For the purposes of meeting the documentation
> standard, are data attributes regarded has "returning"
> something, i.e., should ndarray.itemsize, for example, have
> a Returns section?
> 
> I would describe them in an Attributes section of the
> class's
> docstring. See MachAr for an example I did some time ago.
> 
> ? http://docs.scipy.org/numpy/docs/numpy.lib.machar.MachAr/
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Thu Jun 25 17:14:45 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 25 Jun 2009 14:14:45 -0700 (PDT)
Subject: [SciPy-dev] Summer Marathon: targeting a category per week
Message-ID: <7264.45252.qm@web52103.mail.re2.yahoo.com>


OK, we have a couple nominees already: polynomials, or "one of the masked array ones."  I'm partial to polynomials myself; anyone else want to opine?

DG

--- On Thu, 6/25/09, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:

> From: David Goldsmith <d_l_goldsmith at yahoo.com>
> Subject: [SciPy-dev] Summer Marathon: targeting a category per week
> To: scipy-dev at scipy.org
> Date: Thursday, June 25, 2009, 1:39 PM
> 
> Hi, folks!? So, one of the ideas that came out of last
> week's Skypecon for increasing participation in the Marathon
> is to pick a category each week to target for "completion"
> (meaning Marathon goal met = getting every function to at
> least the "needs first review" stage) by the following
> week's Skypecon.? No one nominated any categories last
> week, but I'm not giving up that easily ;-).? I hereby
> call for suggestions for a target category for this week
> (i.e., to be completed by next Wed. July 1) but if I don't
> receive any by tomorrow morning my time (UTC-7), I'll just
> choose. :-)? Thanks!
> 
> DG
> 
> 
> ? ? ? 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From robert.kern at gmail.com  Thu Jun 25 17:41:24 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Jun 2009 16:41:24 -0500
Subject: [SciPy-dev] Documenting data attributes
In-Reply-To: <59548.7588.qm@web52101.mail.re2.yahoo.com>
References: <59548.7588.qm@web52101.mail.re2.yahoo.com>
Message-ID: <3d375d730906251441sb4b9299n4f0bfc0bcf9bb768@mail.gmail.com>

On Thu, Jun 25, 2009 at 16:10, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> Well, they're already being documented separately (see, e.g., http://docs.scipy.org/numpy/Milestones/#ndarray-ii-status-63-done-leader-your-name-here, under which several data attributes are listed as needing documentation, independent of the separate listing of numpy.ndarray under http://docs.scipy.org/numpy/Milestones/#ndarray-ii-status-63-done-leader-your-name-here).

Then, no.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From ralf.gommers at googlemail.com  Fri Jun 26 00:45:45 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 26 Jun 2009 00:45:45 -0400
Subject: [SciPy-dev] Documenting data attributes
In-Reply-To: <3d375d730906251355v73a3b5b4o822bb62ba77913a7@mail.gmail.com>
References: <539406.59181.qm@web52104.mail.re2.yahoo.com>
	<3d375d730906251355v73a3b5b4o822bb62ba77913a7@mail.gmail.com>
Message-ID: <dde7764a0906252145q333e3addq5be08a8766abad94@mail.gmail.com>

On Thu, Jun 25, 2009 at 4:55 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, Jun 25, 2009 at 15:49, David Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > Hi!  For the purposes of meeting the documentation standard, are data
> attributes regarded has "returning" something, i.e., should
> ndarray.itemsize, for example, have a Returns section?
>
> I would describe them in an Attributes section of the class's
> docstring. See MachAr for an example I did some time ago.
>
>  http://docs.scipy.org/numpy/docs/numpy.lib.machar.MachAr/
>

Robert, that docstring references Numerical Recipes in C++, is that okay? Is
it just Numerical Recipes in C that has license issues or the whole series?

>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090626/3bbad313/attachment.html>

From robert.kern at gmail.com  Fri Jun 26 00:53:18 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Jun 2009 23:53:18 -0500
Subject: [SciPy-dev] Documenting data attributes
In-Reply-To: <dde7764a0906252145q333e3addq5be08a8766abad94@mail.gmail.com>
References: <539406.59181.qm@web52104.mail.re2.yahoo.com>
	<3d375d730906251355v73a3b5b4o822bb62ba77913a7@mail.gmail.com> 
	<dde7764a0906252145q333e3addq5be08a8766abad94@mail.gmail.com>
Message-ID: <3d375d730906252153p3c8ca173j8afc77cb4e78a3c0@mail.gmail.com>

On Thu, Jun 25, 2009 at 23:45, Ralf Gommers<ralf.gommers at googlemail.com> wrote:
>
>
> On Thu, Jun 25, 2009 at 4:55 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Thu, Jun 25, 2009 at 15:49, David Goldsmith<d_l_goldsmith at yahoo.com>
>> wrote:
>> >
>> > Hi! ?For the purposes of meeting the documentation standard, are data
>> > attributes regarded has "returning" something, i.e., should
>> > ndarray.itemsize, for example, have a Returns section?
>>
>> I would describe them in an Attributes section of the class's
>> docstring. See MachAr for an example I did some time ago.
>>
>> ?http://docs.scipy.org/numpy/docs/numpy.lib.machar.MachAr/
>
> Robert, that docstring references Numerical Recipes in C++, is that okay? Is
> it just Numerical Recipes in C that has license issues or the whole series?

A reference does not mean that we have copied code.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Fri Jun 26 12:52:31 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Fri, 26 Jun 2009 09:52:31 -0700 (PDT)
Subject: [SciPy-dev] Definition of class multiarray
Message-ID: <177588.58999.qm@web52104.mail.re2.yahoo.com>


Hi.  Where is class multiarray defined?  Thanks!

DG


      


From pav at iki.fi  Fri Jun 26 14:13:22 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 26 Jun 2009 18:13:22 +0000 (UTC)
Subject: [SciPy-dev] Definition of class multiarray
References: <177588.58999.qm@web52104.mail.re2.yahoo.com>
Message-ID: <h23342$8vp$1@ger.gmane.org>

On 2009-06-26, David Goldsmith <d_l_goldsmith at yahoo.com> wrote:
> Hi.  Where is class multiarray defined?  Thanks!

There's no class named multiarray. numpy.core.multiarray is an 
extension module written in C, providing eg. the ndarray class.

You can find the sources under numpy/core/src

-- 
Pauli Virtanen



From d_l_goldsmith at yahoo.com  Fri Jun 26 14:45:10 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Fri, 26 Jun 2009 11:45:10 -0700 (PDT)
Subject: [SciPy-dev] Definition of class multiarray
Message-ID: <111590.36894.qm@web52106.mail.re2.yahoo.com>


OK, tried to figure it out myself, but:

Do ndarray.<method>s which have an "equivalent" numpy.<method> actually call the numpy method to operate on self?

DG

--- On Fri, 6/26/09, Pauli Virtanen <pav at iki.fi> wrote:

> From: Pauli Virtanen <pav at iki.fi>
> Subject: Re: [SciPy-dev] Definition of class multiarray
> To: scipy-dev at scipy.org
> Date: Friday, June 26, 2009, 11:13 AM
> On 2009-06-26, David Goldsmith <d_l_goldsmith at yahoo.com>
> wrote:
> > Hi.? Where is class multiarray defined??
> Thanks!
> 
> There's no class named multiarray. numpy.core.multiarray is
> an 
> extension module written in C, providing eg. the ndarray
> class.
> 
> You can find the sources under numpy/core/src
> 
> -- 
> Pauli Virtanen
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From pgmdevlist at gmail.com  Fri Jun 26 15:24:46 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Fri, 26 Jun 2009 15:24:46 -0400
Subject: [SciPy-dev] Documenting Warnings
Message-ID: <95741555-0617-489A-B651-4BFCC707DFE0@gmail.com>

All,
How do we document a warning, a note that should be displayed  
differently as a note ? Don't we have a "Warnings" entry in the  
docstrings standard ?
Thx


From robert.kern at gmail.com  Fri Jun 26 15:30:47 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 26 Jun 2009 14:30:47 -0500
Subject: [SciPy-dev] Definition of class multiarray
In-Reply-To: <111590.36894.qm@web52106.mail.re2.yahoo.com>
References: <111590.36894.qm@web52106.mail.re2.yahoo.com>
Message-ID: <3d375d730906261230h727a5f4ew707df4b236e6e674@mail.gmail.com>

On Fri, Jun 26, 2009 at 13:45, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> OK, tried to figure it out myself, but:
>
> Do ndarray.<method>s which have an "equivalent" numpy.<method> actually call the numpy method to operate on self?

Note that the latter are called functions, not methods. Where there is
an equivalence, the function calls the method, not vice versa. Take a
look at the source of numpy.std, for instance.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Fri Jun 26 16:28:20 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Fri, 26 Jun 2009 13:28:20 -0700 (PDT)
Subject: [SciPy-dev] Definition of class multiarray
Message-ID: <310902.44571.qm@web52109.mail.re2.yahoo.com>


--- On Fri, 6/26/09, Robert Kern <robert.kern at gmail.com> wrote:

> Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >
> > OK, tried to figure it out myself, but:
> >
> > Do ndarray.<method>s which have an "equivalent"
> numpy.<method> actually call the numpy method to
> operate on self?
> 
> Note that the latter are called functions, not methods.

Sorry, of course, my bad.

> Where there is
> an equivalence, the function calls the method, not vice
> versa. Take a
> look at the source of numpy.std, for instance.

Interesting; why? Because presently we're doing the doc the other way: if someone does help(ndarray.<method>) (and there's an equivalent numpy function) they're referred to the function for (detailed) help. :-)  Granted, this "reversal" probably doesn't matter since which is calling which isn't typically seen by the user, but I just thought I'd note it in case anyone has a problem with it (and thus wants to discuss it further).

DG

> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
> ? -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From robert.kern at gmail.com  Fri Jun 26 16:30:53 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 26 Jun 2009 15:30:53 -0500
Subject: [SciPy-dev] Definition of class multiarray
In-Reply-To: <310902.44571.qm@web52109.mail.re2.yahoo.com>
References: <310902.44571.qm@web52109.mail.re2.yahoo.com>
Message-ID: <3d375d730906261330u7e59fe7dmcd5a185fe2b72023@mail.gmail.com>

On Fri, Jun 26, 2009 at 15:28, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> --- On Fri, 6/26/09, Robert Kern <robert.kern at gmail.com> wrote:
>
>> Goldsmith<d_l_goldsmith at yahoo.com>
>> wrote:
>> >
>> > OK, tried to figure it out myself, but:
>> >
>> > Do ndarray.<method>s which have an "equivalent"
>> numpy.<method> actually call the numpy method to
>> operate on self?
>>
>> Note that the latter are called functions, not methods.
>
> Sorry, of course, my bad.
>
>> Where there is
>> an equivalence, the function calls the method, not vice
>> versa. Take a
>> look at the source of numpy.std, for instance.
>
> Interesting; why?

It's much easier to implement that way.

> Because presently we're doing the doc the other way: if someone does help(ndarray.<method>) (and there's an equivalent numpy function) they're referred to the function for (detailed) help. :-) ?Granted, this "reversal" probably doesn't matter since which is calling which isn't typically seen by the user, but I just thought I'd note it in case anyone has a problem with it (and thus wants to discuss it further).

It really doesn't matter.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d_l_goldsmith at yahoo.com  Fri Jun 26 16:32:35 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Fri, 26 Jun 2009 13:32:35 -0700 (PDT)
Subject: [SciPy-dev] Marathon category of the week...
Message-ID: <896987.57703.qm@web52101.mail.re2.yahoo.com>


And the winner is...polynomials!  I'll make a note on the Milestones page.  Feel free to add yourself either as a leader or a helper if you like (though you don't need to do so, to participate, obviously).  Again, the idea is that this will motivate us to "finish" this category by next Wednesday's Skypecon.  Happy doc-ing! :-)

DG


      


From ralf.gommers at googlemail.com  Fri Jun 26 16:48:00 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 26 Jun 2009 16:48:00 -0400
Subject: [SciPy-dev] Documenting Warnings
In-Reply-To: <95741555-0617-489A-B651-4BFCC707DFE0@gmail.com>
References: <95741555-0617-489A-B651-4BFCC707DFE0@gmail.com>
Message-ID: <dde7764a0906261348x4268deb7o51ca058871da6045@mail.gmail.com>

On Fri, Jun 26, 2009 at 3:24 PM, Pierre GM <pgmdevlist at gmail.com> wrote:

> All,
> How do we document a warning, a note that should be displayed
> differently as a note ? Don't we have a "Warnings" entry in the
> docstrings standard ?
> Thx


For longer reST doc files you can use (see for example
http://docs.scipy.org/numpy/docs/numpy-docs/user/index.rst/):

*.. warning::

  Description.

*There is no Warnings heading in the docstring standard. Why can't you put
it either under Notes or under Raises? And special reST markup like the
above is discouraged in docstrings because it looks bad on text terminals.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090626/1c15ce73/attachment.html>

From pgmdevlist at gmail.com  Fri Jun 26 17:03:08 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Fri, 26 Jun 2009 17:03:08 -0400
Subject: [SciPy-dev] Documenting Warnings
In-Reply-To: <dde7764a0906261348x4268deb7o51ca058871da6045@mail.gmail.com>
References: <95741555-0617-489A-B651-4BFCC707DFE0@gmail.com>
	<dde7764a0906261348x4268deb7o51ca058871da6045@mail.gmail.com>
Message-ID: <C4E2ABCB-D156-4ABE-8AA3-5B2B9C0D0A09@gmail.com>


On Jun 26, 2009, at 4:48 PM, Ralf Gommers wrote:

>
>
> On Fri, Jun 26, 2009 at 3:24 PM, Pierre GM <pgmdevlist at gmail.com>  
> wrote:
> All,
> How do we document a warning, a note that should be displayed
> differently as a note ? Don't we have a "Warnings" entry in the
> docstrings standard ?
> Thx
>

> For longer reST doc files you can use (see for example http://docs.scipy.org/numpy/docs/numpy-docs/user/index.rst/) 
> :
>
> .. warning::
>
>   Description.

Meh. Not the best as you pointed out.


> There is no Warnings heading in the docstring standard.

I've noticed that and regret it.

> Why can't you put it either under Notes or under Raises?

Because you may want to stress one particular aspect that would  
otherwise be easy to overlook in a Notes. Because you want to describe  
a known limitation that doesn't raise any exception (and maybe not  
even a warning per se: in that case, I'd put in the Raises section as  
you suggest).

[FYI, I was just checking recent updates in the docstrings of numpy.ma  
and noticed that Pauli got rid of the Warnings section and merged it  
in a Notes. I still think that the two sections shouldn't have been  
merged, but I won't lose sleep over it. I'm just curious).


> And special reST markup like the above is discouraged in docstrings  
> because it looks bad on text terminals.

So why don't we have a Warning entry in the docsring standard ? Pauli,  
what are your thoughts about that ? I know for a fact that it'd be  
quite easy to implement. Any strong reason against that ?



From d_l_goldsmith at yahoo.com  Fri Jun 26 18:21:52 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Fri, 26 Jun 2009 15:21:52 -0700 (PDT)
Subject: [SciPy-dev] Documenting Warnings
Message-ID: <146812.79232.qm@web52108.mail.re2.yahoo.com>


Personally, I think under Notes - with suitable emphasis, e.g., bracketed w/ double *'s, i.e., **Warning:** - would suffice.  However, if it did exist in the standard and was removed, perhaps a summary of why could be added to the FAQ.

DG

--- On Fri, 6/26/09, Pierre GM <pgmdevlist at gmail.com> wrote:

> From: Pierre GM <pgmdevlist at gmail.com>
> Subject: Re: [SciPy-dev] Documenting Warnings
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Friday, June 26, 2009, 2:03 PM
> 
> On Jun 26, 2009, at 4:48 PM, Ralf Gommers wrote:
> 
> >
> >
> > On Fri, Jun 26, 2009 at 3:24 PM, Pierre GM <pgmdevlist at gmail.com>?
> 
> > wrote:
> > All,
> > How do we document a warning, a note that should be
> displayed
> > differently as a note ? Don't we have a "Warnings"
> entry in the
> > docstrings standard ?
> > Thx
> >
> 
> > For longer reST doc files you can use (see for example
> http://docs.scipy.org/numpy/docs/numpy-docs/user/index.rst/)
> 
> > :
> >
> > .. warning::
> >
> >???Description.
> 
> Meh. Not the best as you pointed out.
> 
> 
> > There is no Warnings heading in the docstring
> standard.
> 
> I've noticed that and regret it.
> 
> > Why can't you put it either under Notes or under
> Raises?
> 
> Because you may want to stress one particular aspect that
> would? 
> otherwise be easy to overlook in a Notes. Because you want
> to describe? 
> a known limitation that doesn't raise any exception (and
> maybe not? 
> even a warning per se: in that case, I'd put in the Raises
> section as? 
> you suggest).
> 
> [FYI, I was just checking recent updates in the docstrings
> of numpy.ma? 
> and noticed that Pauli got rid of the Warnings section and
> merged it? 
> in a Notes. I still think that the two sections shouldn't
> have been? 
> merged, but I won't lose sleep over it. I'm just curious).
> 
> 
> > And special reST markup like the above is discouraged
> in docstrings? 
> > because it looks bad on text terminals.
> 
> So why don't we have a Warning entry in the docsring
> standard ? Pauli,? 
> what are your thoughts about that ? I know for a fact that
> it'd be? 
> quite easy to implement. Any strong reason against that ?
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From gael.varoquaux at normalesup.org  Fri Jun 26 18:23:40 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 27 Jun 2009 00:23:40 +0200
Subject: [SciPy-dev] Documenting Warnings
In-Reply-To: <146812.79232.qm@web52108.mail.re2.yahoo.com>
References: <146812.79232.qm@web52108.mail.re2.yahoo.com>
Message-ID: <20090626222340.GF20661@phare.normalesup.org>

On Fri, Jun 26, 2009 at 03:21:52PM -0700, David Goldsmith wrote:

> Personally, I think under Notes - with suitable emphasis, e.g., bracketed w/ double *'s, i.e., **Warning:** - would suffice.  However, if it did exist in the standard and was removed, perhaps a summary of why could be added to the FAQ.

I would say: under Notes, using sphinx standard:

.. warning::

    ...

But I haven't check it works with our rendering pipeline.

Ga?l


From pgmdevlist at gmail.com  Fri Jun 26 19:11:47 2009
From: pgmdevlist at gmail.com (Pierre GM)
Date: Fri, 26 Jun 2009 19:11:47 -0400
Subject: [SciPy-dev] Documenting Warnings
In-Reply-To: <146812.79232.qm@web52108.mail.re2.yahoo.com>
References: <146812.79232.qm@web52108.mail.re2.yahoo.com>
Message-ID: <21692594-2570-404D-B885-EC6EA7220479@gmail.com>


On Jun 26, 2009, at 6:21 PM, David Goldsmith wrote:

>
> Personally, I think under Notes - with suitable emphasis, e.g.,  
> bracketed w/ double *'s, i.e., **Warning:** - would suffice.   
> However, if it did exist in the standard and was removed, perhaps a  
> summary of why could be added to the FAQ.

The **...** method is not as good as a warning directive which  
displayed with a special template.
Using a ..warning directive inside a 'Notes' might break things in  
numpydoc.
There's already a _str_warnings in SphinxDocString, that transforms a  
"Warnings" section into a ..warning directive, why can't we use that ?



From gael.varoquaux at normalesup.org  Sat Jun 27 03:09:34 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 27 Jun 2009 09:09:34 +0200
Subject: [SciPy-dev] SciPy abstract submission deadline extended
Message-ID: <20090627070934.GA6149@phare.normalesup.org>

Greetings,

The conference committee is extending the deadline for abstract
submission for the Scipy conference 2009 one week. 

On Friday July 3th, at midnight Pacific, we will turn off the abstract
submission on the conference site. Up to then, you can modify the
already-submitted abstract, or submit new abstracts.

Submitting Papers
---------------------

The program features tutorials, contributed papers, lightning talks, and
bird-of-a-feather sessions. We are soliciting talks and accompanying
papers (either formal academic or magazine-style articles) that discuss
topics which center around scientific computing using Python. These
include applications, teaching, future development directions, and
research. A collection of peer-reviewed articles will be published as
part of the proceedings.

Proposals for talks are submitted as extended abstracts. There are two
categories of talks:

    Paper presentations

        These talks are 35 minutes in duration (including questions). A
one page abstract of no less than 500 words (excluding figures and
references) should give an outline of the final paper. Proceeding papers
are due two weeks after the conference, and may be in a formal academic
style, or in a more relaxed magazine-style format.

    Rapid presentations

        These talks are 10 minutes in duration. An abstract of between
300 and 700 words should describe the topic and motivate its relevance to
scientific computing.

In addition, there will be an open session for lightning talks during
which any attendee willing to do so is invited to do a
couple-of-minutes-long presentation.

If you wish to present a talk at the conference, please create an account
on the website (http://conference.scipy.org). You may then submit an
abstract by logging in, clicking on your profile and following the
"Submit an abstract" link.


Submission Guidelines

    * Submissions should be uploaded via the online form.
    * Submissions whose main purpose is to promote a commercial product
      or service will be refused.
    * All accepted proposals must be presented at the SciPy conference by
      at least one author.
    * Authors of an accepted proposal can provide a final paper for
      publication in the conference proceedings. Final papers are limited
      to 7 pages, including diagrams, figures, references, and
      appendices. The papers will be reviewed to help ensure the
      high-quality of the proceedings.

For further information, please visit the conference homepage:
http://conference.scipy.org.


The SciPy 2009 executive committee
-----------------------------------

 * Jarrod Millman, UC Berkeley, USA (Conference Chair)
 * Ga?l Varoquaux, INRIA Saclay, France (Program Co-Chair)
 * St?fan van der Walt, University of Stellenbosch, South Africa (Program Co-Chair)
 * Fernando P?rez, UC Berkeley, USA (Tutorial Chair)




From scott.sinclair.za at gmail.com  Sat Jun 27 03:50:36 2009
From: scott.sinclair.za at gmail.com (Scott Sinclair)
Date: Sat, 27 Jun 2009 09:50:36 +0200
Subject: [SciPy-dev] Documenting Warnings
In-Reply-To: <C4E2ABCB-D156-4ABE-8AA3-5B2B9C0D0A09@gmail.com>
References: <95741555-0617-489A-B651-4BFCC707DFE0@gmail.com>
	<dde7764a0906261348x4268deb7o51ca058871da6045@mail.gmail.com>
	<C4E2ABCB-D156-4ABE-8AA3-5B2B9C0D0A09@gmail.com>
Message-ID: <6a17e9ee0906270050h5a5dc327m498abe7854cf7602@mail.gmail.com>

>2009/6/26 Pierre GM <pgmdevlist at gmail.com>:
>
>> On Jun 26, 2009, at 4:48 PM, Ralf Gommers wrote:
>
>> Why can't you put it either under Notes or under Raises?
>
> Because you may want to stress one particular aspect that would
> otherwise be easy to overlook in a Notes. Because you want to describe
> a known limitation that doesn't raise any exception (and maybe not
> even a warning per se: in that case, I'd put in the Raises section as
> you suggest).
>
> [FYI, I was just checking recent updates in the docstrings of numpy.ma
> and noticed that Pauli got rid of the Warnings section and merged it
> in a Notes. I still think that the two sections shouldn't have been
> merged, but I won't lose sleep over it. I'm just curious).

I'm also guilty of mangling your docstrings in this way, so that
they'd match the standard. Including an optional warnings section in
the standard sounds like a good idea to me..

Cheers,
Scott


From ralf.gommers at googlemail.com  Sat Jun 27 11:53:52 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 27 Jun 2009 11:53:52 -0400
Subject: [SciPy-dev] Documenting Warnings
In-Reply-To: <21692594-2570-404D-B885-EC6EA7220479@gmail.com>
References: <146812.79232.qm@web52108.mail.re2.yahoo.com>
	<21692594-2570-404D-B885-EC6EA7220479@gmail.com>
Message-ID: <dde7764a0906270853g4e48ce4bs47d308ab197b14ec@mail.gmail.com>

On Fri, Jun 26, 2009 at 7:11 PM, Pierre GM <pgmdevlist at gmail.com> wrote:

>
> On Jun 26, 2009, at 6:21 PM, David Goldsmith wrote:
>
> >
> > Personally, I think under Notes - with suitable emphasis, e.g.,
> > bracketed w/ double *'s, i.e., **Warning:** - would suffice.
> > However, if it did exist in the standard and was removed, perhaps a
> > summary of why could be added to the FAQ.
>
> The **...** method is not as good as a warning directive which
> displayed with a special template.


agreed

>
> Using a ..warning directive inside a 'Notes' might break things in
> numpydoc.
> There's already a _str_warnings in SphinxDocString, that transforms a
> "Warnings" section into a ..warning directive, why can't we use that ?
>

 I looked in the ma module, the first example I found is
http://docs.scipy.org/numpy/docs/numpy.ma.core.MaskedArray.cumsum
The first line of Notes there does not need a big red box drawn around it,
and be the standout visual element on the whole page. It's fine as a note
saying: "pass in the wrong type --> something unexpected will happen".

Some more thoughts:
- if there are big red boxes on a lot of pages, a new user might think that
NumPy is hard to use or beta quality.
- all sections now have quite distinct purposes, while the line between
Notes and Warnings is blurry. This will make the docs less uniform.
- if you strongly feel something needs a big red box in a one-page
docstring, you probably should raise an error after all.

Can you give some examples where you think having warnings would really
improve things?

Cheers,
Ralf


> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090627/540ed0b2/attachment.html>

From pav at iki.fi  Sat Jun 27 13:18:34 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 27 Jun 2009 17:18:34 +0000 (UTC)
Subject: [SciPy-dev] Documenting Warnings
References: <146812.79232.qm@web52108.mail.re2.yahoo.com>
	<21692594-2570-404D-B885-EC6EA7220479@gmail.com>
	<dde7764a0906270853g4e48ce4bs47d308ab197b14ec@mail.gmail.com>
Message-ID: <h25k9a$nk1$1@ger.gmane.org>

On 2009-06-27, Ralf Gommers <ralf.gommers at googlemail.com> wrote:
[clip]
> Some more thoughts:
> - if there are big red boxes on a lot of pages, a new user might think that
> NumPy is hard to use or beta quality.
> - all sections now have quite distinct purposes, while the line between
> Notes and Warnings is blurry. This will make the docs less uniform.
> - if you strongly feel something needs a big red box in a one-page
> docstring, you probably should raise an error after all.

Some comments on this discussion: the warning:: directive will of 
course work without problems in all cases. The same goes for 
note:: and the other admonitions. I also don't think they look 
bad enough in text form to be avoided.

I do not see a real need for a separate "Warnings" section. 
Typically, warnings are some points that you want to emphasize 
about something. I think these are better raised in vicinity of 
the context of the warning. If you want visual standouts, I think 
using the warning:: or note:: directives is appropriate.

Also, the boundary between a warning as opposed to an ordinary 
note is a bit blurry here.

For example:

	...

	Parameters
	----------
	spam : ham_type
	    Type of spam preferred.

	    .. warning:: Giving `Ni` as `spam` will result
                         to a permanent loss of cheese.

	...

is IMHO more appropriate than

	...

	Parameters
	----------
	spam : ham_type
	    Type of spam preferred.

	...

	Warnings
	--------
	Giving `Ni` as `spam` may result to a permanent loss of 
	cheese.

	...

-- 
Pauli Virtanen



From millman at berkeley.edu  Mon Jun 29 02:59:59 2009
From: millman at berkeley.edu (Jarrod Millman)
Date: Sun, 28 Jun 2009 23:59:59 -0700
Subject: [SciPy-dev] ANN: SciPy 2009 student sponsorship
Message-ID: <c7009a550906282359x68015894lf094807468bf7dec@mail.gmail.com>

I am pleased to announce that the Python Software Foundation is
sponsoring 10 students' travel, registration, and accommodation for
the SciPy 2009 conference (Aug. 18-23).  The focus of the conference
is both on scientific libraries and tools developed with Python and on
scientific or engineering achievements using Python.  If you're in
college or a graduate program, please check out the details here:
http://conference.scipy.org/student-funding

About the conference
--------------------

SciPy 2009, the 8th Python in Science conference, will be held from
August 18-23, 2009 at Caltech in Pasadena, CA, USA.  The conference
starts with two days of tutorials to the scientific Python tools.
There will be two tracks, one for introduction of the basic tools to
beginners, and one for more advanced tools.  The tutorials will be
followed by two days of talks.  Both days of talks will begin with a
keynote address.  The first day?s keynote will be given by Peter
Norvig, the Director of Research at Google; while, the second keynote
will be delivered by Jon Guyer, a Materials Scientist in the
Thermodynamics and Kinetics Group at NIST.  The program committee will
select the remaining talks from submissions to our call for papers.
All selected talks will be included in our conference proceedings
edited by the program committee.  After the talks each day we will
provide several rooms for impromptu birds of a feather discussions.
Finally, the last two days of the conference will be used for a number
of coding sprints on the major software projects in our community.

For the 8th consecutive year, the conference will bring together the
developers and users of the open source software stack for scientific
computing with Python.  Attendees have the opportunity to review the
available tools and how they apply to specific problems.  By providing
a forum for developers to share their Python expertise with the wider
commercial, academic, and research communities, this conference
fosters collaboration and facilitates the sharing of software
components, techniques, and a vision for high level language use in
scientific computing.

For further information, please visit the conference homepage:
http://conference.scipy.org.

Important Dates
---------------

* Friday, July 3: Abstracts Due
* Friday, July 10: Announce accepted talks, post schedule
* Friday, July 10: Early Registration ends
* Tuesday-Wednesday, August 18-19: Tutorials
* Thursday-Friday, August 20-21: Conference
* Saturday-Sunday, August 22-23: Sprints
* Friday, September 4: Papers for proceedings due

Executive Committee
-------------------

* Jarrod Millman, UC Berkeley, USA (Conference Chair)
* Ga?l Varoquaux, INRIA Saclay, France (Program Co-Chair)
* St?fan van der Walt, University of Stellenbosch, South Africa
(Program Co-Chair)
* Fernando P?rez, UC Berkeley, USA (Tutorial Chair)


From dsdale24 at gmail.com  Mon Jun 29 08:56:18 2009
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 29 Jun 2009 08:56:18 -0400
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened up
	for registration
In-Reply-To: <20090621235540.GB14395@phare.normalesup.org>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
	<20090621235540.GB14395@phare.normalesup.org>
Message-ID: <a08e5f80906290556g17d86daemf67f23468856837a@mail.gmail.com>

On Sun, Jun 21, 2009 at 7:55 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Sun, Jun 21, 2009 at 05:20:08PM -0600, Ondrej Certik wrote:
> > On Fri, Jun 19, 2009 at 8:01 AM, Gael
> > Varoquaux<gael.varoquaux at normalesup.org> wrote:
> > > We are finally opening the registration for the SciPy 2009 conference.
> It
> > > took us time, but the reason is that we made careful budget estimations
> > > to bring the registration cost down.
>
> > > We are very happy to announce that this year registration to the
> > > conference will be only $150, sprints $100, and students get half
> price!
> > > We made this effort because we hope it will open up the conference to
> > > more people, especially students that often have to finance this trip
> > > with little budget. As a consequence, however, catering at noon is not
> > > included.
>
> > One more question -- how can I actually register for the conference? I
> went to:
>
> > http://conference.scipy.org/
>
> > registered and sent the abstract (some time ago already). So today I
> > logged in and clicked "registration":
>
> > http://conference.scipy.org/to_register
>
> > which says "To register to the conference, create an account on this
> > site and log in. Go to your profile page, you can submit an abstract
> > or register to the conference.", so I clicked on my profile page:
>
> > http://conference.scipy.org/profile
>
> > which shows my abstract, but it says "The conference is not yet open
> > for registration.". So how can I pay the conference fees and register?
>
> Well, well. Looks like I did things too quickly, or too jet-lagged. I
> had forgotten to pull the setting on the server. That's why we where not
> observing any registration. Thank you for signaling it, I wonder how many
> people had tried and failed.
>

I logged in this morning to see about submitting an abstract, and I see the
following:

"Couldn't connect to registration server. We cannot display your
registration information"

Below that there are links for changing personal information, registering
for the conference, and submitting an abstract, but it is not clear that I
should proceed if the registration server is unreachable. Can anyone
confirm?

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090629/5776fed1/attachment.html>

From gael.varoquaux at normalesup.org  Mon Jun 29 10:35:53 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 29 Jun 2009 16:35:53 +0200
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened	up
	for registration
In-Reply-To: <a08e5f80906290556g17d86daemf67f23468856837a@mail.gmail.com>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
	<20090621235540.GB14395@phare.normalesup.org>
	<a08e5f80906290556g17d86daemf67f23468856837a@mail.gmail.com>
Message-ID: <20090629143553.GA16691@phare.normalesup.org>

On Mon, Jun 29, 2009 at 08:56:18AM -0400, Darren Dale wrote:
>    I logged in this morning to see about submitting an abstract, and I see
>    the following:

>    "Couldn't connect to registration server. We cannot display your
>    registration information"

>    Below that there are links for changing personal information, registering
>    for the conference, and submitting an abstract, but it is not clear that I
>    should proceed if the registration server is unreachable. Can anyone
>    confirm?

Thanks for reporting. It should be fixed: an http link had change to an
https link.

Ga?l


From d_l_goldsmith at yahoo.com  Mon Jun 29 16:28:29 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 29 Jun 2009 13:28:29 -0700 (PDT)
Subject: [SciPy-dev] Last week's Skypecon Minutes and request
Message-ID: <603512.89632.qm@web52106.mail.re2.yahoo.com>


Hi, all.  Below are the Minutes of last week's Summer Marathon Weekly Skypecon.  Before that, you'll note in them that the participants decided to fix the Skypecon time to Wednesday's, 19:00 UTC.  Well, I already need to request a "variance" for Wed. July 15 - anyone object strongly to Tuesday July 14, 18:00 UTC that week?  Thanks!

DG

PS: Note that that's three Weds. from now - the next two, July 1 and July 8, the Skypecon will be at the designated time, 19:00 UTC; please email me any items you'd like to see on the agenda.  And now, without further ado, I give you... the Minutes!


Numpy Doc Summer '09 Marathon
June 24, 2009 Skypecon Minutes

Start: 19:00 UTC
End: 20:00 UTC

Present:
David Goldsmith, Secretary
Stefan van der Walt
Ralf Gommers
Pauli Virtanen

Discussions:

0) Clarifying the Doc Standard vis-?-vis classes and their constructors, attributes, instances (created by numpy), and constants

    Agreed that, for now at least, c-tors will be documented in the class docstring

    Agreed that, because we might want to group attributes into meaningful categories within their class, we?ll stick with manual generation and annotation of such lists of attributes

    Instances: Pauli explained how things work ?behind the scenes,? and it was decided that the way it's currently done is okay. For what that way is, see patch attached to ticket #1146, http://projects.scipy.org/numpy/ticket/1146

    Constants: At first, said it?s moot because we can?t easily modify constants? docstrings, but then Pauli pointed out that the development version of NumPy has the subpackage numpy.doc.constants, wherein constants can be documented at module scope.  Did not settle on exactly how it should look but were in agreement that it should be a) kept short, and b) use the same sections as for functions where applicable.

1) Two "pre-proof" reviews: technical (?Is it correct??) and presentation (?Is it clear and as simple as possible, modulo being correct??)

    Note: the presentation issue is seen as distinct from whether or not the docstring is grammatically correct and free of typos, these latter to be assured by the final proof

    Discussed the ?pros? (our labor pool, in general, consists of persons who are stronger in one area or the other, but not both; dividing the review process in this way makes it more manageable and thus less intimidating for prospective reviewers) and ?cons? (compounding and complicating the overall process in this way will just push back completion that much further); decided that the pros outweigh the cons, and thus this division should be added to the review process, but, recognizing that these reviews are beyond the stated goal of the Summer Marathon, decided that required changes to the Wiki can be designated as ?medium? priority.

    It came up after the meeting that there is still confusion about the meaning of the proposal, and that if the ?non-technical? review is as described above, then at least one meeting participants opted to change his ?vote,? resulting in a ?tie? regarding ?endorsement? of the proposal;  we await clarification from the proposer regarding his intended meaning.

2) Adding a FAQ page to the Wiki

    Discussed how recent questions/issues arising on the mailing list and in the Comments sections of the Wiki demonstrate the need for the Wiki to have something like a FAQ page.

    Pauli agreed to create a ?mock-up? for dissemination and discussion, which he has already completed and published at http://docs.scipy.org/numpy/Questions+Answers/

3) Meeting time

    Decided that 19:00 UTC Wednesdays is a good time, and that, all else equal, it's probably better to fix the time than have it "float."  Consequently, next Summer Marathon Skypecon is scheduled for:

    Wednesday, July 1, 19:00 UTC

Notes:

    Ralf noted an inconsistency on the Milestones page between the Goal statement and the color scheme, which the Secretary has corrected

    Again, had periodic dropout problems all around.




      


From ondrej at certik.cz  Tue Jun 30 00:23:04 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 29 Jun 2009 22:23:04 -0600
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened up
	for registration
In-Reply-To: <20090629143553.GA16691@phare.normalesup.org>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
	<20090621235540.GB14395@phare.normalesup.org>
	<a08e5f80906290556g17d86daemf67f23468856837a@mail.gmail.com>
	<20090629143553.GA16691@phare.normalesup.org>
Message-ID: <85b5c3130906292123v5b708707s32c483a89e2d8859@mail.gmail.com>

On Mon, Jun 29, 2009 at 8:35 AM, Gael
Varoquaux<gael.varoquaux at normalesup.org> wrote:
> On Mon, Jun 29, 2009 at 08:56:18AM -0400, Darren Dale wrote:
>> ? ?I logged in this morning to see about submitting an abstract, and I see
>> ? ?the following:
>
>> ? ?"Couldn't connect to registration server. We cannot display your
>> ? ?registration information"
>
>> ? ?Below that there are links for changing personal information, registering
>> ? ?for the conference, and submitting an abstract, but it is not clear that I
>> ? ?should proceed if the registration server is unreachable. Can anyone
>> ? ?confirm?
>
> Thanks for reporting. It should be fixed: an http link had change to an
> https link.

I get an annoying warning in firefox that the security certificate for
paying is invalid (only valid for "www.enthought.com", notice the
"www"). Here is the address:

https://enthought.com/scipy09/?email=ondrej at certik.cz

however, if I change the address manually to:

https://www.enthought.com/scipy09/?email=ondrej at certik.cz

then it just works.

Ondrej


From gael.varoquaux at normalesup.org  Tue Jun 30 01:26:19 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 30 Jun 2009 07:26:19 +0200
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened	up
	for registration
In-Reply-To: <85b5c3130906292123v5b708707s32c483a89e2d8859@mail.gmail.com>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
	<20090621235540.GB14395@phare.normalesup.org>
	<a08e5f80906290556g17d86daemf67f23468856837a@mail.gmail.com>
	<20090629143553.GA16691@phare.normalesup.org>
	<85b5c3130906292123v5b708707s32c483a89e2d8859@mail.gmail.com>
Message-ID: <20090630052619.GC18109@phare.normalesup.org>

On Mon, Jun 29, 2009 at 10:23:04PM -0600, Ondrej Certik wrote:
> I get an annoying warning in firefox that the security certificate for
> paying is invalid (only valid for "www.enthought.com", notice the
> "www"). Here is the address:

> https://enthought.com/scipy09/?email=ondrej at certik.cz

> however, if I change the address manually to:

> https://www.enthought.com/scipy09/?email=ondrej at certik.cz

> then it just works.

Thanks for pointing out. I think corrected the problem in the codebase,
however, I cannot try this out myself right now. Could you confirm that
you are no longer seeing the problem.

Cheers,

Ga?l


From ondrej at certik.cz  Tue Jun 30 03:02:10 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 30 Jun 2009 01:02:10 -0600
Subject: [SciPy-dev] [SciPy-user] [ANN] SciPy 2009 conference opened up
	for registration
In-Reply-To: <20090630052619.GC18109@phare.normalesup.org>
References: <20090619140158.GA12012@phare.normalesup.org>
	<85b5c3130906211620l21baecaaq7d469fb8f693f098@mail.gmail.com>
	<20090621235540.GB14395@phare.normalesup.org>
	<a08e5f80906290556g17d86daemf67f23468856837a@mail.gmail.com>
	<20090629143553.GA16691@phare.normalesup.org>
	<85b5c3130906292123v5b708707s32c483a89e2d8859@mail.gmail.com>
	<20090630052619.GC18109@phare.normalesup.org>
Message-ID: <85b5c3130906300002n541a195ar58f9d87537bd1030@mail.gmail.com>

On Mon, Jun 29, 2009 at 11:26 PM, Gael
Varoquaux<gael.varoquaux at normalesup.org> wrote:
> On Mon, Jun 29, 2009 at 10:23:04PM -0600, Ondrej Certik wrote:
>> I get an annoying warning in firefox that the security certificate for
>> paying is invalid (only valid for "www.enthought.com", notice the
>> "www"). Here is the address:
>
>> https://enthought.com/scipy09/?email=ondrej at certik.cz
>
>> however, if I change the address manually to:
>
>> https://www.enthought.com/scipy09/?email=ondrej at certik.cz
>
>> then it just works.
>
> Thanks for pointing out. I think corrected the problem in the codebase,
> however, I cannot try this out myself right now. Could you confirm that
> you are no longer seeing the problem.

Yes, it's fixed. Thanks!

Ondrej


From arokem at berkeley.edu  Tue Jun 30 18:16:28 2009
From: arokem at berkeley.edu (Ariel Rokem)
Date: Tue, 30 Jun 2009 15:16:28 -0700
Subject: [SciPy-dev] Memory usage of scipy.io.loadmat
Message-ID: <43958ee60906301516s637b180fm35b96d5b61a1b549@mail.gmail.com>

Hi everyone,

I have stumbled on some interesting behavior of scipy.io.loadmat. The short
of it - it looks like loadmat is gobbling up memory in some unjustified
manner and releasing it under some strange circumstances.

Here's the long story. This is all happening on a Mac OS 10.5.7, running EPD
4.0.30001 (Python 2.5.2), but with a relatively new version of scipy (see
below).

I start ipython -pylab in one terminal and run 'top' in another, in order to
monitor the memory usage. Here's what I get initially:

PhysMem:  417M wired,  449M active,  183M inactive, 1055M used, 3041M free.

Then:

In [1]: import scipy

In [2]: scipy.__version__
Out[2]: '0.8.0.dev5606'

In [3]: import scipy.io as sio

Here's what it looks like now:

PhysMem:  418M wired,  450M active,  183M inactive, 1058M used, 3038M free.

So far, so good. I read in a large matfile with tons of data in it:

In [4]: a =
sio.loadmat('/Users/arokem/Projects/SchizoSpread/Scans/SMR033109_MC/Gray/Original/TSeries/Scan1/tSeries1.mat')

PhysMem:  419M wired, 1024M active,  183M inactive, 1632M used, 2464M free.

So - about 600 MB of memory is taken up by this new variable.

Now to the wierdness:

In [5]: b
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/Users/arokem/<ipython console> in <module>()

NameError: name 'b' is not defined

Of course - 'b' doesn't exist!

But now, the memory usage has dramatically gone down:

PhysMem:  420M wired,  740M active,  183M inactive, 1350M used, 2746M free.

So - just invoking an error in the ipython command line has freed up 300 MB.
Where did they come from? I tried different things - assigning other
variables doesn't seem to free up this memory. Neither do calls to other
functions. Except "plot()", which does seem to do the trick for some reason.
Interestingly, when I run all this in a python interactive session (and not
ipython), I get a similar memory usage initially. Calling a non-existent
variable does not free up the memory, but other things do. For example,
import matplotlib.pylab into the namespace did the trick. Does anyone have
any idea what is going on?

Thanks --

Ariel


-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090630/3865a477/attachment.html>

From robert.kern at gmail.com  Tue Jun 30 18:19:14 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 30 Jun 2009 17:19:14 -0500
Subject: [SciPy-dev] Memory usage of scipy.io.loadmat
In-Reply-To: <43958ee60906301516s637b180fm35b96d5b61a1b549@mail.gmail.com>
References: <43958ee60906301516s637b180fm35b96d5b61a1b549@mail.gmail.com>
Message-ID: <3d375d730906301519g19575991q6b3cdf6d24033c2b@mail.gmail.com>

On Tue, Jun 30, 2009 at 17:16, Ariel Rokem<arokem at berkeley.edu> wrote:
> Hi everyone,
>
> I have stumbled on some interesting behavior of scipy.io.loadmat. The short
> of it - it looks like loadmat is gobbling up memory in some unjustified
> manner and releasing it under some strange circumstances.
>
> Here's the long story. This is all happening on a Mac OS 10.5.7, running EPD
> 4.0.30001 (Python 2.5.2), but with a relatively new version of scipy (see
> below).
>
> I start ipython -pylab in one terminal and run 'top' in another, in order to
> monitor the memory usage. Here's what I get initially:
>
> PhysMem:? 417M wired,? 449M active,? 183M inactive, 1055M used, 3041M free.
>
> Then:
>
> In [1]: import scipy
>
> In [2]: scipy.__version__
> Out[2]: '0.8.0.dev5606'
>
> In [3]: import scipy.io as sio
>
> Here's what it looks like now:
>
> PhysMem:? 418M wired,? 450M active,? 183M inactive, 1058M used, 3038M free.
>
> So far, so good. I read in a large matfile with tons of data in it:
>
> In [4]: a =
> sio.loadmat('/Users/arokem/Projects/SchizoSpread/Scans/SMR033109_MC/Gray/Original/TSeries/Scan1/tSeries1.mat')
>
> PhysMem:? 419M wired, 1024M active,? 183M inactive, 1632M used, 2464M free.
>
> So - about 600 MB of memory is taken up by this new variable.
>
> Now to the wierdness:
>
> In [5]: b
> ---------------------------------------------------------------------------
> NameError???????????????????????????????? Traceback (most recent call last)
>
> /Users/arokem/<ipython console> in <module>()
>
> NameError: name 'b' is not defined
>
> Of course - 'b' doesn't exist!
>
> But now, the memory usage has dramatically gone down:
>
> PhysMem:? 420M wired,? 740M active,? 183M inactive, 1350M used, 2746M free.
>
> So - just invoking an error in the ipython command line has freed up 300 MB.
> Where did they come from? I tried different things - assigning other
> variables doesn't seem to free up this memory. Neither do calls to other
> functions. Except "plot()", which does seem to do the trick for some reason.
> Interestingly, when I run all this in a python interactive session (and not
> ipython), I get a similar memory usage initially. Calling a non-existent
> variable does not free up the memory, but other things do. For example,
> import matplotlib.pylab into the namespace did the trick. Does anyone have
> any idea what is going on?

Garbage collection? Try the above after a call to gc.disable().

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From saintmlx at apstat.com  Tue Jun 30 18:33:10 2009
From: saintmlx at apstat.com (Xavier Saint-Mleux)
Date: Tue, 30 Jun 2009 18:33:10 -0400
Subject: [SciPy-dev] [SciPy-user] Memory usage of scipy.io.loadmat
In-Reply-To: <43958ee60906301516s637b180fm35b96d5b61a1b549@mail.gmail.com>
References: <43958ee60906301516s637b180fm35b96d5b61a1b549@mail.gmail.com>
Message-ID: <4A4A92A6.9070503@apstat.com>


>
> So - just invoking an error in the ipython command line has freed up
> 300 MB. Where did they come from? I tried different things - assigning
> other variables doesn't seem to free up this memory. Neither do calls
> to other functions. Except "plot()", which does seem to do the trick
> for some reason. Interestingly, when I run all this in a python
> interactive session (and not ipython), I get a similar memory usage
> initially. Calling a non-existent variable does not free up the
> memory, but other things do. For example, import matplotlib.pylab into
> the namespace did the trick. Does anyone have any idea what is going on?
>

It is probably just the garbage collector being invoked.  If you invoke
it manually, does it always free memory? e.g.:

import gc

gc.collect()



Xavier Saint-Mleux




From d_l_goldsmith at yahoo.com  Tue Jun 30 18:54:30 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 30 Jun 2009 15:54:30 -0700 (PDT)
Subject: [SciPy-dev] Tomorrow's Skypecon: Proposed Agenda
Message-ID: <976425.10817.qm@web52110.mail.re2.yahoo.com>


Proposed Agenda

Old Business:

    Timetable for approval of Ralf's patch for ticket #1146

New Business:

    Clarification of how much and what should be in the docstrings of methods which are equivalent to some function

Please email me any additional items ASAP.  (And your Skype ID if you haven't already and want to participate.)

Also, thanks to all who chipped in this past week to get Polynomials to the "Goal Met (almost)" state; there are a few pending road blocks to completion, but generally, I'd say it was a success.  Here are a few proposals for "Category of the Week" for the coming week:

Financial Functions - Status: 50% done Leader: Skipper Seabold
Random Number Generation - Status: 57% done Leader: Alan Jackson 
Linear Algebra - Status: 24% done Leader: None (yet)

Feel free to cast a vote via email if you won't be able to join the Skypecon.

Talk to you tomorrow, hopefully.

David Goldsmith
Technical Editor


      


From arokem at berkeley.edu  Tue Jun 30 19:24:57 2009
From: arokem at berkeley.edu (Ariel Rokem)
Date: Tue, 30 Jun 2009 16:24:57 -0700
Subject: [SciPy-dev] [SciPy-user] Memory usage of scipy.io.loadmat
In-Reply-To: <4A4A92A6.9070503@apstat.com>
References: <43958ee60906301516s637b180fm35b96d5b61a1b549@mail.gmail.com> 
	<4A4A92A6.9070503@apstat.com>
Message-ID: <43958ee60906301624l7fd7f445sebd0d69b4ac32e61@mail.gmail.com>

Yes - that does seem to free up the memory.

While running this:

In [11]: for i in range(10):
                 a =
sio.loadmat('/Users/arokem/Projects/SchizoSpread/Scans/SMR033109_MC/Gray/Original/TSeries/Scan1/tSeries1.mat')

causes a memory error, running this:

In [14]: for i in range(10):
                a =
sio.loadmat('/Users/arokem/Projects/SchizoSpread/Scans/SMR033109_MC/Gray/Original/TSeries/Scan1/tSeries1.mat')
                gc.collect()

seems like it could go on forever (looking at the memory usage on a memory
monitor, it just goes up and down to the same point, without net
accumulation).

Thanks a lot!

Ariel









On Tue, Jun 30, 2009 at 3:33 PM, Xavier Saint-Mleux <saintmlx at apstat.com>wrote:

>
> >
> > So - just invoking an error in the ipython command line has freed up
> > 300 MB. Where did they come from? I tried different things - assigning
> > other variables doesn't seem to free up this memory. Neither do calls
> > to other functions. Except "plot()", which does seem to do the trick
> > for some reason. Interestingly, when I run all this in a python
> > interactive session (and not ipython), I get a similar memory usage
> > initially. Calling a non-existent variable does not free up the
> > memory, but other things do. For example, import matplotlib.pylab into
> > the namespace did the trick. Does anyone have any idea what is going on?
> >
>
> It is probably just the garbage collector being invoked.  If you invoke
> it manually, does it always free memory? e.g.:
>
> import gc
>
> gc.collect()
>
>
>
> Xavier Saint-Mleux
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090630/cac9f825/attachment.html>