2009/12/6 josef.pktd :
np.equal(np.arange(5),'a')
> NotImplemented
Why is NotImplemented a *return* value? Normally NotImplementedError
is a raised exception, but if it's not implemented, it shouldn't be
returned as a value.
For one thing, it leads to absurdities like the following being po
Skipper Seabold wrote:
> I believe this is known, but I am surprised that division by "integer"
> zero results in the following.
>
> In [1]: import numpy as np
>
> In [2]: np.__version__
> Out[2]: '1.4.0.dev7539'
>
> In [3]: 0**-1 # or 0**-1/-1
>
On Sun, Dec 6, 2009 at 11:36 AM, Sturla Molden wrote:
> Colin J. Williams skrev:
>> When one has a smallish sample size, what give the best estimate of the
>> variance?
> What do you mean by "best estimate"?
>
> Unbiased? Smallest standard error?
>
>
>> In the widely used Analysis of Variance (ANO
(we hashed this out on IRC, but replying here for the sake of
recording it)
On 5-Dec-09, at 9:04 PM, Pauli Virtanen wrote:
> Can you try to change linalg/setup.py so that it *only* includes
> lapack_litemodule.c in the build?
Yup; it turns out it wasn't NumPy's lapack_lite calling dlamc3_ but
On Sun, Dec 6, 2009 at 1:16 PM, Skipper Seabold wrote:
> In [9]: np.array([0])**-1/-1
> Floating point exception
>
> This last command crashes the interpreter.
>
>
It crashes mine also, and IMO, anything that crashes the interpreter should
be considered a bug - can you file a bug report, please?
I believe this is known, but I am surprised that division by "integer"
zero results in the following.
In [1]: import numpy as np
In [2]: np.__version__
Out[2]: '1.4.0.dev7539'
In [3]: 0**-1 # or 0**-1/-1
---
ZeroDivisionErro
On Sun, Dec 06, 2009 at 01:12:52PM -0600, Robert Kern wrote:
> Is this Cython or Pyrex code?
It is.
> Unfortunately Pyrex checks the size of types exactly such that even if
> you extend the type in a backwards compatible way, it will raise that
> exception.
OK, that makes sens. Thanks for the
On Sun, Dec 6, 2009 at 07:53, Gael Varoquaux
wrote:
> I have a lot of code that has stopped working with my latest SVN pull to
> numpy.
>
> * Some compiled code yields an error looking like (from memory):
>
> "incorrect type 'numpy.ndarray'"
>
> Rebuilding it is sufficient.
Is this Cython or P
On Sun, Dec 6, 2009 at 6:36 AM, Ralf Gommers wrote:
>
>
> On Sun, Dec 6, 2009 at 2:10 PM, Gael Varoquaux <
> gael.varoqu...@normalesup.org> wrote:
>
>>
>> Excellent. I tweeked a bit the text to make it clearer:
>> http://docs.scipy.org/numpy/docs/numpy.core.defchararray.chararray/
>>
>> I made it
Colin J. Williams skrev:
> When one has a smallish sample size, what give the best estimate of the
> variance?
What do you mean by "best estimate"?
Unbiased? Smallest standard error?
> In the widely used Analysis of Variance (ANOVA), the degrees of freedom
> are reduced for each mean estimate
On Sun, Dec 6, 2009 at 4:57 AM, wrote:
> what's the difference in the implementation between np.equal and == ?
> np.equal raises NotImplemented for strings, while == works.
>
aa
> array(['a', 'b', 'a', 'aa', 'a'],
> dtype='|S2')
>
aa == 'a'
> array([ True, False, True, False, Tru
On Sun, Dec 6, 2009 at 9:21 AM, wrote:
> On Sun, Dec 6, 2009 at 11:01 AM, Colin J. Williams wrote:
> >
>
> What's the best estimate? That's the main question
>
> Estimators differ in their (sample or posterior) distribution,
> especially bias and variance.
> Stein estimator dominates OLS in
On Sun, Dec 6, 2009 at 11:01 AM, Colin J. Williams wrote:
>
>
> On 04-Dec-09 10:54 AM, Bruce Southey wrote:
>> On 12/04/2009 06:18 AM, yogesh karpate wrote:
>>> @ Pauli and @ Colin:
>>> Sorry for the late reply. I was
>>> busy in some other assignments.
>>> # As f
On 04-Dec-09 10:54 AM, Bruce Southey wrote:
> On 12/04/2009 06:18 AM, yogesh karpate wrote:
>> @ Pauli and @ Colin:
>> Sorry for the late reply. I was
>> busy in some other assignments.
>> # As far as normalization by(n) is concerned then its common
>> assumpt
su, 2009-12-06 kello 15:37 +0100, Xavier Gnata kirjoitti:
> Is there a way to help to port numpy to python3?
If you want to write some code, check
http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt
> I don't thing I have time to rewrite some code but I can test whatever
> has to be teste
Hi,
Is there a way to help to port numpy to python3?
I don't thing I have time to rewrite some code but I can test whatever
has to be tested.
Is there an official web page showing the status of this port? Same
question from scipy?
It is already nice to see that the last numpy version is compatib
On Sun, Dec 6, 2009 at 2:10 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
>
> Excellent. I tweeked a bit the text to make it clearer:
> http://docs.scipy.org/numpy/docs/numpy.core.defchararray.chararray/
>
> I made it clear that the replacement are present only starting numpy 1.4.
> I
On Sun, Dec 06, 2009 at 04:14:55PM +0200, Pauli Virtanen wrote:
> su, 2009-12-06 kello 15:11 +0100, Gael Varoquaux kirjoitti:
> > On Sun, Dec 06, 2009 at 04:07:16PM +0200, Pauli Virtanen wrote:
> [clip]
> > > > I find it a bit strange that a '.x' release induces so much breakage,
> > > > and I am a
su, 2009-12-06 kello 15:11 +0100, Gael Varoquaux kirjoitti:
> On Sun, Dec 06, 2009 at 04:07:16PM +0200, Pauli Virtanen wrote:
[clip]
> > > I find it a bit strange that a '.x' release induces so much breakage,
> > > and I am afraid that it won't be popular amongst our users.
>
> > Well, there's sti
On Sun, Dec 06, 2009 at 04:07:16PM +0200, Pauli Virtanen wrote:
> su, 2009-12-06 kello 14:53 +0100, Gael Varoquaux kirjoitti:
> > I have a lot of code that has stopped working with my latest SVN pull to
> > numpy.
> Which SVN revision? Before or after the Py3K commits?
> Note that the trunk is cur
su, 2009-12-06 kello 14:53 +0100, Gael Varoquaux kirjoitti:
> I have a lot of code that has stopped working with my latest SVN pull to
> numpy.
Which SVN revision? Before or after the Py3K commits?
Note that the trunk is currently aiming at 1.5.x, code for 1.4.x is in a
branch.
> * Some compiled
I have a lot of code that has stopped working with my latest SVN pull to
numpy.
* Some compiled code yields an error looking like (from memory):
"incorrect type 'numpy.ndarray'"
Rebuilding it is sufficient.
* I had some code doing:
hashlib.md5(x).hexdigest()
where x is a numpy array.
On Sun, Dec 06, 2009 at 01:11:24PM +0100, Ralf Gommers wrote:
>[2]http://docs.scipy.org/doc/numpy/reference/generated/numpy.chararray.html
>> says that chararray are depreciated. I think I saw a discussion on the
>> mailing list that hinted otherwise. Which one is true? Should I correc
su, 2009-12-06 kello 12:54 +0900, David Cournapeau kirjoitti:
> On Sun, Dec 6, 2009 at 9:41 AM, Pauli Virtanen wrote:
> > Hi,
> >
> > I'd like to commit my Py3 Numpy branch to SVN trunk soon:
> >
> >http://github.com/pv/numpy-work/commits/py3k
>
> Awesome - I think we should merge this AS
On Sat, Dec 5, 2009 at 10:54 PM, David Cournapeau wrote:
> On Sun, Dec 6, 2009 at 9:41 AM, Pauli Virtanen wrote:
>> Hi,
>>
>> I'd like to commit my Py3 Numpy branch to SVN trunk soon:
>>
>> http://github.com/pv/numpy-work/commits/py3k
>
> Awesome - I think we should merge this ASAP. In par
what's the difference in the implementation between np.equal and == ?
np.equal raises NotImplemented for strings, while == works.
>>> aa
array(['a', 'b', 'a', 'aa', 'a'],
dtype='|S2')
>>> aa == 'a'
array([ True, False, True, False, True], dtype=bool)
>>> np.equal(aa,'a')
NotImplemented
2009/12/6 Ernest Adrogué :
> Hi,
>
> A few weeks ago there was a discussion about a
> histogram_discrete() function --sorry for starting a new
> thread but I have lost the mails.
>
> Somebody pointed out that bincount() already can be used
> to histogram discrete data (except that it doesn't work
>
Hi,
A few weeks ago there was a discussion about a
histogram_discrete() function --sorry for starting a new
thread but I have lost the mails.
Somebody pointed out that bincount() already can be used
to histogram discrete data (except that it doesn't work
with negative values).
I have just discov
On Sun, Dec 6, 2009 at 12:13 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
>
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.chararray.html
> says that chararray are depreciated. I think I saw a discussion on the
> mailing list that hinted otherwise. Which one is true? Shou
http://docs.scipy.org/doc/numpy/reference/generated/numpy.chararray.html
says that chararray are depreciated. I think I saw a discussion on the
mailing list that hinted otherwise. Which one is true? Should I correct
the docs?
Cheers,
Gaël
___
NumPy-Disc
A Saturday 05 December 2009 11:16:55 Dag Sverre Seljebotn escrigué:
> > Mmh, the only case that I'm aware about dtype *mutability* is changing
> > the names of compound types:
> >
> > In [19]: t = np.dtype("i4,f4")
> >
> > In [20]: t
> > Out[20]: dtype([('f0', ' >
> > In [21]: hash(t)
> > Out[21]:
31 matches
Mail list logo
