On Oct 1, 2012, at 9:11 AM, Jim Bosch wrote:
> On 09/30/2012 03:59 PM, Travis Oliphant wrote:
>> Hey all,
>>
>> In a github-discussion with Gael and Nathaniel, we came up with a proposal
>> for .base that we should put before this list.Traditionally, .base has
>> always pointed to None for
Hello Jay,
Cool idea! I like to see work on structured arrays. Just a couple of
questions:
- Since there are already have ufuncs for primitive dtypes (int, float,
etc), and you are just acting columnwise here, can't you write a single
function which interprets the dtypes, gathers the a
Perhaps sum wasn't the best function for this example. I'm going to
rework the code with other function
Consider a function that operates on an array and returns a number
def myfunc(data):
return data.min() + 2 * data.max()
The function with nditer is:
def nditer_fun(data, axes):
it = n
On Mon, Oct 1, 2012 at 2:32 PM, Chris Barker wrote:
> On Sat, Sep 29, 2012 at 2:16 AM, Gael Varoquaux
> wrote:
> > Next time I see you, I owe you a beer for making you cross :).
>
> If I curse at you, will I get a beer too?
>
Wow! This is taking a very Pavlovian turn...
Be Well
Anthony
>
>
Hi,
On Mon, Oct 1, 2012 at 9:42 PM, Matthew Brett wrote:
> Hi,
>
> One of our kind users pointed out an error when using easy_install to
> install our package nipy. I've reproduced it now on a bare package
> using numpy distutils and having a trivial extension:
>
> https://github.com/matthew-br
Hi,
One of our kind users pointed out an error when using easy_install to
install our package nipy. I've reproduced it now on a bare package
using numpy distutils and having a trivial extension:
https://github.com/matthew-brett/apkg
To reproduce:
git clone git://github.com/mathew-brett/apkg.g
On Sat, Sep 29, 2012 at 2:16 AM, Gael Varoquaux
wrote:
> Next time I see you, I owe you a beer for making you cross :).
If I curse at you, will I get a beer too?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
76
On Fri, Sep 28, 2012 at 3:11 PM, Charles R Harris
wrote:
> If the behaviour is not specified and tested, there is no guarantee that it
> will continue.
This is an open-source project - there is no guarantee of ANYTHING.
But that being said, the specification and testing of numpy is quite
weak --
Paul,
Nice to see someone working on these issues, but:
I'm not sure the problem you are trying to solve -- accumulating in a
list is pretty efficient anyway -- not a whole lot overhead.
But if you do want to improve that, it may be better to change the
accumulating method, rather than doing the
Sounds like I'm not the only one surprised then:
http://projects.scipy.org/numpy/ticket/2220
Matthew Brett wrote:
> Hi,
>
> On Mon, Oct 1, 2012 at 9:04 AM, Pierre Haessig
> wrote:
>> Hi,
>>
>> Le 28/09/2012 21:02, Neal Becker a écrit :
>>> In [19]: u = np.arange (10)
>>>
>>> In [20]: v = np.ar
On Mon, 2012-10-01 at 10:59 -0600, Charles R Harris wrote:
>
>
> On Mon, Oct 1, 2012 at 10:09 AM, Sebastian Berg
> wrote:
> Hey,
>
> About the imaginary part being ignored for all/any function...
>
>
>
>
> > The all method fail
On Mon, Oct 1, 2012 at 10:09 AM, Sebastian Berg
wrote:
> Hey,
>
> About the imaginary part being ignored for all/any function...
>
>
>
>
> > The all method fails also.
> >
> > In [1]: a = zeros(5, complex)
> >
> > In [2]: a.imag = 1
> >
> > In [3]: a.all()
> > Out[3]: False
> >
> > Chuck
> >
> I
Hey,
About the imaginary part being ignored for all/any function...
> The all method fails also.
>
> In [1]: a = zeros(5, complex)
>
> In [2]: a.imag = 1
>
> In [3]: a.all()
> Out[3]: False
>
> Chuck
>
I believe this diff fixes the issue (also posted on Tracker), I doubt
its the best way
All,
I've submitted the following pull request for NumPy:
https://github.com/numpy/numpy/pull/462
This change allows ufuncs to be registered for structured arrays by using a
new API method PyUFunc_RegisterLoopForStructType. For example, a ufunc
could be registered to take two arrays of type 'u8,
On Mon, Oct 1, 2012 at 3:40 PM, Thouis (Ray) Jones wrote:
> On Mon, Oct 1, 2012 at 8:20 AM, Nathaniel Smith wrote:
>> [...]
>> How can we discourage people from doing this in the future? Can we
>> make .base write-only from the Python level (with suitable deprecation
>> period)? Rename it to ._ba
On Mon, Oct 1, 2012 at 8:40 AM, Thouis (Ray) Jones wrote:
> On Mon, Oct 1, 2012 at 8:20 AM, Nathaniel Smith wrote:
> > [...]
> > How can we discourage people from doing this in the future? Can we
> > make .base write-only from the Python level (with suitable deprecation
> > period)? Rename it to
On Mon, Oct 1, 2012 at 8:20 AM, Nathaniel Smith wrote:
> [...]
> How can we discourage people from doing this in the future? Can we
> make .base write-only from the Python level (with suitable deprecation
> period)? Rename it to ._base (likewise) so that it's still possible to
> peek under the cov
On Mon, Oct 1, 2012 at 8:35 AM, Nathaniel Smith wrote:
> On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux
> wrote:
>> On Sun, Sep 30, 2012 at 07:17:42PM +0100, Nathaniel Smith wrote:
>>> Is there anything better to do than simply revert np.copy() to its
>>> traditional behaviour and accept that np
On Mon, Oct 1, 2012 at 6:20 AM, Nathaniel Smith wrote:
> On Sun, Sep 30, 2012 at 8:59 PM, Travis Oliphant
> wrote:
> > Hey all,
> >
> > In a github-discussion with Gael and Nathaniel, we came up with a
> proposal for .base that we should put before this list.Traditionally,
> .base has always
On 09/30/2012 03:59 PM, Travis Oliphant wrote:
> Hey all,
>
> In a github-discussion with Gael and Nathaniel, we came up with a proposal
> for .base that we should put before this list.Traditionally, .base has
> always pointed to None for arrays that owned their own memory and to the
> "most
On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux
wrote:
> On Sun, Sep 30, 2012 at 07:17:42PM +0100, Nathaniel Smith wrote:
>> Is there anything better to do than simply revert np.copy() to its
>> traditional behaviour and accept that np.copy(a) and a.copy() will
>> continue to have different semant
On Sun, Sep 30, 2012 at 8:59 PM, Travis Oliphant wrote:
> Hey all,
>
> In a github-discussion with Gael and Nathaniel, we came up with a proposal
> for .base that we should put before this list.Traditionally, .base has
> always pointed to None for arrays that owned their own memory and to th
Hi,
On Mon, Oct 1, 2012 at 9:04 AM, Pierre Haessig wrote:
> Hi,
>
> Le 28/09/2012 21:02, Neal Becker a écrit :
>> In [19]: u = np.arange (10)
>>
>> In [20]: v = np.arange (10)
>>
>> In [21]: u[v] = u
>>
>> In [22]: u[v] = np.arange(11)
>>
>> silence...
> I've same behavior with my numpy 1.6.2.
>
Hi,
Le 28/09/2012 21:02, Neal Becker a écrit :
> In [19]: u = np.arange (10)
>
> In [20]: v = np.arange (10)
>
> In [21]: u[v] = u
>
> In [22]: u[v] = np.arange(11)
>
> silence...
I've same behavior with my numpy 1.6.2.
It indeed looks strange that the end of the data vector is dropped in
silence
On Thu, Sep 27, 2012 at 6:08 PM, Sergio Pascual wrote:
> Hello, I'm trying to understand how to work with nditer to do a
> reduction, in my case converting a 3d array into a 2d array.
>
> I followed the help here
> http://docs.scipy.org/doc/numpy/reference/arrays.nditer.html and
> managed to creat
25 matches
Mail list logo
