Thomas Heller wrote:
> Robert Kern wrote:
>
>> Francesc Altet wrote:
>>
>>> A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure:
>>>
>>>
Just out of curiosity:
In [1]: x = N.array([])
In [2]: x.__array_data__
Out[2]: ('0x01C23EE0', False)
>
A Divendres 16 Juny 2006 21:25, Thomas Heller va escriure:
> Robert Kern wrote:
> > Like how Win64 uses 32-bit longs and 64-bit pointers. And then there's
> > signedness. Please don't use Python ints to encode pointers. Holding
> > arbitrary pointers is the job of CObjects.
>
> (Sorry, I'm late in
Robert Kern wrote:
> Francesc Altet wrote:
>> A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure:
>>
>>>Just out of curiosity:
>>>
>>>In [1]: x = N.array([])
>>>
>>>In [2]: x.__array_data__
>>>Out[2]: ('0x01C23EE0', False)
>>>
>>>Is there a reason why the __array_data__ tuple stores the
OK, here's another (semi-crazy) idea:
__array_struct__ is the interface. ctypes lets us use it in "pure"
Python. We provide a "reference implementation" so that newbies don't
get segfaults.
___
Numpy-discussion mailing list
Numpy-discussion@lists.sou
David M. Cooke wrote:
>On Fri, 09 Jun 2006 16:03:32 -0700
>Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>
>
>>Tim Hochberg wrote:
>>
>>
>>
>>>Which of the following should we require for an object to be "supporting
>>>the array interface"? Here a producer is something that supplies
>>>array_s
On Fri, 09 Jun 2006 16:03:32 -0700
Andrew Straw <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
>
> >Which of the following should we require for an object to be "supporting
> >the array interface"? Here a producer is something that supplies
> >array_struct or array_interface (where the latter
Tim Hochberg wrote:
>Which of the following should we require for an object to be "supporting
>the array interface"? Here a producer is something that supplies
>array_struct or array_interface (where the latter is the Python level
>version of the former as per recent messages). Consumers do som
Which of the following should we require for an object to be "supporting
the array interface"? Here a producer is something that supplies
array_struct or array_interface (where the latter is the Python level
version of the former as per recent messages). Consumers do something
with the results
Travis Oliphant wrote:
>Tim Hochberg wrote:
>
>
>
>>I was going to say that it may help to think of array_interface as
>>returning a *view*, since that seems to be the semantics that could
>>probably be implemented safely without too much trouble. However, it
>>looks like that's not what happ
On Fri, 09 Jun 2006 12:08:51 -0600
Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
>
> > Sasha wrote:
> >
> >> On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>
> >>>
> >>
> >> My problem with __array_struct__ returning either a tuple or a CObject
> >> is that array prot
Travis Oliphant wrote:
> Andrew Straw wrote:
>
>> On the one hand, I feel we should keep __array_struct__ behaving
>> exactly as it is now. There's already lots of code that uses it, and
>> it's tremendously useful despite (because of?) it's simplicity. For
>> these of use cases, the __array_de
Tim Hochberg wrote:
>I was going to say that it may help to think of array_interface as
>returning a *view*, since that seems to be the semantics that could
>probably be implemented safely without too much trouble. However, it
>looks like that's not what happens. array_interface->shape and stri
Sasha wrote:
>On 6/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>>... In NumPy this is not quite the rule followed.
>>Bascially attributes are used when getting or setting intrinsinc
>>"properties" of the array. Attributes are used for properties that are
>>important in defining what
On the one hand, I feel we should keep __array_struct__ behaving exactly
as it is now. There's already lots of code that uses it, and it's
tremendously useful despite (because of?) it's simplicity. For these of
use cases, the __array_descr__ information has already proven
unnecessary. I must sa
On 6/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> ... In NumPy this is not quite the rule followed.
> Bascially attributes are used when getting or setting intrinsinc
> "properties" of the array. Attributes are used for properties that are
> important in defining what an array *is*. The
On 6/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> ... In NumPy this is not quite the rule followed.
> Bascially attributes are used when getting or setting intrinsinc
> "properties" of the array. Attributes are used for properties that are
> important in defining what an array *is*. The
Tim Hochberg wrote:
> Sasha wrote:
>
>> On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>>
>>
>>> ...
>>> +0 for name change; I'm happy with it as an attribute.
>>>
>>>
>>
>> My rule of thumb for choosing between an attribute and a method is
>> that attribute access should not create new
Sasha wrote:
>On 6/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>>Sasha wrote:
>>...
>>
>>
>>>My rule of thumb for choosing between an attribute and a method is
>>>that attribute access should not create new objects.
>>>
>>>
>>>
>>Conceptually at least, couldn't there be a single
Albert Strasheim wrote:
>Hello all
>
>
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:numpy-
>>[EMAIL PROTECTED] On Behalf Of Travis Oliphant
>>Sent: 08 June 2006 22:27
>>To: numpy-discussion
>>Subject: [Numpy-discussion] Array Protocol change for Python 2.6
>>
>>...
>>
>>I wou
On 6/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Shouldn't pure python implementations
> just provide __array__?
>
You cannot implement __array__ without importing numpy.
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https
On 6/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Sasha wrote:
> ...
> >>
> >My rule of thumb for choosing between an attribute and a method is
> >that attribute access should not create new objects.
> >
> Conceptually at least, couldn't there be a single __array_interface__
> object associated
Francesc Altet wrote:
> A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure:
>
>>Just out of curiosity:
>>
>>In [1]: x = N.array([])
>>
>>In [2]: x.__array_data__
>>Out[2]: ('0x01C23EE0', False)
>>
>>Is there a reason why the __array_data__ tuple stores the address as a hex
>>string? I wo
Sasha wrote:
>On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>
>
>>...
>>+0 for name change; I'm happy with it as an attribute.
>>
>>
>>
>My rule of thumb for choosing between an attribute and a method is
>that attribute access should not create new objects.
>
Conceptually at least, co
A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure:
> Just out of curiosity:
>
> In [1]: x = N.array([])
>
> In [2]: x.__array_data__
> Out[2]: ('0x01C23EE0', False)
>
> Is there a reason why the __array_data__ tuple stores the address as a hex
> string? I would guess that this representa
Hello all
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:numpy-
> [EMAIL PROTECTED] On Behalf Of Travis Oliphant
> Sent: 08 June 2006 22:27
> To: numpy-discussion
> Subject: [Numpy-discussion] Array Protocol change for Python 2.6
>
> ...
>
> I would like to eliminate all the other
On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> ...
> +0 for name change; I'm happy with it as an attribute.
>
My rule of thumb for choosing between an attribute and a method is
that attribute access should not create new objects. In addition, to
me __array_interface__ feels like a generali
Sasha wrote:
>On 6/8/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>>...
>>__array_struct__ (perhaps we could call this __array_interface__ but
>>I'm happy keeping the name the same too.)
>>
>>
>
>+0 on the name change and consider making it a method rather than an attribute.
>
>
I'
On Thu, 8 Jun 2006 17:07:55 -0400
Sasha <[EMAIL PROTECTED]> wrote:
> On 6/8/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> > ...
> > __array_struct__ (perhaps we could call this __array_interface__ but
> > I'm happy keeping the name the same too.)
>
> +0 on the name change and consider making
On 6/8/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> ...
> __array_struct__ (perhaps we could call this __array_interface__ but
> I'm happy keeping the name the same too.)
+0 on the name change and consider making it a method rather than an attribute.
>
> If __array_struct__ is a CObject the
29 matches
Mail list logo
