Hello,
I
installed Numpy 1.5.1 with Python 2.7.2 and when I try to test my QIIME install
it gives me the following error:
/apps/qiime-1.5/dependencies/lib/python2.7/site-packages/numpy/core/multiarray.so:
undefined symbol: _Py_ascii_whitespace
ldd
for that file gives:
libm.s
On 6/13/12 5:11 PM, Wes McKinney wrote:
> And retrieving group indicies/summing:
>
> In [8]: %timeit arr=='a'
> 1000 loops, best of 3: 1.52 ms per loop
> In [10]: vals = np.random.randn(100)
> In [20]: inds = [arr==x for x in lets]
> In [23]: %timeit for ind in inds: vals[ind].sum()
> 10 loops,
On 6/13/12 1:12 PM, Nathaniel Smith wrote:
> your-branch's-base-master but not in your-repo's-master are new stuff
> that you did on your branch. Solution is just to do
>git push master
Fixed, thanks.
> Yes, of course we *could* write the code to implement these "open"
> dtypes, and then wri
On Wed, Jun 13, 2012 at 5:19 PM, Bryan Van de Ven wrote:
> On 6/13/12 1:54 PM, Wes McKinney wrote:
>> OK, I need to spend some time on this as it will directly impact me.
>> Random thoughts here.
>>
>> It looks like the levels can only be strings. This is too limited for
>> my needs. Why not suppo
On 6/13/12 1:54 PM, Wes McKinney wrote:
> OK, I need to spend some time on this as it will directly impact me.
> Random thoughts here.
>
> It looks like the levels can only be strings. This is too limited for
> my needs. Why not support all possible NumPy dtypes? In pandas world,
> the levels can b
Not the neighborhood one, though. It would be good if this iterator had a
cython wrapper, and ndimage used that, though.
Le 13 juin 2012 18:59, "Ralf Gommers" a
écrit :
>
>
> On Wed, Jun 13, 2012 at 6:57 PM, Thouis (Ray) Jones wrote:
>
>> Hello,
>>
>> I'm rewriting scipy.ndimage.label() using num
On Wed, Jun 13, 2012 at 7:58 PM, Ralf Gommers
wrote:
> I think there were some changes to the iterator API recently, so please keep
> in mind that scipy has to still be compatible with numpy 1.5.1 (at least for
> now).
Noted. I'll rewrite using the 1.5 API, and save this for when scipy
moves to
On Wed, Jun 13, 2012 at 2:12 PM, Nathaniel Smith wrote:
> On Wed, Jun 13, 2012 at 5:44 PM, Bryan Van de Ven wrote:
>> On 6/13/12 8:33 AM, Nathaniel Smith wrote:
>>> Hi Bryan,
>>>
>>> I skimmed over the diff:
>>> https://github.com/bryevdv/numpy/compare/master...enum
>>> It was a bit hard to r
On Wed, Jun 13, 2012 at 5:44 PM, Bryan Van de Ven wrote:
> On 6/13/12 8:33 AM, Nathaniel Smith wrote:
>> Hi Bryan,
>>
>> I skimmed over the diff:
>> https://github.com/bryevdv/numpy/compare/master...enum
>> It was a bit hard to read since it seems like about half the changes
>> in that branch
On Wed, Jun 13, 2012 at 6:57 PM, Thouis (Ray) Jones wrote:
> Hello,
>
> I'm rewriting scipy.ndimage.label() using numpy's iterator API,
I think there were some changes to the iterator API recently, so please
keep in mind that scipy has to still be compatible with numpy 1.5.1 (at
least for now).
Tried to figure out in-place calculation for the neighbor routine that I
recently submitted to numpy, but got nowhere. See
https://github.com/numpy/numpy/pull/303 for what I came up with. It
currently makes a new array to hold the calculations.
If someone does come up with something - I would be
Further to the recent discussion on lazy evaluation & numba, I moved
what I was doing into a new project:
PyAutoDiff:
https://github.com/jaberg/pyautodiff
It currently works by executing CPython bytecode with a numpy-aware
engine that builds a symbolic expression graph with Theano... so you
can d
Hello,
I'm rewriting scipy.ndimage.label() using numpy's iterator API, and
would like to add the ability for it to operate in-place. However, to
do so, I need to limit the neighbors consulted to those that have
already been processed in the parent iterator over the input and
output arrays. Is th
Nathaniel Smith wrote:
>On Wed, Jun 13, 2012 at 5:04 PM, Dag Sverre Seljebotn
> wrote:
>> On 06/13/2012 03:33 PM, Nathaniel Smith wrote:
>>> I'm inclined to say therefore that we should just drop the "open
>type"
>>> idea, since it adds complexity but doesn't seem to actually solve
>the
>>> pro
On 6/13/12 8:33 AM, Nathaniel Smith wrote:
> Hi Bryan,
>
> I skimmed over the diff:
> https://github.com/bryevdv/numpy/compare/master...enum
> It was a bit hard to read since it seems like about half the changes
> in that branch are datatime cleanups or something? I hope you'll
> separate those
On Wed, Jun 13, 2012 at 5:04 PM, Dag Sverre Seljebotn
wrote:
> On 06/13/2012 03:33 PM, Nathaniel Smith wrote:
>> I'm inclined to say therefore that we should just drop the "open type"
>> idea, since it adds complexity but doesn't seem to actually solve the
>> problem it's designed for.
>
> If one
On 06/13/2012 03:33 PM, Nathaniel Smith wrote:
> On Tue, Jun 12, 2012 at 10:27 PM, Bryan Van de Ven
> wrote:
>> Hi all,
>>
>> It has been some time, but I do have an update regarding this proposed
>> feature. I thought it would be helpful to flesh out some parts of a
>> possible implementation to
I have M is numpy matrix with 0's& 1's. I want to color the nodes with
different colors.
can anyone give me a hint on the following code?
import network as nx
import pylab as plt
G=nx.Graph(M) # M is numpy matrix ,i.e:type(M)=numpy.ndarray
for i in xrange(len(M)):
tt=P[i,:].sum()
if
On Tue, Jun 12, 2012 at 10:27 PM, Bryan Van de Ven wrote:
> Hi all,
>
> It has been some time, but I do have an update regarding this proposed
> feature. I thought it would be helpful to flesh out some parts of a
> possible implementation to learn what can be spelled reasonably in
> NumPy. Mark Wi
19 matches
Mail list logo
