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
Albert Strasheim wrote:
> Hello all
>
> For my Summer of Code project, I'm adding Support Vector Machine code to
> SciPy. Underneath, I'm currently using libsvm. Thus far, I've been compiling
> libsvm as a shared library (DLL on Windows) using SCons and doing the
> wrapping with ctypes.
>
> Now,
I'm just starting with numpy (via scipy) and I'm wanting to perform
adaptive thresholding
(http://www.cee.hw.ac.uk/hipr/html/adpthrsh.html) on an image.
Basically that means that I need to get a threshold for each pixel by
examining the pixels around it. In numpy this translates to finding
the adja
Thanks for your response to the questionaire.
>>3) Please, explain your reason(s) for not making the switch. (if
>>you answered No to #2)
>>
>>
>
>Lack of time. Some of the changes from Numeric are subtle and require
>a careful analysis of the code, and then careful testing. For big
>ap
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
Andrew Straw wrote:
> Christopher Barker wrote:
>> Joe Harrington wrote:
>>> My
>>> suggestion is that all the other pages be automatic redirects to the
>>> scipy.org page or subpages thereof.
>> if that means something like:
>>
>> www.numpy.scipy.org (or www.scipy.org/numpy )
>> Then I'm all fo
On 6/9/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> > This difference is so dramatic that I think a message is justified
> > (absent a proper logging framework). It's helpful to know that the
> > time is going into c++ compilation, and not your code hanging for 30
> > seconds.
>
> Ok, I'll giv
David M. Cooke wrote:
>On Fri, 9 Jun 2006 15:19:14 -0600
>"Fernando Perez" <[EMAIL PROTECTED]> wrote:
>
>
>
>>On 6/9/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>>
>>
>>>On Thu, Jun 08, 2006 at 11:28:04PM -0600, Fernando Perez wrote:
>>>
>>>
Anyone object to this patch against cu
On Fri, 9 Jun 2006 15:19:14 -0600
"Fernando Perez" <[EMAIL PROTECTED]> wrote:
> On 6/9/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 08, 2006 at 11:28:04PM -0600, Fernando Perez wrote:
>
> > > Anyone object to this patch against current numpy SVN to get rid of
> > > this thing? (t
On 6/9/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 08, 2006 at 11:28:04PM -0600, Fernando Perez wrote:
> > Anyone object to this patch against current numpy SVN to get rid of
> > this thing? (tracking where the hell that thing was coming from was
> > all kinds of fun)
>
> Go ahead.
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
For my Summer of Code project, I'm adding Support Vector Machine code to
SciPy. Underneath, I'm currently using libsvm. Thus far, I've been compiling
libsvm as a shared library (DLL on Windows) using SCons and doing the
wrapping with ctypes.
Now, I would like to integrate my code into t
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
>
> atlas_info:
> ( library_dirs = /usr/local/lib:/usr/lib )
> ( paths: /usr/lib/atlas,/usr/lib/sse2 )
> looking libraries f77blas,cblas,atlas in /usr/local/lib but found None
> looking libraries f77blas,cblas,atlas in /usr/local/lib but found None
(.. more
On Thu, Jun 08, 2006 at 11:28:04PM -0600, Fernando Perez wrote:
> Hi all,
>
> the following warning about strict-prototypes in weave drives me crazy:
>
> longs[~]> python wbuild.py
>
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid
> for Ada/C/ObjC but not for C++
>
> sinc
Hi all,
the following warning about strict-prototypes in weave drives me crazy:
longs[~]> python wbuild.py
cc1plus: warning: command line option "-Wstrict-prototypes" is valid
for Ada/C/ObjC but not for C++
since I use weave on auto-generated code, I get it lots of times and I
find spurious war
33 matches
Mail list logo
