On Fri, May 11, 2012 at 9:26 PM, T J wrote:
> On Fri, May 11, 2012 at 1:12 PM, Mark Wiebe wrote:
>>
>> On Fri, May 11, 2012 at 2:18 PM, Pauli Virtanen wrote:
>>>
>>> 11.05.2012 17:54, Frédéric Bastien kirjoitti:
>>> > In Theano we use a view, but that is not relevant as it is the
>>> > compiler
On Thu, May 10, 2012 at 7:23 PM, Chris Barker wrote:
> That is one of my concerns about the "bit pattern" idea -- we've then
> created a new binary type that no other standard software understands
> -- that looks like a a lot of work to me to deal with, or even worse,
> ripe for weird, non-obvious
Hi there!
I'm having troubles getting numpy to work with ACML. I'm running Ubuntu
12.04 on an x86-64 system and use acml 5.1.0.
On my first try, I installed numpy/scipy from the official ubuntu
repository, then just changed the symlink to the blas/lapack libraries
of my system to use acml. i.
Running on Linux RHEL4
numpy.random.multivariate_normal seems to work well for 25 mean values but when
I go to 26 mean values (and their corresponding covariance values) it produces
garbage.
Any ideas?
$ python2.7 good.py
np version: 1.6.1
determinate(covariances): 42854852.1649
0 [ 3.45322570
On Fri, May 11, 2012 at 1:12 PM, Mark Wiebe wrote:
> On Fri, May 11, 2012 at 2:18 PM, Pauli Virtanen wrote:
>
>> 11.05.2012 17:54, Frédéric Bastien kirjoitti:
>> > In Theano we use a view, but that is not relevant as it is the
>> > compiler that tell what is inplace. So this is invisible to the
On Thu, May 10, 2012 at 10:28 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, May 10, 2012 at 2:43 AM, Nathaniel Smith wrote:
> > Hi Matthew,
> >
> > On Thu, May 10, 2012 at 12:01 AM, Matthew Brett
> wrote:
> >>> The third proposal is certainly the best one from Cython's perspective;
> >>> and I imag
On Fri, May 11, 2012 at 8:37 AM, mark florisson
wrote:
> On 11 May 2012 12:13, Dag Sverre Seljebotn
> wrote:
> > (NumPy devs: I know, I get too many ideas. But this time I *really*
> believe
> > in it, I think this is going to be *huge*. And if Mark F. likes it it's
> not
> > going to be without
On Fri, May 11, 2012 at 2:18 PM, Pauli Virtanen wrote:
> 11.05.2012 17:54, Frédéric Bastien kirjoitti:
> > In Theano we use a view, but that is not relevant as it is the
> > compiler that tell what is inplace. So this is invisible to the user.
> >
> > What about a parameter to diagonal() that def
On Fri, May 11, 2012 at 6:13 AM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really*
> believe in it, I think this is going to be *huge*. And if Mark F. likes
> it it's not going to be without manpower; and as his mentor I
On May 11, 2012, at 2:18 PM, Pauli Virtanen wrote:
> 11.05.2012 17:54, Frédéric Bastien kirjoitti:
>> In Theano we use a view, but that is not relevant as it is the
>> compiler that tell what is inplace. So this is invisible to the user.
>>
>> What about a parameter to diagonal() that default to
11.05.2012 17:54, Frédéric Bastien kirjoitti:
> In Theano we use a view, but that is not relevant as it is the
> compiler that tell what is inplace. So this is invisible to the user.
>
> What about a parameter to diagonal() that default to return a view not
> writable as you said. The user can the
hi,
is this intended?
np.histogramdd([[1,2],[3,4]],bins=2)
(array([[ 1., 0.],
[ 0., 1.]]),
[array([ 1. , 1.5, 2. ]), array([ 3. , 3.5, 4. ])])
np.histogram2d([1,2],[3,4],bins=2)
(array([[ 1., 0.],
[ 0., 1.]]),
array([ 1. , 1.5, 2. ]),
array([ 3. , 3.5, 4. ]))
np.h
On Fri, May 11, 2012 at 12:00 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Fri, May 11, 2012 at 9:01 AM, Benjamin Root wrote:
>
>> Hello all,
>>
>> I need to sort a structured array in a stable manner. I am also sorting
>> only by one of the keys, so I don't think lexsort()
On Fri, May 11, 2012 at 9:01 AM, Benjamin Root wrote:
> Hello all,
>
> I need to sort a structured array in a stable manner. I am also sorting
> only by one of the keys, so I don't think lexsort() is stable in that
> respect. np.sort() allows for choosing 'mergesort', but it appears to not
> be
In Theano we use a view, but that is not relevant as it is the
compiler that tell what is inplace. So this is invisible to the user.
What about a parameter to diagonal() that default to return a view not
writable as you said. The user can then choose what it want and this
don't break the inferface
I've been trying to sort through the changes that landed in master
from the missingdata branch to figure out how to separate out changes
related to NA support from those that aren't, and noticed that one of
them should probably be flagged to the list. Traditionally,
arr.diagonal() and np.diagonal(a
On Fri, May 11, 2012 at 09:59:16AM -0500, Travis Oliphant wrote:
> > Is there a advantage for users by making it a subclass? Nobody is saying
> > you couldn't 'inherit' the struct (make the ndmask struct be castable to
> > a PyArrayObject*) even if that is not declared in the Python type object.
Hi all,
I'm an idiot and seem to have accidentally deleted the
NA-discussion-status web page. I do have a query into support@github,
but, does anyone happen to have a local copy of the content, perhaps
in their browser cache?
Frustratedly yrs,
-- Nathaniel
On 05/11/2012 01:36 AM, Travis Oliphant wrote:
>>>
>>> I guess this mixture of Python-API and C-API is different from the way
>>> the API tries to protect incorrect access. From the Python API, it.
>>> should let everything through, because it's for Python code to use. From
>>> the C API, it should
Hello all,
I need to sort a structured array in a stable manner. I am also sorting
only by one of the keys, so I don't think lexsort() is stable in that
respect. np.sort() allows for choosing 'mergesort', but it appears to not
be implemented for structured arrays. Am I going to have to create a
>>
>> See my post in the other thread for my proposal to add a flag that allows
>> users to switch between the Python side default being ndarray's or ndmasked,
>> but they are different types at the C-level.The proposal so far does not
>> specify whether or not ndarray or ndmasked is a subc
On May 11, 2012, at 2:13 AM, Fernando Perez wrote:
> On Thu, May 10, 2012 at 11:44 PM, Scott Sinclair
> wrote:
>> That's pretty much how things already work. The documentation is in
>> the main source tree and built docs end up at http://docs.scipy.org.
>> NEPs live at https://github.com/numpy/n
On Sat, May 5, 2012 at 2:15 PM, Ralf Gommers wrote:
> Hi,
>
> I'm pleased to announce the availability of the first release candidate of
> NumPy 1.6.2. This is a maintenance release. Due to the delay of the NumPy
> 1.7.0, this release contains far more fixes than a regular NumPy bugfix
> release.
On 11 May 2012 12:13, Dag Sverre Seljebotn wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really* believe
> in it, I think this is going to be *huge*. And if Mark F. likes it it's not
> going to be without manpower; and as his mentor I'd pitch in too here and
> there.)
>
> (M
This comes from a refactor of the work on CEP 1000: It's a pre-PEP with
a hack we can use *today*, that allows 3rd party libraries to agree on
extensions to the PyTypeObject structure.
http://wiki.cython.org/enhancements/cep1001
As hinted in my other recent thread, I believe this will also be g
On 11 May 2012 12:13, Dag Sverre Seljebotn wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really* believe
> in it, I think this is going to be *huge*. And if Mark F. likes it it's not
> going to be without manpower; and as his mentor I'd pitch in too here and
> there.)
>
> (M
On 05/11/2012 01:13 PM, Dag Sverre Seljebotn wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really*
> believe in it, I think this is going to be *huge*. And if Mark F. likes
> it it's not going to be without manpower; and as his mentor I'd pitch in
> too here and there.)
>
> (
(NumPy devs: I know, I get too many ideas. But this time I *really*
believe in it, I think this is going to be *huge*. And if Mark F. likes
it it's not going to be without manpower; and as his mentor I'd pitch in
too here and there.)
(Mark F.: I believe this is *very* relevant to your GSoC. I c
On Thu, May 10, 2012 at 11:44 PM, Scott Sinclair
wrote:
> That's pretty much how things already work. The documentation is in
> the main source tree and built docs end up at http://docs.scipy.org.
> NEPs live at https://github.com/numpy/numpy/tree/master/doc/neps, but
> don't get published outside
29 matches
Mail list logo
