numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] adding an attribute to an nd-array

[Travis O. <oli...@ee...>]

Stefan van der Walt wrote:

>On Wed, Oct 18, 2006 at 09:17:49PM -0400, Pierre GM wrote:
>  
>
>>On Wednesday 18 October 2006 20:29, Stefan van der Walt wrote:
>>    
>>
>>>A quick question on extending numpy arrays: is it possible to easily
>>>add an attribute to an ndarray?
>>>      
>>>
>>It might be easier to create a subclass: pleasehave a look here:
>>http://projects.scipy.org/scipy/numpy/attachment/wiki/MaskedArray/test_subclasses.py
>>That's a tiny example of subclassing ndarrays, with some extra attributes.
>>(BTW, I'm not sure that's the most obvious place where to look: if it turns 
>>out to be useful, I'll put it on the scipy wiki)
>>    
>>
>
>Thanks very much, Pierre.
>
>If I understand correctly, the following should work:
>
>import numpy as N
>
>class InfoArray(N.ndarray):
>    def __new__(info_arr_cls,arr,info={}):
>        info_arr_cls.info = info
>        return N.array(arr).view(info_arr_cls)
>
>When does __array_finalize__ get called, and is it always necessary to
>specify it?
>  
>

Actually something as simple as

class InfoArray(N.ndarray):
         pass

will allow you to add attributes to InfoArray.

I just learned about how to allow built-ins to have attributes assigned 
to their instances.   It's actually pretty easy because of Python 
support for it --- but it comes at a cost.  You have to add a dictionary 
to the PyArrayObject structure, create that dictionary when the ndarray 
is allocated, and set the tp_dictoffset in the TypeObject structure to 
its location in PyArrayObject.   It takes 4 lines of code with the cost of
creating a new dictionary for every ndarray.



I don't think the extra bytes for every ndarray object are worth it, 
given how easy it is to sub-class and create your own ndarray that can 
have attributes attached.    What are others opinions.

-Travis

P.S.  Here is the patch that adds it:


Index: numpy/core/include/numpy/ndarrayobject.h
===================================================================
--- numpy/core/include/numpy/ndarrayobject.h    (revision 3366)
+++ numpy/core/include/numpy/ndarrayobject.h    (working copy)
@@ -1172,6 +1172,7 @@
         PyArray_Descr *descr;   /* Pointer to type structure */
         int flags;              /* Flags describing array -- see below*/
         PyObject *weakreflist;  /* For weakreferences */
+        PyObject *instancedict; /* For instance attributes */
 } PyArrayObject;

 #define NPY_AO PyArrayObject
Index: numpy/core/src/arrayobject.c
===================================================================
--- numpy/core/src/arrayobject.c        (revision 3366)
+++ numpy/core/src/arrayobject.c        (working copy)
@@ -1906,6 +1906,8 @@
         if (self->weakreflist != NULL)
                 PyObject_ClearWeakRefs((PyObject *)self);

+        Py_DECREF(self->instancedict);
+
         if(self->base) {
                 /* UPDATEIFCOPY means that base points to an
                    array that should be updated with the contents
@@ -5305,6 +5307,7 @@
         self->descr = descr;
         self->base = (PyObject *)NULL;
         self->weakreflist = (PyObject *)NULL;
+        self->instancedict = PyDict_New();

         if (nd > 0) {
                 self->dimensions = PyDimMem_NEW(2*nd);
@@ -6689,7 +6692,7 @@
         0,                                        /* tp_dict */
         0,                                        /* tp_descr_get */
         0,                                        /* tp_descr_set */
-        0,                                        /* tp_dictoffset */
+        offsetof(PyArrayObject, instancedict),    /* tp_dictoffset */
         (initproc)0,                              /* tp_init */
         array_alloc,                              /* tp_alloc */
         (newfunc)array_new,                       /* tp_new */

Re: [Numpy-discussion] Product of an empty sequence

[Ivan V. i B. <iv...@ca...>]

En/na Travis Oliphant ha escrit::

> Ivan Vilata i Balaguer wrote:
>> Wouldn't be 0.0 a more natural answer?  I understand that 1 is neutral=

>> on product operations, but I still can't see why 1.0 is a better answe=
r.
>=20
> It's the identity for the multiplication ufunc. =20

OK, I guess that means it's something like an implicit ``initializer``
(as pointed by Alan) to ufunc reductions.  Thanks!  ::

>> (BTW, the definitions of ``prod()`` and ``product()`` are still
>> identical as noted by Sebastian Haase some time ago.)
>>  =20
> Is this a problem?

No, but it also caught my eye. :)

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] Unit test error with numpy rc3

[Travis O. <oli...@ee...>]

Tim Hochberg wrote:

>Travis Oliphant wrote:
>  
>
>>Tim Hochberg wrote:
>>  
>>    
>>
>>>Rudolph van der Merwe wrote:
>>>  
>>>    
>>>      
>>>
>>>>I get the following error with RC3 on a RHE Linux box:
>>>>
>>>>Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
>>>>[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
>>>>Type "help", "copyright", "credits" or "license" for more information.
>>>>  
>>>>    
>>>>      
>>>>        
>>>>
>>>>>>>import numpy
>>>>>>>numpy.__version__
>>>>>>>        
>>>>>>>          
>>>>>>>            
>>>>>>>              
>>>>>>>
>>>>'1.0rc3'
>>>>  
>>>>    
>>>>      
>>>>        
>>>>
>>>On a visual studio build, I'm getting a real failure though:
>>>
>>>    FAIL: Ticket #112
>>>    ----------------------------------------------------------------------
>>>    Traceback (most recent call last):
>>>      File
>>>    "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
>>>    line 219, in check_longfloat_repr
>>>        assert(str(a)[1:9] == str(a[0])[:8])
>>>    AssertionError
>>>
>>>The code in question is dependent on the spelling of INF(or at least the 
>>>*length* of the spelling) on a given platform which is why it's failing. 
>>>  
>>>    
>>>      
>>>
>>Actually, you shouldn't be getting an INF at all.    This is what the 
>>test is designed to test for (so I guess it's working).  The test was 
>>actually written wrong and was never failing because previously keyword 
>>arguments to ufuncs were ignored. 
>>
>>Can you show us what 'a' is on your platform.
>>    
>>
>Sure:
>
> >>> import numpy as N
> >>> a = N.exp(N.array([1000],dtype=N.longfloat))
>Warning: overflow encountered in exp
> >>> a
>array([1.#INF], dtype=float64)
>  
>
O.K.   We need to modify the test in case to check and see that the size 
of longfloat isn't the same as double.

-Travis

Re: [Numpy-discussion] Unit test error with numpy rc3

[Tim H. <tim...@ie...>]

Travis Oliphant wrote:
> Tim Hochberg wrote:
>   
>> Rudolph van der Merwe wrote:
>>   
>>     
>>> I get the following error with RC3 on a RHE Linux box:
>>>
>>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
>>> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>   
>>>     
>>>       
>>>>>> import numpy
>>>>>> numpy.__version__
>>>>>>         
>>>>>>           
>>>>>>             
>>> '1.0rc3'
>>>   
>>>     
>>>       
>> On a visual studio build, I'm getting a real failure though:
>>
>>     FAIL: Ticket #112
>>     ----------------------------------------------------------------------
>>     Traceback (most recent call last):
>>       File
>>     "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
>>     line 219, in check_longfloat_repr
>>         assert(str(a)[1:9] == str(a[0])[:8])
>>     AssertionError
>>
>> The code in question is dependent on the spelling of INF(or at least the 
>> *length* of the spelling) on a given platform which is why it's failing. 
>>   
>>     
>
> Actually, you shouldn't be getting an INF at all.    This is what the 
> test is designed to test for (so I guess it's working).  The test was 
> actually written wrong and was never failing because previously keyword 
> arguments to ufuncs were ignored. 
>
> Can you show us what 'a' is on your platform.
>   
I expect that the problem is related to this:

     >>> N.array([1000],dtype=N.float).dtype
    dtype('float64')
     >>> N.array([1000],dtype=N.longfloat).dtype
    dtype('float64')

longfloat appears to just be an alias for float under VS.

-tim


> -Travis
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>   

Re: [Numpy-discussion] Unit test error with numpy rc3

[Tim H. <tim...@ie...>]

Travis Oliphant wrote:
> Tim Hochberg wrote:
>   
>> Rudolph van der Merwe wrote:
>>   
>>     
>>> I get the following error with RC3 on a RHE Linux box:
>>>
>>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
>>> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>   
>>>     
>>>       
>>>>>> import numpy
>>>>>> numpy.__version__
>>>>>>         
>>>>>>           
>>>>>>             
>>> '1.0rc3'
>>>   
>>>     
>>>       
>> On a visual studio build, I'm getting a real failure though:
>>
>>     FAIL: Ticket #112
>>     ----------------------------------------------------------------------
>>     Traceback (most recent call last):
>>       File
>>     "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
>>     line 219, in check_longfloat_repr
>>         assert(str(a)[1:9] == str(a[0])[:8])
>>     AssertionError
>>
>> The code in question is dependent on the spelling of INF(or at least the 
>> *length* of the spelling) on a given platform which is why it's failing. 
>>   
>>     
>
> Actually, you shouldn't be getting an INF at all.    This is what the 
> test is designed to test for (so I guess it's working).  The test was 
> actually written wrong and was never failing because previously keyword 
> arguments to ufuncs were ignored. 
>
> Can you show us what 'a' is on your platform.
Sure:

 >>> import numpy as N
 >>> a = N.exp(N.array([1000],dtype=N.longfloat))
Warning: overflow encountered in exp
 >>> a
array([1.#INF], dtype=float64)

Re: [Numpy-discussion] recent ubuntu package

[Andrew S. <str...@as...>]

Sven Schreiber wrote:
> Andrew Straw schrieb:
>
>   
>> The matplotlib .deb on my website is working fine for me with the latest
>> numpy .deb there. If there are any recent patches or anything you are
>> missing, please let me know -- it's not really a big deal to update
>> them, although it might take a couple of days for me to find the time.
>>
>>
>>     
>
> Thanks for your answer. No, I'm not aware of any new features I would
> use, so that's ok for me. It just wasn't obvious to me why the builds
> are from in-between-releases devel versions, that's why I asked. After
> numpy 1.0 is released, are you planning to put up only official releases
> or also devel snapshots?
>   
With numpy, I currently use the most recent SVN version I can because I
want to help Travis testing for the 1.0 release. With that in mind, I
keep matplotlib and scipy relatively up-to-date as well in case there
have been any changes that those two have tracked. I'm not sure what
I'll do after the release of numpy 1.0. I do not intend to be on the
"bleeding edge" -- I use these repositories for a number of machines at
work. But if the leading edge isn't bleeding (as currently), it's quite
possible I'll keep updating them, particularly if features come out I'm
interested in. This would be a good reason for me to keep updating scipy
and matplotlib, even if I keep numpy more stable.

-Andrew

Re: [Numpy-discussion] Unit test error with numpy rc3

[Travis O. <oli...@ie...>]

Tim Hochberg wrote:
> Rudolph van der Merwe wrote:
>   
>> I get the following error with RC3 on a RHE Linux box:
>>
>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
>> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>   
>>     
>>>>> import numpy
>>>>> numpy.__version__
>>>>>         
>>>>>           
>> '1.0rc3'
>>   
>>     
>
> On a visual studio build, I'm getting a real failure though:
>
>     FAIL: Ticket #112
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>       File
>     "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
>     line 219, in check_longfloat_repr
>         assert(str(a)[1:9] == str(a[0])[:8])
>     AssertionError
>
> The code in question is dependent on the spelling of INF(or at least the 
> *length* of the spelling) on a given platform which is why it's failing. 
>   

Actually, you shouldn't be getting an INF at all.    This is what the 
test is designed to test for (so I guess it's working).  The test was 
actually written wrong and was never failing because previously keyword 
arguments to ufuncs were ignored. 

Can you show us what 'a' is on your platform.

-Travis

Re: [Numpy-discussion] Product of an empty sequence

[Travis O. <oli...@ie...>]

Ivan Vilata i Balaguer wrote:
> Today I was surprised by this::
>
>   
>>>> import numpy
>>>> numpy.__version__
>>>>         
> '1.0.dev3341'
>   
>>>> numpy.prod(())
>>>>         
> 1.0
>
> Wouldn't be 0.0 a more natural answer?  I understand that 1 is neutral
> on product operations, but I still can't see why 1.0 is a better answer.
>   

It's the identity for the multiplication ufunc.  

>  Sorry for the clueless question, but I have searched lists, docstrings
> and web and found nothing about this.
>
> (BTW, the definitions of ``prod()`` and ``product()`` are still
> identical as noted by Sebastian Haase some time ago.)
>   
Is this a problem?

-Travis

Re: [Numpy-discussion] adding an attribute to an nd-array

[Travis O. <oli...@ie...>]

Stefan van der Walt wrote:
> On Wed, Oct 18, 2006 at 09:17:49PM -0400, Pierre GM wrote:
>   
>> On Wednesday 18 October 2006 20:29, Stefan van der Walt wrote:
>>     
>>> A quick question on extending numpy arrays: is it possible to easily
>>> add an attribute to an ndarray?
>>>       
>> It might be easier to create a subclass: pleasehave a look here:
>> http://projects.scipy.org/scipy/numpy/attachment/wiki/MaskedArray/test_subclasses.py
>> That's a tiny example of subclassing ndarrays, with some extra attributes.
>> (BTW, I'm not sure that's the most obvious place where to look: if it turns 
>> out to be useful, I'll put it on the scipy wiki)
>>     
>
> Thanks very much, Pierre.
>
> If I understand correctly, the following should work:
>
> import numpy as N
>
> class InfoArray(N.ndarray):
>     def __new__(info_arr_cls,arr,info={}):
>         info_arr_cls.info = info
>         return N.array(arr).view(info_arr_cls)
>
> When does __array_finalize__ get called, and is it always necessary to
> specify it?
>   
It gets called whenever a new array is created.  No, it is not necessary 
to specify it.

-Travis

Re: [Numpy-discussion] Unit test error with numpy rc3

[Tim H. <tim...@ie...>]

Rudolph van der Merwe wrote:
> I get the following error with RC3 on a RHE Linux box:
>
> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>   
>>>> import numpy
>>>> numpy.__version__
>>>>         
> '1.0rc3'
>   
[SNIP lots of warnings]

Ah! I see that Travis has turned up the default warning level. 
Excellent! This will require some tweaking of the tests, but that 
shouldn't be a big deal. If I have time I will try to work on that later 
today. For the moment, try this:

     >>> olderr = numpy.seterr(all='ignore')
     >>> numpy.test()
     >>> numpy.seterr(*olderr)

This should run the tests with the warnings suppressed.

On a visual studio build, I'm getting a real failure though:

    FAIL: Ticket #112
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File
    "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
    line 219, in check_longfloat_repr
        assert(str(a)[1:9] == str(a[0])[:8])
    AssertionError

The code in question is dependent on the spelling of INF(or at least the 
*length* of the spelling) on a given platform which is why it's failing. 
I suspect that the correct test is:
    str(a)[1:-1] == str(a[0])
However, I'm not entirely sure what this is testing, so I'm reluctant to 
check that in.

-tim

Re: [Numpy-discussion] Product of an empty sequence

[Alan G I. <ai...@am...>]

On Thu, 19 Oct 2006, Ivan Vilata i Balaguer apparently wrote:=20
>>>> numpy.prod(())=20
> 1.0
> Wouldn't be 0.0 a more natural answer?

I think it must be 1 or a TypeError.  E.g.,
http://docs.python.org/lib/built-in-funcs.html#reduce
reduce(function, sequence[, initializer])
    Apply function of two arguments cumulatively to the=20
    items of sequence, from left to right, so as to reduce=20
    the sequence to a single value. For example,=20
    reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates=20
    ((((1+2)+3)+4)+5). The left argument, x, is the=20
    accumulated value and the right argument, y, is the=20
    update value from the sequence. If the optional=20
    initializer is present, it is placed before the items of=20
    the sequence in the calculation, and serves as a default=20
    when the sequence is empty. If initializer is not given=20
    and sequence contains only one item, the first item is=20
    returned.

hth,
Alan Isaac
(just a user)

Re: [Numpy-discussion] recent ubuntu package

[Sven S. <sve...@gm...>]

Andrew Straw schrieb:

> The matplotlib .deb on my website is working fine for me with the latest
> numpy .deb there. If there are any recent patches or anything you are
> missing, please let me know -- it's not really a big deal to update
> them, although it might take a couple of days for me to find the time.
> 
>

Thanks for your answer. No, I'm not aware of any new features I would
use, so that's ok for me. It just wasn't obvious to me why the builds
are from in-between-releases devel versions, that's why I asked. After
numpy 1.0 is released, are you planning to put up only official releases
or also devel snapshots?

thanks, sven

[Numpy-discussion] Unit test error with numpy rc3

[Rudolph v. d. M. <rud...@gm...>]

I get the following error with RC3 on a RHE Linux box:

Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'1.0rc3'
>>> numpy.test()
  Found 5 tests for numpy.distutils.misc_util
  Found 3 tests for numpy.lib.getlimits
  Found 31 tests for numpy.core.numerictypes
  Found 32 tests for numpy.linalg
  Found 13 tests for numpy.core.umath
  Found 4 tests for numpy.core.scalarmath
  Found 9 tests for numpy.lib.arraysetops
  Found 42 tests for numpy.lib.type_check
  Found 183 tests for numpy.core.multiarray
  Found 3 tests for numpy.fft.helper
  Found 36 tests for numpy.core.ma
  Found 12 tests for numpy.lib.twodim_base
  Found 10 tests for numpy.core.defmatrix
  Found 1 tests for numpy.lib.ufunclike
  Found 4 tests for numpy.ctypeslib
  Found 41 tests for numpy.lib.function_base
  Found 2 tests for numpy.lib.polynomial
  Found 8 tests for numpy.core.records
  Found 26 tests for numpy.core.numeric
  Found 4 tests for numpy.lib.index_tricks
  Found 47 tests for numpy.lib.shape_base
  Found 0 tests for __main__
.......................................................................................................Warning:
invalid value encountered in divide
..Warning: invalid value encountered in divide
..Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
..Warning: invalid value encountered in divide
.Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
..Warning: invalid value encountered in divide
..Warning: invalid value encountered in divide
..Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
.Warning: divide by zero encountered in divide
........Warning: invalid value encountered in divide
.Warning: invalid value encountered in divide
..Warning: divide by zero encountered in divide
........................................................................................................................................................................................................Warning:
divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
Warning: divide by zero encountered in divide
.....................Warning: invalid value encountered in sqrt
Warning: invalid value encountered in log
Warning: invalid value encountered in log10
..Warning: invalid value encountered in sqrt
Warning: invalid value encountered in sqrt
Warning: divide by zero encountered in log
Warning: divide by zero encountered in log
Warning: divide by zero encountered in log10
Warning: divide by zero encountered in log10
Warning: invalid value encountered in arcsin
Warning: invalid value encountered in arcsin
Warning: invalid value encountered in arccos
Warning: invalid value encountered in arccos
Warning: invalid value encountered in arccosh
Warning: invalid value encountered in arccosh
Warning: divide by zero encountered in arctanh
Warning: divide by zero encountered in arctanh
Warning: invalid value encountered in divide
Warning: invalid value encountered in true_divide
Warning: invalid value encountered in floor_divide
Warning: invalid value encountered in remainder
Warning: invalid value encountered in fmod
...............................................................................................................................................................
----------------------------------------------------------------------
Ran 516 tests in 0.368s

OK
<unittest.TextTestRunner object at 0xb7abf46c>
>>>

-- 
Rudolph van der Merwe
KAT (Karoo Array Telescope) / www.kat.ac.za

[Numpy-discussion] Product of an empty sequence

[Ivan V. i B. <iv...@ca...>]

Today I was surprised by this::

>>> import numpy
>>> numpy.__version__
'1.0.dev3341'
>>> numpy.prod(())
1.0

Wouldn't be 0.0 a more natural answer?  I understand that 1 is neutral
on product operations, but I still can't see why 1.0 is a better answer.
 Sorry for the clueless question, but I have searched lists, docstrings
and web and found nothing about this.

(BTW, the definitions of ``prod()`` and ``product()`` are still
identical as noted by Sebastian Haase some time ago.)

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] adding an attribute to an nd-array

[Stefan v. d. W. <st...@su...>]

On Wed, Oct 18, 2006 at 09:17:49PM -0400, Pierre GM wrote:
> On Wednesday 18 October 2006 20:29, Stefan van der Walt wrote:
> > A quick question on extending numpy arrays: is it possible to easily
> > add an attribute to an ndarray?
>=20
> It might be easier to create a subclass: pleasehave a look here:
> http://projects.scipy.org/scipy/numpy/attachment/wiki/MaskedArray/test_=
subclasses.py
> That's a tiny example of subclassing ndarrays, with some extra attribut=
es.
> (BTW, I'm not sure that's the most obvious place where to look: if it t=
urns=20
> out to be useful, I'll put it on the scipy wiki)

Thanks very much, Pierre.

If I understand correctly, the following should work:

import numpy as N

class InfoArray(N.ndarray):
    def __new__(info_arr_cls,arr,info=3D{}):
        info_arr_cls.info =3D info
        return N.array(arr).view(info_arr_cls)

When does __array_finalize__ get called, and is it always necessary to
specify it?

Cheers
St=E9fan

Re: [Numpy-discussion] Conditional tests for test classes derived from NumpyTest

[<pe...@ce...>]

On Thu, 19 Oct 2006, David Cournapeau wrote:

> Hi,
> 
>     Is there a simple way to execute tests inherited from NumpyTest 
> conditionally ? I have something like that for now:
> 
>     class test_c_implementation(NumpyTestCase):
>         def _check(self, level, decimal = 12):
>             try:
>                 from foo import bar
>                 Y   = bar()
>             except ImportError, inst:
>                 print "Error while importing bar, not tested"
>                 print " -> (Import error was %s)" % inst
> 
>     And all checking functions of the class call _check. The problem is 
> that if there are 10 check functions, there are 10 errors reported, 
> which is a bit stupid,

One approach is demonstrated in scipy/Lib/lib/blas/tests/test_fblas.py.
In your case:

class base_test_c_implementation:
    def check_bar(self, level, decimal=12):
        Y = bar()

try:
    from foo import bar
    class test_c_implementation(base_test_c_implementation,NumpyTestCase):
        pass
except ImportError, inst:
    print "Error while importing bar, not tested"
    print " -> (Import error was %s)" % inst


Pearu

[Numpy-discussion] Conditional tests for test classes derived from NumpyTest

[David C. <da...@ar...>]

Hi,

    Is there a simple way to execute tests inherited from NumpyTest 
conditionally ? I have something like that for now:

    class test_c_implementation(NumpyTestCase):
        def _check(self, level, decimal = 12):
            try:
                from foo import bar
                Y   = bar()
            except ImportError, inst:
                print "Error while importing bar, not tested"
                print " -> (Import error was %s)" % inst

    And all checking functions of the class call _check. The problem is 
that if there are 10 check functions, there are 10 errors reported, 
which is a bit stupid,

    cheers,

    David

Re: [Numpy-discussion] adding an attribute to an nd-array

[Pierre GM <pgm...@gm...>]

On Wednesday 18 October 2006 20:29, Stefan van der Walt wrote:
> A quick question on extending numpy arrays: is it possible to easily
> add an attribute to an ndarray?

It might be easier to create a subclass: pleasehave a look here:
http://projects.scipy.org/scipy/numpy/attachment/wiki/MaskedArray/test_subclasses.py
That's a tiny example of subclassing ndarrays, with some extra attributes.
(BTW, I'm not sure that's the most obvious place where to look: if it turns 
out to be useful, I'll put it on the scipy wiki)

Re: [Numpy-discussion] sort(axis=-1)

[Christian K. <ck...@ho...>]

Travis Oliphant <oliphant.travis <at> ieee.org> writes:

> 
> Christian Kristukat wrote:
> > Hi,
> >
> > it seems that -1 as axis parameter is interpreted like in array indexing, 
> > -1 means the last axis rather than meaning the only axis of the flattened
> > representation, like for example with take().
> > Is that intendend?
> >
> >   
> 
> I don't understand the question.   Yes, sort(axis=-1) sorts along the 
> last dimension.
> 
> AFAIK, take has the same meaning for axis.

Oh sure, I mixed that up with axis=None as Robert pointed out. However I don't
understand why axis=None wouldn't make sense for an inplace operation. Anyway,
it's not important. Sorry for the noise.

Christian

[Numpy-discussion] adding an attribute to an nd-array

[Stefan v. d. W. <st...@su...>]

A quick question on extending numpy arrays: is it possible to easily
add an attribute to an ndarray?

With Python-defined classes one can do

class X(object):
    pass

x =3D X()
x.foo =3D 'bar'

but with ndarrays you get

x =3D N.array([1,2,3])
x.foo =3D 'bar'

AttributeError: 'numpy.ndarray' object has no attribute 'foo'

Is there an easy way around this (without writing a C extension)?

Thanks for any advice.
St=E9fan

Re: [Numpy-discussion] Question about indexing arrays with boolean arrays

[Michael S. <mic...@gm...>]

On 10/18/06, Daniel Arbuckle <dj...@hi...> wrote:
> Why does a[b1, b2] not mean the same thing as a[b1][:, b2], when "a"
> is an array and "b1" and "b2" are appropriately sized arrays of
> booleans?

>From my previous experience with R I am used to a[b1, b2] being
equivalent to a[b1][:, b2], so this is a little strange to me as well.
In numpy I think you need to use the function ix_ to get the cross
product.

e.g. a[ix_(b1,b2)] is equivalent to a[b1][:, b2]

a[b1,b2] raises an error about a type mismatch. I have no idea what
this syntax is supposed to do in numpy.

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

[Charles R H. <cha...@gm...>]

On 10/18/06, Travis Oliphant <oli...@ee...> wrote:
>
> Charles R Harris wrote:
>
> >
> >
> > On 10/18/06, *Travis Oliphant* <oli...@ee...
> > <mailto:oli...@ee...>> wrote:
> >
> >     Charles R Harris wrote:
> >
> >     > Well, I knew that for numeric, but it was a good deal less
> >     obvious in
> >     > combo with the order keyword.  For instance, contiguous could
> change
> >     > its meaning to match up with FORTRAN, so that FORTRAN=True and
> >     > CONTIGUOUS=True meant Fortran contiguous, which was sort of what
> >     I was
> >     > thinking. Explicit never hurts.
> >
> >
> >     Ahh, so you were confused by looking at flags for 1-d arrays (where
> >
> >
> > More confused by what seemed to make sense to me. Tim was the one who
> > actually ran the experiment to see what was going on, and he wasn't
> > sure what FORTRAN meant either. Now if I had accessed the full set of
> > offsets, strides, and counts, it would all have become clear. Numpy
> > tries to hide the nasty details, which is good until you really have
> > to know what it happening underneath.
>
> I've done as you requested.  I've added F_CONTIGUOUS as an alias to
> FORTRAN and C_CONTIGUOUS as an alias to CONTIGUOUS.  These are the names
> that show up when you print the flags and you can use them whenever you
> used the other names.  The other names are still everywhere in the code,
> but perhaps the existence of these aliases will help people understand
> what is meant better.


Thanks, Travis. I really appreciate your willingness to make such
modifications.

Chuck

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

[Travis O. <oli...@ee...>]

Charles R Harris wrote:

>
>
> On 10/18/06, *Travis Oliphant* <oli...@ee... 
> <mailto:oli...@ee...>> wrote:
>
>     Charles R Harris wrote:
>
>     > Well, I knew that for numeric, but it was a good deal less
>     obvious in
>     > combo with the order keyword.  For instance, contiguous could change
>     > its meaning to match up with FORTRAN, so that FORTRAN=True and
>     > CONTIGUOUS=True meant Fortran contiguous, which was sort of what
>     I was
>     > thinking. Explicit never hurts.
>
>
>     Ahh, so you were confused by looking at flags for 1-d arrays (where
>
>
> More confused by what seemed to make sense to me. Tim was the one who 
> actually ran the experiment to see what was going on, and he wasn't 
> sure what FORTRAN meant either. Now if I had accessed the full set of 
> offsets, strides, and counts, it would all have become clear. Numpy 
> tries to hide the nasty details, which is good until you really have 
> to know what it happening underneath.

I've done as you requested.  I've added F_CONTIGUOUS as an alias to 
FORTRAN and C_CONTIGUOUS as an alias to CONTIGUOUS.  These are the names 
that show up when you print the flags and you can use them whenever you 
used the other names.  The other names are still everywhere in the code, 
but perhaps the existence of these aliases will help people understand 
what is meant better.

-Travis

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

[Charles R H. <cha...@gm...>]

On 10/18/06, Travis Oliphant <oli...@ee...> wrote:
>
> Charles R Harris wrote:
>
> > Well, I knew that for numeric, but it was a good deal less obvious in
> > combo with the order keyword.  For instance, contiguous could change
> > its meaning to match up with FORTRAN, so that FORTRAN=True and
> > CONTIGUOUS=True meant Fortran contiguous, which was sort of what I was
> > thinking. Explicit never hurts.
>
>
> Ahh, so you were confused by looking at flags for 1-d arrays (where


More confused by what seemed to make sense to me. Tim was the one who
actually ran the experiment to see what was going on, and he wasn't sure
what FORTRAN meant either. Now if I had accessed the full set of offsets,
strides, and counts, it would all have become clear. Numpy tries to hide the
nasty details, which is good until you really have to know what it happening
underneath.

Chuck

Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

[Travis O. <oli...@ee...>]

Charles R Harris wrote:

> Well, I knew that for numeric, but it was a good deal less obvious in 
> combo with the order keyword.  For instance, contiguous could change 
> its meaning to match up with FORTRAN, so that FORTRAN=True and 
> CONTIGUOUS=True meant Fortran contiguous, which was sort of what I was 
> thinking. Explicit never hurts.


Ahh, so you were confused by looking at flags for 1-d arrays (where 
indeed both CONTIGUOUS and FORTRAN can be True --- 1-d arrays that are 
CONTIGUOUS are also FORTRAN CONTIGUOUS).

-Travis