Re: [Numpy-discussion] Strange behavior of np.sinc
On Sat, Jun 26, 2010 at 9:39 PM, Robert Kern wrote: > On Sat, Jun 26, 2010 at 23:33, David Goldsmith > wrote: > > Hi! The docstring for numpy.lib.function_base.sinc indicates that the > > parameter has to be an ndarray, and that it will return the limiting > value 1 > > for sinc(0). Checking to see if it should actually say array_like, I > found > > the following (Python 2.6): > > > np.sinc(np.array((0,0.5))) > > array([ 1., 0.63661977]) > np.sinc((0,0.5)) > > array([NaN, 0.63661977]) > np.sinc([0,0.5]) > > array([NaN, 0.63661977]) > np.version.version > > '1.4.1' > > > > So, it doesn't choke on non-array sequences, and appears to return values > > consistent w/ array input, except at 0. Bug in code (failure at 0 if in > a > > sequence) and in the doc (ndarray should be array_like)? > > Bug in both code and docs. There should be an "x = np.asanyarray(x)" > before the rest of the code. > Thanks Robert; I'll file a ticket and fix the docstring. DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Strange behavior of np.sinc
On Sat, Jun 26, 2010 at 23:33, David Goldsmith wrote: > Hi! The docstring for numpy.lib.function_base.sinc indicates that the > parameter has to be an ndarray, and that it will return the limiting value 1 > for sinc(0). Checking to see if it should actually say array_like, I found > the following (Python 2.6): > np.sinc(np.array((0,0.5))) > array([ 1. , 0.63661977]) np.sinc((0,0.5)) > array([ NaN, 0.63661977]) np.sinc([0,0.5]) > array([ NaN, 0.63661977]) np.version.version > '1.4.1' > > So, it doesn't choke on non-array sequences, and appears to return values > consistent w/ array input, except at 0. Bug in code (failure at 0 if in a > sequence) and in the doc (ndarray should be array_like)? Bug in both code and docs. There should be an "x = np.asanyarray(x)" before the rest of the 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Strange behavior of np.sinc
Hi! The docstring for numpy.lib.function_base.sinc indicates that the parameter has to be an ndarray, and that it will return the limiting value 1 for sinc(0). Checking to see if it should actually say array_like, I found the following (Python 2.6): >>> np.sinc(np.array((0,0.5))) array([ 1., 0.63661977]) >>> np.sinc((0,0.5)) array([NaN, 0.63661977]) >>> np.sinc([0,0.5]) array([NaN, 0.63661977]) >>> np.version.version '1.4.1' So, it doesn't choke on non-array sequences, and appears to return values consistent w/ array input, except at 0. Bug in code (failure at 0 if in a sequence) and in the doc (ndarray should be array_like)? DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 3:22 PM, wrote: > On Sat, Jun 26, 2010 at 6:11 PM, David Goldsmith > wrote: > > On Sat, Jun 26, 2010 at 3:03 PM, wrote: > >> > >> On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith > >> wrote: > >> > Something is systematically wrong if there are this many problems in > the > >> > numpy.stats docstrings: numpy is supposed to be (was) almost > completely > >> > ready for review; please focus on scipy unless/until the reason why > >> > there > >> > are now so many problems in numpy.stats can be determined (I suspect > the > >> > numpy.stats code has been made to call the scipy.stats.distributions > >> > module, > >> > and all those docstrings have been marked "Unimportant" - meaning do > not > >> > edit - either permanently, in the case of the instances, or > temporarily > >> > in > >> > the case of the base classes from which the instances are created). > >> > > >> > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). > >> > >> It's missing in several functions and incorrect docstrings have to be > >> corrected. Look at the log of e.g. pareto in the editor, the returns > >> have never been added, unless you find any missing revisions that are > >> not in the doc editor. > >> > >> Josef > > > > OK, I see it was promoted to "Needs review" very early in the first > Marathon > > - before the Standard had been finalized? God help us: how many other > numpy > > docstrings are improperly at "Needs review" because of this? Scheisse, > > numpy may not be as close to Ready For Review as we thought... > > Is there a chance that some changes got lost? > (Almost) anything's possible... :-( Well, here's what happened in the particular case of numpy's pareto: The promotion to "Needs review" took place - interestingly - 2008-06-26 (yes, two years ago today), despite the lack of a Returns section; the initial check-in of HOWTO_DOCUMENT.txt - which does specify that a Returns section be included (when applicable) - was one week before, 2008-06-19. So, it's not that surprising that this slipped through the cracks. Pauli (or anyone): is there a way to search the Wiki, e.g., using a SQL-like query, for docstrings that saw a change in status before a date, or between two dates? Thanks! DG > > I thought I had edited random.pareto to note that it is actually Lomax > or Pareto II. But I'm not completely sure I actually did it, and not > just intended to do it. I don't see any record in the doc editor, so > maybe I never did edit it. > > Josef > > > > > > DG > > > > > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?
Kurt Smith wrote:
> I'd really like arr.copy(order='F') to work -- is it supposed to as
> its docstring says, or is it supposed to raise a TypeError as it does
> now?
>
It works for me if I don't use the keyword. That is,
>>> b = a.copy('F')
But I get the same error if I use order='F', so there is a either a bug
in the docstring or a bug in the code.
Warren
> This is on numpy 1.4
>
>
import numpy as np
a = np.arange(10).reshape(5,2)
a
> array([[0, 1],
>[2, 3],
>[4, 5],
>[6, 7],
>[8, 9]])
>
print a.copy.__doc__
> a.copy(order='C')
>
> Return a copy of the array.
>
> Parameters
> --
> order : {'C', 'F', 'A'}, optional
> By default, the result is stored in C-contiguous (row-major) order in
> memory. If `order` is `F`, the result has 'Fortran' (column-major)
> order. If order is 'A' ('Any'), then the result has the same order
> as the input.
>
> Examples
>
> >>> x = np.array([[1,2,3],[4,5,6]], order='F')
>
> >>> y = x.copy()
>
> >>> x.fill(0)
>
> >>> x
> array([[0, 0, 0],
>[0, 0, 0]])
>
> >>> y
> array([[1, 2, 3],
>[4, 5, 6]])
>
> >>> y.flags['C_CONTIGUOUS']
> True
>
a.copy(order='C')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: copy() takes no keyword arguments
>
a.copy(order='F')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: copy() takes no keyword arguments
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?
I'd really like arr.copy(order='F') to work -- is it supposed to as
its docstring says, or is it supposed to raise a TypeError as it does
now?
This is on numpy 1.4
>>> import numpy as np
>>> a = np.arange(10).reshape(5,2)
>>> a
array([[0, 1],
[2, 3],
[4, 5],
[6, 7],
[8, 9]])
>>> print a.copy.__doc__
a.copy(order='C')
Return a copy of the array.
Parameters
--
order : {'C', 'F', 'A'}, optional
By default, the result is stored in C-contiguous (row-major) order in
memory. If `order` is `F`, the result has 'Fortran' (column-major)
order. If order is 'A' ('Any'), then the result has the same order
as the input.
Examples
>>> x = np.array([[1,2,3],[4,5,6]], order='F')
>>> y = x.copy()
>>> x.fill(0)
>>> x
array([[0, 0, 0],
[0, 0, 0]])
>>> y
array([[1, 2, 3],
[4, 5, 6]])
>>> y.flags['C_CONTIGUOUS']
True
>>> a.copy(order='C')
Traceback (most recent call last):
File "", line 1, in
TypeError: copy() takes no keyword arguments
>>> a.copy(order='F')
Traceback (most recent call last):
File "", line 1, in
TypeError: copy() takes no keyword arguments
>>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 3:28 PM, Vincent Davis wrote: > On Sat, Jun 26, 2010 at 4:22 PM, wrote: > > On Sat, Jun 26, 2010 at 6:11 PM, David Goldsmith > > wrote: > >> On Sat, Jun 26, 2010 at 3:03 PM, wrote: > >>> > >>> On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith > >>> wrote: > >>> > Something is systematically wrong if there are this many problems in > the > >>> > numpy.stats docstrings: numpy is supposed to be (was) almost > completely > >>> > ready for review; please focus on scipy unless/until the reason why > >>> > there > >>> > are now so many problems in numpy.stats can be determined (I suspect > the > >>> > numpy.stats code has been made to call the scipy.stats.distributions > >>> > module, > >>> > and all those docstrings have been marked "Unimportant" - meaning do > not > >>> > edit - either permanently, in the case of the instances, or > temporarily > >>> > in > >>> > the case of the base classes from which the instances are created). > >>> > > >>> > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). > >>> > >>> It's missing in several functions and incorrect docstrings have to be > >>> corrected. Look at the log of e.g. pareto in the editor, the returns > >>> have never been added, unless you find any missing revisions that are > >>> not in the doc editor. > >>> > >>> Josef > >> > >> OK, I see it was promoted to "Needs review" very early in the first > Marathon > >> - before the Standard had been finalized? God help us: how many other > numpy > >> docstrings are improperly at "Needs review" because of this? Scheisse, > >> numpy may not be as close to Ready For Review as we thought... > > > > Is there a chance that some changes got lost? > > > > I thought I had edited random.pareto to note that it is actually Lomax > > or Pareto II. But I'm not completely sure I actually did it, and not > > just intended to do it. I don't see any record in the doc editor, so > > maybe I never did edit it. > > Also several are missing examples but this is easy (copy past) with > the tests I just added. > Vincent > > I'm busy right now, but in a little bit I'll check when the Standard was "finalized" and demote - until they can be thoroughly checked for Standard compliance - to "Being Written" everything promoted to "Needs review" prior to that time. DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 4:22 PM, wrote: > On Sat, Jun 26, 2010 at 6:11 PM, David Goldsmith > wrote: >> On Sat, Jun 26, 2010 at 3:03 PM, wrote: >>> >>> On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith >>> wrote: >>> > Something is systematically wrong if there are this many problems in the >>> > numpy.stats docstrings: numpy is supposed to be (was) almost completely >>> > ready for review; please focus on scipy unless/until the reason why >>> > there >>> > are now so many problems in numpy.stats can be determined (I suspect the >>> > numpy.stats code has been made to call the scipy.stats.distributions >>> > module, >>> > and all those docstrings have been marked "Unimportant" - meaning do not >>> > edit - either permanently, in the case of the instances, or temporarily >>> > in >>> > the case of the base classes from which the instances are created). >>> > >>> > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). >>> >>> It's missing in several functions and incorrect docstrings have to be >>> corrected. Look at the log of e.g. pareto in the editor, the returns >>> have never been added, unless you find any missing revisions that are >>> not in the doc editor. >>> >>> Josef >> >> OK, I see it was promoted to "Needs review" very early in the first Marathon >> - before the Standard had been finalized? God help us: how many other numpy >> docstrings are improperly at "Needs review" because of this? Scheisse, >> numpy may not be as close to Ready For Review as we thought... > > Is there a chance that some changes got lost? > > I thought I had edited random.pareto to note that it is actually Lomax > or Pareto II. But I'm not completely sure I actually did it, and not > just intended to do it. I don't see any record in the doc editor, so > maybe I never did edit it. Also several are missing examples but this is easy (copy past) with the tests I just added. Vincent > > Josef > > >> >> DG >> >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Try this, new tests for numpy.random
I added a set of simple testes for numpy.random. These test only test that you get results and that they are stable. (see attachment) That said I get several errors (see below) as a result I assume of how the resent enthought 6.2 beta does the calculation (The tests results are from numpy running of 3.1) I think it would be a good idea if several others ran the test to see if there are other problems or if it is actually stable across versions. Any other feedback Vincent SUMMARY OF UNIT TEST RESULTS FAILED TESTS * TestRandomDist.test_lognormal -- test_random.py (numpy-vmd-dev/numpy/random/tests) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([[ 1.81865312, 0.07476378], [ 0.51747188, 0.61901346], [ 44.09839408, 0.35777415]]) y: array([[ 16.50698632, 36.54846706], [ 22.678866 , 0.71617561], [ 65.72798502, 86.84341601]]) unittest.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6): 279 testMethod() test_random.py (numpy-vmd-dev/numpy/random/tests): 272 np.testing.assert_array_almost_equal(actual, desired, decimal=15) utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 765 header='Arrays are not almost equal') utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 609 raise AssertionError(msg) * TestRandomDist.test_multivariate_normal -- test_random.py (numpy-vmd-dev/numpy/random/tests) AssertionError: Arrays are not almost equal (mismatch 50.0%) x: array([[[ -0.15876548, 10.], [ 0.58858952, 10.]], ... y: array([[[ -1.47027513, 10.], [ -1.65915082, 10.]], ... unittest.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6): 279 testMethod() test_random.py (numpy-vmd-dev/numpy/random/tests): 305 np.testing.assert_array_almost_equal(actual, desired, decimal=15) utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 765 header='Arrays are not almost equal') utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 609 raise AssertionError(msg) * TestRandomDist.test_negative_binomial -- test_random.py (numpy-vmd-dev/numpy/random/tests) AssertionError: Arrays are not equal (mismatch 100.0%) x: array([[702, 777], [692, 646], [630, 806]]) y: array([[848, 841], [892, 611], [779, 647]]) unittest.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6): 279 testMethod() test_random.py (numpy-vmd-dev/numpy/random/tests): 313 np.testing.assert_array_equal(actual, desired) utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 677 verbose=verbose, header='Arrays are not equal') utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 609 raise AssertionError(msg) * TestRandomDist.test_noncentral_chisquare -- test_random.py (numpy-vmd-dev/numpy/random/tests) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([[ 5.42550628, 3.68327961], [ 7.8305713 , 5.45961594], [ 10.68988949, 5.17932387]]) y: array([[ 23.91905354, 13.35324693], [ 31.22452661, 16.60047399], [ 5.03461598, 17.94973089]]) unittest.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6): 279 testMethod() test_random.py (numpy-vmd-dev/numpy/random/tests): 321 np.testing.assert_array_almost_equal(actual, desired, decimal=15) utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 765 header='Arrays are not almost equal') utils.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6/site-packages/numpy/testing): 609 raise AssertionError(msg) * TestRandomDist.test_noncentral_f -- test_random.py (numpy-vmd-dev/numpy/random/tests) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([[ 1.41010542, 106.52208522], [ 1.35761411, 45.00197918], [ 9.97943281, 13.86047453]]) y: array([[ 1.405981 , 0.34207973], [ 3.57715069, 7.92632663], [ 0.43741599, 1.17742088]]) unittest.py (/Library/Frameworks/Python.framework/Versions/6.2/lib/python2.6): 279 testMethod() test_random.py (numpy-vmd-dev/numpy/random/tests): 330 np.testing.assert
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 6:11 PM, David Goldsmith wrote: > On Sat, Jun 26, 2010 at 3:03 PM, wrote: >> >> On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith >> wrote: >> > Something is systematically wrong if there are this many problems in the >> > numpy.stats docstrings: numpy is supposed to be (was) almost completely >> > ready for review; please focus on scipy unless/until the reason why >> > there >> > are now so many problems in numpy.stats can be determined (I suspect the >> > numpy.stats code has been made to call the scipy.stats.distributions >> > module, >> > and all those docstrings have been marked "Unimportant" - meaning do not >> > edit - either permanently, in the case of the instances, or temporarily >> > in >> > the case of the base classes from which the instances are created). >> > >> > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). >> >> It's missing in several functions and incorrect docstrings have to be >> corrected. Look at the log of e.g. pareto in the editor, the returns >> have never been added, unless you find any missing revisions that are >> not in the doc editor. >> >> Josef > > OK, I see it was promoted to "Needs review" very early in the first Marathon > - before the Standard had been finalized? God help us: how many other numpy > docstrings are improperly at "Needs review" because of this? Scheisse, > numpy may not be as close to Ready For Review as we thought... Is there a chance that some changes got lost? I thought I had edited random.pareto to note that it is actually Lomax or Pareto II. But I'm not completely sure I actually did it, and not just intended to do it. I don't see any record in the doc editor, so maybe I never did edit it. Josef > > DG > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 3:03 PM, wrote: > On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith > wrote: > > Something is systematically wrong if there are this many problems in the > > numpy.stats docstrings: numpy is supposed to be (was) almost completely > > ready for review; please focus on scipy unless/until the reason why there > > are now so many problems in numpy.stats can be determined (I suspect the > > numpy.stats code has been made to call the scipy.stats.distributions > module, > > and all those docstrings have been marked "Unimportant" - meaning do not > > edit - either permanently, in the case of the instances, or temporarily > in > > the case of the base classes from which the instances are created). > > > > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). > > It's missing in several functions and incorrect docstrings have to be > corrected. Look at the log of e.g. pareto in the editor, the returns > have never been added, unless you find any missing revisions that are > not in the doc editor. > > Josef > OK, I see it was promoted to "Needs review" very early in the first Marathon - before the Standard had been finalized? God help us: how many other numpy docstrings are improperly at "Needs review" because of this? Scheisse, numpy may not be as close to Ready For Review as we thought... DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 3:56 PM, David Goldsmith wrote: > Something is systematically wrong if there are this many problems in the > numpy.stats docstrings: numpy is supposed to be (was) almost completely > ready for review; please focus on scipy unless/until the reason why there > are now so many problems in numpy.stats can be determined (I suspect the > numpy.stats code has been made to call the scipy.stats.distributions module, > and all those docstrings have been marked "Unimportant" - meaning do not > edit - either permanently, in the case of the instances, or temporarily in > the case of the base classes from which the instances are created). I ran across several more. missing returns and a little inconsistency with shape being defined as "shape" or "a" a few other things. I just stopped posting them to the list > > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). I had started a simple set of tests for the rand functions to catch problems like the one resulting from the way the enthought distr. was calculating randn(), I was just finishing that and making note of what I say in the docs as I did so. I am moving back to the scipy docs soon. Vincent > > DG > > On Sat, Jun 26, 2010 at 2:40 PM, Vincent Davis > wrote: >> >> numpy.random.poisson docs missing "Returns" >> >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.poisson.html#numpy.random.poisson >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > -- > Mathematician: noun, someone who disavows certainty when their uncertainty > set is non-empty, even if that set has measure zero.at > > Hope: noun, that delusive spirit which escaped Pandora's jar and, with her > lies, prevents mankind from committing a general suicide. (As interpreted > by Robert Graves) > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith wrote: > Something is systematically wrong if there are this many problems in the > numpy.stats docstrings: numpy is supposed to be (was) almost completely > ready for review; please focus on scipy unless/until the reason why there > are now so many problems in numpy.stats can be determined (I suspect the > numpy.stats code has been made to call the scipy.stats.distributions module, > and all those docstrings have been marked "Unimportant" - meaning do not > edit - either permanently, in the case of the instances, or temporarily in > the case of the base classes from which the instances are created). > > Bottom line: if it doesn't start w/ scipy, leave it alone (for now). It's missing in several functions and incorrect docstrings have to be corrected. Look at the log of e.g. pareto in the editor, the returns have never been added, unless you find any missing revisions that are not in the doc editor. Josef > > DG > > On Sat, Jun 26, 2010 at 2:40 PM, Vincent Davis > wrote: >> >> numpy.random.poisson docs missing "Returns" >> >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.poisson.html#numpy.random.poisson >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > -- > Mathematician: noun, someone who disavows certainty when their uncertainty > set is non-empty, even if that set has measure zero.at > > Hope: noun, that delusive spirit which escaped Pandora's jar and, with her > lies, prevents mankind from committing a general suicide. (As interpreted > by Robert Graves) > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
Something is systematically wrong if there are this many problems in the numpy.stats docstrings: numpy is supposed to be (was) almost completely ready for review; please focus on scipy unless/until the reason why there are now so many problems in numpy.stats can be determined (I suspect the numpy.stats code has been made to call the scipy.stats.distributions module, and all those docstrings have been marked "Unimportant" - meaning do not edit - either permanently, in the case of the instances, or temporarily in the case of the base classes from which the instances are created). Bottom line: if it doesn't start w/ scipy, leave it alone (for now). DG On Sat, Jun 26, 2010 at 2:40 PM, Vincent Davis wrote: > numpy.random.poisson docs missing "Returns" > > http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.poisson.html#numpy.random.poisson > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero.at Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"
On Sat, Jun 26, 2010 at 5:40 PM, Vincent Davis wrote: > numpy.random.poisson docs missing "Returns" > http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.poisson.html#numpy.random.poisson You could just copy a generic Returns section to all of these. They all return a sample (array or int, array or float) of the requested shape. Josef > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.random.poisson docs missing "Returns"
numpy.random.poisson docs missing "Returns" http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.poisson.html#numpy.random.poisson ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.random.pareto, missing "returns" in the docs
numpy.random.pareto, missing "returns" in the docs http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.pareto.html#numpy.random.pareto Vincent ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 3:18 PM, wrote:
> On Sat, Jun 26, 2010 at 5:12 PM, Vincent Davis
> wrote:
>> On Sat, Jun 26, 2010 at 3:04 PM, wrote:
>>> On Sat, Jun 26, 2010 at 4:58 PM, David Goldsmith
>>> wrote:
On Sat, Jun 26, 2010 at 1:41 PM, Vincent Davis
wrote:
>
> numpy.random.logseries(p, size=None)
>
> but the parameters section,
> Parameters:
> loc : float
> scale : float > 0.
> size : {tuple, int}
> Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
> samples are drawn.
>>
>> Thanks, I'll file a ticket
>
> Don't file a ticket, just edit the docs. It's just the docstring not the
> source
Ok, I just need to remember to make the changes :-)
Vincent
>
> the Return is also wrong
>
> samples : {ndarray, scalar}
> where the values are all integers in [0, n].
>
> sample values are greater or equal to one, but unbound above
>
stats.logser.pmf(np.arange(1, 10005),0.9)
> array([ 7.85931402e-06, 7.85844959e-06, 7.85758532e-06,
> 7.85672123e-06, 7.85585731e-06])
>
> Josef
>
>> Vincent
>>
>
> Notice that p <> loc and what about scale.
>
> I'll file a ticket unless I am mission something,
> Which should it be loc or p
> What about scale.
The source is opaque (to me; Cython?) so unless you can decipher it, test
actual behavior and document that - my guess is that p is short for
"parameters" and is intended to be a two-element array_like containing both
the loc and scale parameters, but that's the way it should be documented,
not with some unprecedented reference to loc and scale when the signature
specifies p, but as I said, check that first.
>>>
>> np.source(stats.distributions.logser_gen)
>>>
>>> class logser_gen(rv_discrete):
>>> def _rvs(self, pr):
>>> return mtrand.logseries(pr,size=self._size)
>>> def _argcheck(self, pr):
>>> return (pr > 0) & (pr < 1)
>>> def _pmf(self, k, pr):
>>> return -pr**k * 1.0 / k / log(1-pr)
>>>
>>> p is a probability between in (0,1), just a mistake in the documentation.
>>>
> There is no numpy-dev list right? Should this list be used or the
> scipy-dev list>
That's a good Q: this is definitely a "bug" in the doc (loc and scale
shouldn't be documented as such when they're not explicitly in the function
signature), in which case scipy-dev is the proper place to post, but if it
turns out to be a bug in the code also, then this is the proper place,
since
all numpy devs are subscribed here, and numpy users should know about
potential bugs (numpy devs will correct me if I'm wrong).
>>>
>>> I think question about the substance/content of the docstrings should
>>> always go to the mailing list of the corresponding function.
>>>
>>> Josef
>>>
DG
>
> Vincent
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide. (As interpreted
by Robert Graves)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] printing of array and leading white space ?
This is a little strange and I am not sure what is going on. Look at the number of spaced before the first number in the array. >>> x = np.array([629.54440098249688162, 26186.5470310494529258 ]) >>> x array([ 629.54440098249688162, 26186.5470310494529258 ]) 3 spaces before 629.544... >>> x = np.array([629.54440098249688162, 2634186.5470310494529258 ]) >>> x array([ 6.29544400982496882e+02, 2.63418654703104962e+06]) 2 spaces There are many different ways experiment, and I assume that the spaces are there to help the printed array look better. The 3 spaces are not there is the second digit is shorter. The thing is I can't think of an example where the 3 spaces are needed. Is there an example? Vincent ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 5:12 PM, Vincent Davis wrote:
> On Sat, Jun 26, 2010 at 3:04 PM, wrote:
>> On Sat, Jun 26, 2010 at 4:58 PM, David Goldsmith
>> wrote:
>>> On Sat, Jun 26, 2010 at 1:41 PM, Vincent Davis
>>> wrote:
numpy.random.logseries(p, size=None)
but the parameters section,
Parameters:
loc : float
scale : float > 0.
size : {tuple, int}
Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
samples are drawn.
>
> Thanks, I'll file a ticket
Don't file a ticket, just edit the docs. It's just the docstring not the source
the Return is also wrong
samples : {ndarray, scalar}
where the values are all integers in [0, n].
sample values are greater or equal to one, but unbound above
>>> stats.logser.pmf(np.arange(1, 10005),0.9)
array([ 7.85931402e-06, 7.85844959e-06, 7.85758532e-06,
7.85672123e-06, 7.85585731e-06])
Josef
> Vincent
>
Notice that p <> loc and what about scale.
I'll file a ticket unless I am mission something,
Which should it be loc or p
What about scale.
>>>
>>> The source is opaque (to me; Cython?) so unless you can decipher it, test
>>> actual behavior and document that - my guess is that p is short for
>>> "parameters" and is intended to be a two-element array_like containing both
>>> the loc and scale parameters, but that's the way it should be documented,
>>> not with some unprecedented reference to loc and scale when the signature
>>> specifies p, but as I said, check that first.
>>
> np.source(stats.distributions.logser_gen)
>>
>> class logser_gen(rv_discrete):
>> def _rvs(self, pr):
>> return mtrand.logseries(pr,size=self._size)
>> def _argcheck(self, pr):
>> return (pr > 0) & (pr < 1)
>> def _pmf(self, k, pr):
>> return -pr**k * 1.0 / k / log(1-pr)
>>
>> p is a probability between in (0,1), just a mistake in the documentation.
>>
>>>
There is no numpy-dev list right? Should this list be used or the
scipy-dev list>
>>>
>>> That's a good Q: this is definitely a "bug" in the doc (loc and scale
>>> shouldn't be documented as such when they're not explicitly in the function
>>> signature), in which case scipy-dev is the proper place to post, but if it
>>> turns out to be a bug in the code also, then this is the proper place, since
>>> all numpy devs are subscribed here, and numpy users should know about
>>> potential bugs (numpy devs will correct me if I'm wrong).
>>
>> I think question about the substance/content of the docstrings should
>> always go to the mailing list of the corresponding function.
>>
>> Josef
>>
>>>
>>> DG
Vincent
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>>
>>> --
>>> Mathematician: noun, someone who disavows certainty when their uncertainty
>>> set is non-empty, even if that set has measure zero.
>>>
>>> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
>>> lies, prevents mankind from committing a general suicide. (As interpreted
>>> by Robert Graves)
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 3:04 PM, wrote:
> On Sat, Jun 26, 2010 at 4:58 PM, David Goldsmith
> wrote:
>> On Sat, Jun 26, 2010 at 1:41 PM, Vincent Davis
>> wrote:
>>>
>>> numpy.random.logseries(p, size=None)
>>>
>>> but the parameters section,
>>> Parameters:
>>> loc : float
>>> scale : float > 0.
>>> size : {tuple, int}
>>> Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
>>> samples are drawn.
Thanks, I'll file a ticket
Vincent
>>>
>>> Notice that p <> loc and what about scale.
>>>
>>> I'll file a ticket unless I am mission something,
>>> Which should it be loc or p
>>> What about scale.
>>
>> The source is opaque (to me; Cython?) so unless you can decipher it, test
>> actual behavior and document that - my guess is that p is short for
>> "parameters" and is intended to be a two-element array_like containing both
>> the loc and scale parameters, but that's the way it should be documented,
>> not with some unprecedented reference to loc and scale when the signature
>> specifies p, but as I said, check that first.
>
np.source(stats.distributions.logser_gen)
>
> class logser_gen(rv_discrete):
> def _rvs(self, pr):
> return mtrand.logseries(pr,size=self._size)
> def _argcheck(self, pr):
> return (pr > 0) & (pr < 1)
> def _pmf(self, k, pr):
> return -pr**k * 1.0 / k / log(1-pr)
>
> p is a probability between in (0,1), just a mistake in the documentation.
>
>>
>>> There is no numpy-dev list right? Should this list be used or the
>>> scipy-dev list>
>>
>> That's a good Q: this is definitely a "bug" in the doc (loc and scale
>> shouldn't be documented as such when they're not explicitly in the function
>> signature), in which case scipy-dev is the proper place to post, but if it
>> turns out to be a bug in the code also, then this is the proper place, since
>> all numpy devs are subscribed here, and numpy users should know about
>> potential bugs (numpy devs will correct me if I'm wrong).
>
> I think question about the substance/content of the docstrings should
> always go to the mailing list of the corresponding function.
>
> Josef
>
>>
>> DG
>>>
>>> Vincent
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>>
>> --
>> Mathematician: noun, someone who disavows certainty when their uncertainty
>> set is non-empty, even if that set has measure zero.
>>
>> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
>> lies, prevents mankind from committing a general suicide. (As interpreted
>> by Robert Graves)
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 4:58 PM, David Goldsmith
wrote:
> On Sat, Jun 26, 2010 at 1:41 PM, Vincent Davis
> wrote:
>>
>> numpy.random.logseries(p, size=None)
>>
>> but the parameters section,
>> Parameters:
>> loc : float
>> scale : float > 0.
>> size : {tuple, int}
>> Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
>> samples are drawn.
>>
>> Notice that p <> loc and what about scale.
>>
>> I'll file a ticket unless I am mission something,
>> Which should it be loc or p
>> What about scale.
>
> The source is opaque (to me; Cython?) so unless you can decipher it, test
> actual behavior and document that - my guess is that p is short for
> "parameters" and is intended to be a two-element array_like containing both
> the loc and scale parameters, but that's the way it should be documented,
> not with some unprecedented reference to loc and scale when the signature
> specifies p, but as I said, check that first.
>>> np.source(stats.distributions.logser_gen)
class logser_gen(rv_discrete):
def _rvs(self, pr):
return mtrand.logseries(pr,size=self._size)
def _argcheck(self, pr):
return (pr > 0) & (pr < 1)
def _pmf(self, k, pr):
return -pr**k * 1.0 / k / log(1-pr)
p is a probability between in (0,1), just a mistake in the documentation.
>
>> There is no numpy-dev list right? Should this list be used or the
>> scipy-dev list>
>
> That's a good Q: this is definitely a "bug" in the doc (loc and scale
> shouldn't be documented as such when they're not explicitly in the function
> signature), in which case scipy-dev is the proper place to post, but if it
> turns out to be a bug in the code also, then this is the proper place, since
> all numpy devs are subscribed here, and numpy users should know about
> potential bugs (numpy devs will correct me if I'm wrong).
I think question about the substance/content of the docstrings should
always go to the mailing list of the corresponding function.
Josef
>
> DG
>>
>> Vincent
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. (As interpreted
> by Robert Graves)
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 1:41 PM, Vincent Davis wrote:
> numpy.random.logseries(p, size=None)
>
> but the parameters section,
> Parameters:
> loc : float
> scale : float > 0.
> size : {tuple, int}
> Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
> samples are drawn.
>
> Notice that p <> loc and what about scale.
>
> I'll file a ticket unless I am mission something,
> Which should it be loc or p
> What about scale.
>
The source is opaque (to me; Cython?) so unless you can decipher it, test
actual behavior and document that - my guess is that p is short for
"parameters" and is intended to be a two-element array_like containing both
the loc and scale parameters, but that's the way it should be documented,
not with some unprecedented reference to loc and scale when the signature
specifies p, but as I said, check that first.
There is no numpy-dev list right? Should this list be used or the
> scipy-dev list>
>
That's a good Q: this is definitely a "bug" in the doc (loc and scale
shouldn't be documented as such when they're not explicitly in the function
signature), in which case scipy-dev is the proper place to post, but if it
turns out to be a bug in the code also, then this is the proper place, since
all numpy devs are subscribed here, and numpy users should know about
potential bugs (numpy devs will correct me if I'm wrong).
DG
> Vincent
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide. (As interpreted
by Robert Graves)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 4:47 PM, Vincent Davis wrote:
> On Sat, Jun 26, 2010 at 2:41 PM, Vincent Davis
> wrote:
>> numpy.random.logseries(p, size=None)
>>
>> but the parameters section,
>> Parameters:
>> loc : float
>> scale : float > 0.
>> size : {tuple, int}
>> Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
>> samples are drawn.
>>
>> Notice that p <> loc and what about scale.
>>
>> I'll file a ticket unless I am mission something,
>> Which should it be loc or p
>> What about scale.
>
> I was looking at this page
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.logseries.html#numpy.random.logseries
>
> To partially answer my own question
> np.random.logseries(p=.923456789, size=(3, 2))
> array([[31, 1],
> [ 2, 38],
> [ 1, 1]])
>
> "loc" is not valid,
> "scale" is not valid
this might be a copy-paste error, logseries is tested against scipy.stats.logser
I will check it, but I think you are right and loc, scale should be
replaced in the docs by the explanation of p.
numpy-discussion is the right list for this.
Josef
>>
>> There is no numpy-dev list right? Should this list be used or the
>> scipy-dev list>
>>
>> Vincent
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation error in numpy.random.logseries
On Sat, Jun 26, 2010 at 2:41 PM, Vincent Davis wrote:
> numpy.random.logseries(p, size=None)
>
> but the parameters section,
> Parameters:
> loc : float
> scale : float > 0.
> size : {tuple, int}
> Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
> samples are drawn.
>
> Notice that p <> loc and what about scale.
>
> I'll file a ticket unless I am mission something,
> Which should it be loc or p
> What about scale.
I was looking at this page
http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.logseries.html#numpy.random.logseries
To partially answer my own question
np.random.logseries(p=.923456789, size=(3, 2))
array([[31, 1],
[ 2, 38],
[ 1, 1]])
"loc" is not valid,
"scale" is not valid
>
> There is no numpy-dev list right? Should this list be used or the
> scipy-dev list>
>
> Vincent
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Documentation error in numpy.random.logseries
numpy.random.logseries(p, size=None)
but the parameters section,
Parameters:
loc : float
scale : float > 0.
size : {tuple, int}
Output shape. If the given shape is, e.g., (m, n, k), then m * n * k
samples are drawn.
Notice that p <> loc and what about scale.
I'll file a ticket unless I am mission something,
Which should it be loc or p
What about scale.
There is no numpy-dev list right? Should this list be used or the
scipy-dev list>
Vincent
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Solving a NLLSQ Problem by Pieces?
The basic problem with nonlinear least squares fitting, as with other nonlinear minimization problems, is that the standard algorithms find only a local minimum. It's easy to miss the global minimum and instead settle on a local minimum that is in fact a horrible fit. To deal with this, there are global optimization techniques - simulated annealing, genetic algorithms, and what have you (including the simplest, explore the whole space with a "dense enough" grid then fine-tune the best one with a local optimizer) - but they're computationally very expensive and not always reliable. So when it's possible to use domain-specific knowledge to make sure what you're settling on is the real minimum, this is a better solution. In this specific case, as in many optimization problems, the problem can be viewed as a series of nested approximations. The crudest approximation might even be linear in some cases; but the point is, you solve the first approximation first because it has fewer parameters and a solution space you understand better (e.g. maybe you can be sure it only has one local minimum). Then because your approximations are by assumption nested, adding more parameters complicates the space you're solving over, but you can be reasonably confident that you're "close" to the right solution already. (If your approximations are "orthogonal" in the right sense, you can even fix the parameters from previous stages and optimize only the new ones; be careful with this, though.) This approach is a very good way to incorporate domain-specific knowledge into your code, but you need to parameterize your problem as a series of nested approximations, and if it turns out the corrections are not small you can still get yourself into trouble. (Or, for that matter, if the initial solution space is complex enough you can still get yourself in trouble. Or if you're not careful your solver can take your sensible initial guess at some stage and zip off into never-never land instead of exploring "nearby".) If you're interested in how other people solve this particular problem, you could take a look at the open-source panorama stitcher "hugin", which fits for a potentially very large number of parameters, including a camera model. To bring this back nearer to on-topic, you will naturally not find domain-specific knowledge built into scipy or numpy, but you will find various local and global optimizers, some of which are specialized for the case of least-squares. So if you wanted to implement this sort of thing with scipy, you could write the domain-specific code yourself and simply call into one of scipy's optimizers. You could also look at OpenOpt, a scikit containing a number of global optimizers. Anne P.S. This question would be better suited to scipy-user or astropy than numpy-discussion. -A On 26 June 2010 13:12, Wayne Watson wrote: > The context here is astronomy and optics. The real point is in the last > paragraph. > > I'm looking at a paper that deals with 5 NL (nonlinear) equations and 8 > unknown parameters. > A. a=a0+arctan((y-y0)/(x-x0) > B. z=V*r+S*e**(D*r) > r=sqrt((x-x0)**2+(y-y0)**2) > and > C. cos(z)=cos(u)*cos(z)-sin(u)*sin(ep)*cos(b) > sin(a-E) = sin(b)*sin(u)/sin(z) > > > He's trying to estimate parameters of a fisheye lens which has taken > star images on a photo plate. For example, x0,y0 is the offset of the > center of projection from the zenith (camera not pointing straight up in > the sky.) Eq. 2 expresses some nonlinearity in the lens. > > a0, xo, y0, V, S, D, ep, and E are the parameters. It looks like he uses > gradient descent (NLLSQ is nonlinear least squares in Subject.), and > takes each equation in turn using the parameter values from the > preceding one in the next, B. He provides reasonable initial estimates. > > A final step uses all eight parameters. He re-examines ep and E, and > assigns new estimates. For all (star positions) on the photo plate, he > minimizes SUM (Fi**2*Gi) using values from the step for A and B, except > for x0,y0. He then does some more dithering, which I'll skip. > > What I've presented is probably a bit difficult to understand without a > good optics understanding, but my question is something like is this > commonly done to solve a system of NLLSQ? It looks a bit wild. I guess > if one knows his subject well, then bringing some "extra" knowledge to > the process helps. As I understand it, he solves parameters in A, then > uses them in B, and so on. I guess that's a reasonable way to do it. > > -- > Wayne Watson (Watson Adventures, Prop., Nevada City, CA) > > (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) > Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet > > Air travel safety Plus Three/Minus 8 rule. Eighty % > of crashes take place in the first 3 minutes and > last 8 minutes. Survival chances are good in you're > paying attention. No hard drinks prior to
Re: [Numpy-discussion] Possible to use numexpr with user made ufuncs/scipy ufuncs?
Sat, 26 Jun 2010 17:51:52 +0100, Francesc Alted wrote:
[clip]
> Well, I'd say that this support can be faked in numexpr easily. For
> example, if one want to compute a certain ufunc called, say, sincos(x)
> defined as sin(cos(x)) (okay, that's very simple, but it will suffice
> for demonstration purposes), he can express that as sincos =
> "sin(cos(%s))", and then use it in a more complex expression like:
>
> "%s+1*cos(%s)" % (sincos % 'x', 'y')
>
> that will be expanded as:
>
> "sin(cos(x))+1*cos(y)"
>
> Of course, this is a bit crude, but I'd say that's more than enough for
> allowing the evaluation of moderately complex expressions.
But what if such an expression does not exist? For example, there is no
finite closed form expression for the Bessel functions in terms of
elementary functions. An accurate implementation is rather complicated,
and usually piecewise defined.
For convenience reasons, it could be useful if one could do something like
numexpr.evaluate("cos(iv(0, x))", functions=dict(iv=scipy.special.iv))
and this would be translated to numexpr bytecode that would make a Python
function call to obtain "iv(0, x)" for each block of data required,
assuming "iv" is a vectorized function. It's of course possible to
precompute the value of "iv(0, x)", but this is extra hassle and requires
additional memory.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Solving a NLLSQ Problem by Pieces?
The context here is astronomy and optics. The real point is in the last paragraph. I'm looking at a paper that deals with 5 NL (nonlinear) equations and 8 unknown parameters. A. a=a0+arctan((y-y0)/(x-x0) B. z=V*r+S*e**(D*r) r=sqrt((x-x0)**2+(y-y0)**2) and C. cos(z)=cos(u)*cos(z)-sin(u)*sin(ep)*cos(b) sin(a-E) = sin(b)*sin(u)/sin(z) He's trying to estimate parameters of a fisheye lens which has taken star images on a photo plate. For example, x0,y0 is the offset of the center of projection from the zenith (camera not pointing straight up in the sky.) Eq. 2 expresses some nonlinearity in the lens. a0, xo, y0, V, S, D, ep, and E are the parameters. It looks like he uses gradient descent (NLLSQ is nonlinear least squares in Subject.), and takes each equation in turn using the parameter values from the preceding one in the next, B. He provides reasonable initial estimates. A final step uses all eight parameters. He re-examines ep and E, and assigns new estimates. For all (star positions) on the photo plate, he minimizes SUM (Fi**2*Gi) using values from the step for A and B, except for x0,y0. He then does some more dithering, which I'll skip. What I've presented is probably a bit difficult to understand without a good optics understanding, but my question is something like is this commonly done to solve a system of NLLSQ? It looks a bit wild. I guess if one knows his subject well, then bringing some "extra" knowledge to the process helps. As I understand it, he solves parameters in A, then uses them in B, and so on. I guess that's a reasonable way to do it. -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Air travel safety Plus Three/Minus 8 rule. Eighty % of crashes take place in the first 3 minutes and last 8 minutes. Survival chances are good in you're paying attention. No hard drinks prior to those periods. No sleeping pills either. Sit within 5 rows of an exit door. --The Survivors Club, Ben Sherwood Web Page: ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Possible to use numexpr with user made ufuncs/scipy ufuncs?
2010/6/26 Pauli Virtanen > Hi, > > la, 2010-06-26 kello 14:24 +0200, Francesc Alted kirjoitti: > [clip] > > Yeah, you need to explicitly code the support for new functions in > numexpr. > > But another possibility, more doable, would be to code the scipy.special > > functions by using numexpr as a computing back-end. > > Would it be possible to add generic support for user-supplied ufuncs > into numexpr? This would maybe be more of a convenience feature than a > speed improvement, although perhaps some speed could be gained by > evaluating ufuncs per-block. > Well, I'd say that this support can be faked in numexpr easily. For example, if one want to compute a certain ufunc called, say, sincos(x) defined as sin(cos(x)) (okay, that's very simple, but it will suffice for demonstration purposes), he can express that as sincos = "sin(cos(%s))", and then use it in a more complex expression like: "%s+1*cos(%s)" % (sincos % 'x', 'y') that will be expanded as: "sin(cos(x))+1*cos(y)" Of course, this is a bit crude, but I'd say that's more than enough for allowing the evaluation of moderately complex expressions. Having said this, one can always think in setting up a wrapper for doing a similar thing more elegantly (although I'm not sure if this is worth the effort). -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Possible to use numexpr with user made ufuncs/scipy ufuncs?
OK, perhaps I will just continue preevaluating the expressions involving special functions. Thank you for the help Fancesc +1 to Pauli's suggestion. On Sat, Jun 26, 2010 at 6:19 AM, Pauli Virtanen wrote: > Hi, > > la, 2010-06-26 kello 14:24 +0200, Francesc Alted kirjoitti: > [clip] > > Yeah, you need to explicitly code the support for new functions in > numexpr. > > But another possibility, more doable, would be to code the scipy.special > > functions by using numexpr as a computing back-end. > > Would it be possible to add generic support for user-supplied ufuncs > into numexpr? This would maybe be more of a convenience feature than a > speed improvement, although perhaps some speed could be gained by > evaluating ufuncs per-block. > > -- > Pauli Virtanen > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Possible to use numexpr with user made ufuncs/scipy ufuncs?
Hi, la, 2010-06-26 kello 14:24 +0200, Francesc Alted kirjoitti: [clip] > Yeah, you need to explicitly code the support for new functions in numexpr. > But another possibility, more doable, would be to code the scipy.special > functions by using numexpr as a computing back-end. Would it be possible to add generic support for user-supplied ufuncs into numexpr? This would maybe be more of a convenience feature than a speed improvement, although perhaps some speed could be gained by evaluating ufuncs per-block. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Possible to use numexpr with user made ufuncs/scipy ufuncs?
A Friday 25 June 2010 21:33:43 John Salvatier escrigué: > Hello, > > Does anyone know whether it is possible to use numexpr with scipy ufuncs > (such as those in scipy.special) or user made ufuncs? This functionality > would be extremely useful. I don't see them in the list of supported > functions (http://code.google.com/p/numexpr/wiki/Overview) and I get a > 'TypeError: 'VariableNode' object is not callable' error when I try this. Yeah, you need to explicitly code the support for new functions in numexpr. But another possibility, more doable, would be to code the scipy.special functions by using numexpr as a computing back-end. However, I understand that many scipy.special functions need to evaluate basic transcendental functions (trignonometrical, exponential, logarithmic...), so you should no expect big speed-ups just by using a plain Numexpr. However, you can always link Numexpr with Intel's VML (Vector Math Library), which can use SIMD and multi-core capabilities in modern Intel/AMD processors so as to accelerate the evaluation of such transcendental functions (typically between 2x and 10x, depending on the function and number of cores in your processor). -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
