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 t
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 followin
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.
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
> t
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 t
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
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:
> >>> > Someth
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
>>>
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 o
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 (w
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
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
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
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.s
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 o
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-discus
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/listinf
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.rand
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 =
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 parameter
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.
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 s
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
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
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
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 m
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
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 p
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(
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
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, yo
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 poss
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
> function
33 matches
Mail list logo
