On 2/1/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
Zachary Pincus wrote:
> Say a function that (despite Tim's pretty
> reasonable 'don't do that' warning) will return true when two arrays
> have overlapping memory?
I think it would be useful, even if it's not robust. I'd still like to
kno
Christopher Barker wrote:
>Zachary Pincus wrote:
>
>
>>Say a function that (despite Tim's pretty
>>reasonable 'don't do that' warning) will return true when two arrays
>>have overlapping memory?
>>
>>
>
>I think it would be useful, even if it's not robust. I'd still like to
>know if a g
Zachary Pincus wrote:
> Say a function that (despite Tim's pretty
> reasonable 'don't do that' warning) will return true when two arrays
> have overlapping memory?
I think it would be useful, even if it's not robust. I'd still like to
know if a given two arrays COULD share data.
I suppose to
Zachary Pincus wrote:
>>>A question, then: Does this represent a bug? Or perhaps there is a
>>>better idiom for modifying an array in-place than 'a[:] = ...'? Or is
>>>incumbent on the user to ensure that any time an array is directly
>>>modified, that the modifying array is not a view of the orig
Zachary Pincus wrote:
>>> I recently was trying to write code to modify an array in-place (so
>>> as not to invalidate any references to that array)
>> I'm not sure what this means exactly.
>
> Say one wants to keep two different variables referencing a single in-
> memory list, as so:
> a = [1,2
>> A question, then: Does this represent a bug? Or perhaps there is a
>> better idiom for modifying an array in-place than 'a[:] = ...'? Or is
>> incumbent on the user to ensure that any time an array is directly
>> modified, that the modifying array is not a view of the original
>> array?
>>
>>
Zachary Pincus wrote:
>Hello folks,
>
>I recently was trying to write code to modify an array in-place (so
>as not to invalidate any references to that array) via the standard
>python idiom for lists, e.g.:
>
>a[:] = numpy.flipud(a)
>
>Now, flipud returns a view on 'a', so assigning that to 'a
On 2/1/07, Zachary Pincus <[EMAIL PROTECTED]> wrote:
[CHOP]
I think that this is is unquestionably a bug
It's not a bug. It's a design decision. It has certain consequences. Many
good, some bad and some that just take some getting used to.
-- isn't the point of
views that the user shouldn't
> Zachary Pincus wrote:
>> Hello folks,
>>
>> I recently was trying to write code to modify an array in-place (so
>> as not to invalidate any references to that array)
>
> I'm not sure what this means exactly.
Say one wants to keep two different variables referencing a single in-
memory list, as
Zachary Pincus wrote:
> Hello folks,
>
> I recently was trying to write code to modify an array in-place (so
> as not to invalidate any references to that array)
I'm not sure what this means exactly.
> via the standard
> python idiom for lists, e.g.:
>
> a[:] = numpy.flipud(a)
>
> Now, fli
On 01/02/07, Zachary Pincus <[EMAIL PROTECTED]> wrote:
> I recently was trying to write code to modify an array in-place (so
> as not to invalidate any references to that array) via the standard
> python idiom for lists, e.g.:
You can do this, but if your concern is invalidating references, you
m
Hello folks,
I recently was trying to write code to modify an array in-place (so
as not to invalidate any references to that array) via the standard
python idiom for lists, e.g.:
a[:] = numpy.flipud(a)
Now, flipud returns a view on 'a', so assigning that to 'a[:]'
provides pretty strange r
12 matches
Mail list logo
