It sounds like there are no objections and this has a strong chance to fix the
problems.We will put it on the TODO list for 1.7.0 release.
-Travis
On Sep 30, 2012, at 9:30 PM, Charles R Harris wrote:
>
>
> On Sun, Sep 30, 2012 at 1:59 PM, Travis Oliphant wrote:
> Hey all,
>
> In a gi
On Sun, Sep 30, 2012 at 8:30 PM, Charles R Harris wrote:
>
>
> On Sun, Sep 30, 2012 at 1: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 al
On Sun, Sep 30, 2012 at 1: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
Announcement: scikits-image 0.7.0
=
We're happy to announce the 7th version of scikits-image!
Scikits-image is an image processing toolbox for SciPy that includes
algorithms
for segmentation, geometric transformations, color space manipulation,
analysis, filtering,
--
Travis Oliphant
(on a mobile)
512-826-7480
On Sep 30, 2012, at 4:00 PM, Han Genuit wrote:
> On Sun, Sep 30, 2012 at 10:55 PM, Travis Oliphant wrote:
>> I think you are misunderstanding the proposal. The proposal is to traverse
>> the views as far as you can but stop just short of havin
On Sun, Sep 30, 2012 at 10:30:52PM +0200, Han Genuit wrote:
> Also, considering that this behaviour already exists in past versions
> of NumPy, namely 1.6,
I just checked: in numpy 1.6.1, the behaviour is to create an endless
chain of base.base.base...
In some sens, what Travis is proposing is go
On Sun, Sep 30, 2012 at 10:55 PM, Travis Oliphant wrote:
> I think you are misunderstanding the proposal. The proposal is to traverse
> the views as far as you can but stop just short of having base point to an
> object of a different type.
>
> This fixes the infinite chain of views problem bu
I think you are misunderstanding the proposal. The proposal is to traverse
the views as far as you can but stop just short of having base point to an
object of a different type.
This fixes the infinite chain of views problem but also fixes the problem
sklearn was having with base pointing to
On Sun, Sep 30, 2012 at 10:35 PM, Travis Oliphant wrote:
> We are not talking about changing it "back". The change in 1.6 caused
> problems that need to be addressed.
>
> Can you clarify your concerns? The proposal is not a major change to the
> behavior on master, but it does fix a real issue
We are not talking about changing it "back". The change in 1.6 caused problems
that need to be addressed.
Can you clarify your concerns? The proposal is not a major change to the
behavior on master, but it does fix a real issue.
--
Travis Oliphant
(on a mobile)
512-826-7480
On Sep 30, 2012,
On Sun, Sep 30, 2012 at 9: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
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
immediate" array object parent for arrays that did not o
As always, I think it is better to don't change the default behaviour.
There is many people that don't update frequently and 2 releases is
not enough. This will lead to many hard to find bug. This will also
give the impression what we can't rely on numpy default behaviour and
numpy is not stable.
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 semantics indefinitely?
Have np.copy take an 'order=None', which w
There are three basic Python APIs to copy an array in numpy:
a.copy(): has always returned a C-contiguous array by default. has
always taken an order= argument, which defaults to "C".
np.array(a, copy=True): by default, produces an array with whatever
memory ordering that 'a' had. Can also spe
On Sat, Sep 29, 2012 at 03:09:08PM -0700, Ondřej Čertík wrote:
> Chuck, Gael, here is my todo list for the 1.7.0 release:
> https://github.com/numpy/numpy/issues/396
I have created issues and mentionned them in the comments on your issue.
Cheers,
Gaël
___
Ondřej Čertík gmail.com> writes:
>
> On Tue, Sep 4, 2012 at 8:38 PM, Travis Oliphant continuum.io>
> wrote:
> I think the test should be changed to check for RuntimeWarning on some of
> the cases. This might take a little work as it looks like the code uses
> generators across multiple tests
For convenience and clarity, this is the diff in question:
https://github.com/Dynetrekk/numpy-1/commit/5bde67531a2005ef80a2690a75c65cebf97c9e00
And this is my numpy fork:
https://github.com/Dynetrekk/numpy-1/
Paul
On Sun, Sep 30, 2012 at 4:14 PM, Paul Anton Letnes
wrote:
> Hello everyone,
>
>
18 matches
Mail list logo
