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

Re: [Numpy-discussion] Learning "strides"

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

Sasha wrote:

>I don't know if this came from numarray or not, but for me as someone
>who transitions from Numeric, the "strides" attribute to an ndarray is
>a a new feature.  I've spend some time playing with it and there are
>some properties that I dislike. Some of these undesired  properties
>are probably bugs and easy to fix, but others require some discussion.
>  
>
Of course strides have always been there, they've just never been 
visible from Python. 

Allowing the user to set the strides may not be a good idea.  It was 
done largely so that the code that deals with misaligned data could be 
tested.    However, it also allows you a lot of flexibility for 
interacting with arbitrary data-buffers that might be useful, so I'm 
inclined to allow it if the possible problems can be fixed.

Users that set strides will have to know what they are doing, of 
course.  The average user wouldn't bother with it.

>1. Negative strides:
>
>  
>
>>>>x = zeros(5)
>>>>x.strides= (-4,)
>>>>x
>>>>        
>>>>
>array([         0,         25,          0, -136009696, -136009536])
>
>Looks like a bug.  PyArray_CheckStrides only checks for one end of the
>buffer.  
>
Right.  PyArray_CheckStrides needs to be better or we can't allow 
negative strides.

>  
>
>3.  "Fractional" strides:
>I call "fractional" strides that are not a multiple of "itemsize".
>  
>
In dealing with an arbitrary data-buffer, I could see this as being 
useful, so I'm not sure if disallowing it is a good idea.  Again, 
setting strides is not something that should be done by the average user 
so  I'm not as concerned about "forgetting" the units strides are in.   
If a user is going to be setting strides you have to assume they are 
being careful.

A separate attribute called steps that uses element-sizes instead of 
byte-sizes is a possible idea.

-Travis

[Numpy-discussion] Learning "strides"

[Sasha <nd...@ma...>]

I don't know if this came from numarray or not, but for me as someone
who transitions from Numeric, the "strides" attribute to an ndarray is
a a new feature.  I've spend some time playing with it and there are
some properties that I dislike. Some of these undesired  properties
are probably bugs and easy to fix, but others require some discussion.

1. Negative strides:

>>> x =3D zeros(5)
>>> x.strides=3D (-4,)
>>> x
array([         0,         25,          0, -136009696, -136009536])

Looks like a bug.  PyArray_CheckStrides only checks for one end of the
buffer.  It is easy to fix that by disallowing negative strides, but I
think that would be wrong. In my view. the right sollution is to pass
offset to PyArray_CheckStrides and check for both ends of the buffer.=20
The later will change C-API.

2. Zero strides:

>>> x =3D arange(5)
>>> x.strides =3D 0
>>> x
array([0, 0, 0, 0, 0])
>>> x +=3D 1
>>> x
array([5, 5, 5, 5, 5])

These are somewhat puzzling properties unless you know the internals.
I believe ndarray with 0s in strides are quite useful and will follow
up with the description of the properties I would expect from them.

3.  "Fractional" strides:
I call "fractional" strides that are not a multiple of "itemsize".

>>> x =3D arange(5)
>>> x.strides =3D 3
>>> x
array([       0,      256,   131072, 50331648,        3])

I think these should be disallowed. It is just too easy to forget that
strides are given in bytes, not in elements.  Ideally rather than
checking for strides[i] % itemsize, I would  just make strides[i] to
be expressed in number of elements, not in bytes.  This can be done
without changing the way strides are stored internally - just multiply
by itemsize in
set_strides and divide in get_strides.  If strides attribute was not
introduced before numpy, this change should not cause any
compatibility problems.  If it has some history
of use, it may be possible to depricate "strides" (with a deprecation
warning) and
introduce a different attribute, say "steps", that will be expressed
in number of elements.

Re: [Numpy-discussion] Beta support for Numpy in PyTables

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

mf...@ae... wrote:

>This is good news.  We're planning, tentatively, to implement a big project
>in Python that would make heavy use both of Numpy and Pytables.  We're also
>waiting, however, to for Numpy to stabilize.  It's a little disconcerting
>to see how turbulent it is right now.
>  
>
The only way for it to stabilize is for people to start using it.   So, 
dive in.   The upheaval of the first of the year is behind us.  I don't 
see any major changes in the works.   The only possibility is a few new 
C-API calls to make scalar math work more easily.

-Travis

Re: [Numpy-discussion] Beta support for Numpy in PyTables

[<mf...@ae...>]

This is good news.  We're planning, tentatively, to implement a big pro=
ject
in Python that would make heavy use both of Numpy and Pytables.  We're =
also
waiting, however, to for Numpy to stabilize.  It's a little disconcerti=
ng
to see how turbulent it is right now.

Mark F. Morss
Principal Analyst, Market Risk
American Electric Power


                                                                       =
    
             Francesc Altet                                            =
    
             <faltet@carabos.c                                         =
    
             om>                                                       =
 To 
             Sent by:                  pyt...@li...=
.ne 
             numpy-discussion-         t                               =
    
             ad...@li...                                         =
 cc 
             eforge.net                num...@li...=
ge. 
                                       net                             =
    
                                                                   Subj=
ect 
             02/02/2006 01:19          [Numpy-discussion] Beta support =
for 
             PM                        Numpy in PyTables               =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    




Hi,

As some of you know (and are impatiently waiting for ;-) I'm in the
process of giving support to numpy in PyTables, so that the users can
transparently make use of numpy objects (or Numeric or numarray).
Well, I'm glad to say that the process is almost done (bar some issues
with character array support and unicode arrays). Fortunately, thanks
to the provision of the array interface, saving and reading numpy
objects have nearly the same performance than using numarray objects
(that, as you know, are in the core of PyTables).

So, if you want to have a try to the new PyTables, you can download
this preliminary version of it from:

http://pytables.carabos.com/download/preliminary/pytables-1.3beta1.tar.=
gz

I'm attaching some examples so that you can see how to use numpy in
combination with PyTables, by simply specifying the correct flavor in
the data type definition for Table and EArray (the same goes for
CArray and VLArray, although no examples are provided here) objects.

Also, as I already said in other occasions, when numpy would stabilize
enough, we are planning to make numpy the core data container for
PyTables. Meanwhile, please, test the couple PyTables/numpy and report
any error or glitch that you may notice, so that it can get as stable
as possible in order to easy the transition numarray-->numpy.

Cheers,

--
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"


[attachment  "array1-numpy.py" deleted by Mark F Morss/OR3/AEPIN]
[attachment  "earray1-numpy.py" deleted by Mark F Morss/OR3/AEPIN]
[attachment  "table1-numpy.py" deleted by Mark F Morss/OR3/AEPIN]=

[Numpy-discussion] Beta support for Numpy in PyTables

[Francesc A. <fa...@ca...>]

Hi,

As some of you know (and are impatiently waiting for ;-) I'm in the
process of giving support to numpy in PyTables, so that the users can
transparently make use of numpy objects (or Numeric or numarray).
Well, I'm glad to say that the process is almost done (bar some issues
with character array support and unicode arrays). Fortunately, thanks
to the provision of the array interface, saving and reading numpy
objects have nearly the same performance than using numarray objects
(that, as you know, are in the core of PyTables).

So, if you want to have a try to the new PyTables, you can download
this preliminary version of it from:

http://pytables.carabos.com/download/preliminary/pytables-1.3beta1.tar.gz

I'm attaching some examples so that you can see how to use numpy in
combination with PyTables, by simply specifying the correct flavor in
the data type definition for Table and EArray (the same goes for
CArray and VLArray, although no examples are provided here) objects.

Also, as I already said in other occasions, when numpy would stabilize
enough, we are planning to make numpy the core data container for
PyTables. Meanwhile, please, test the couple PyTables/numpy and report
any error or glitch that you may notice, so that it can get as stable
as possible in order to easy the transition numarray-->numpy.

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Re: [SciPy-user] scipy 0.4.6 release?

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

Ed Schofield schrieb:

> ensuring operations on matrices return matrices ... ;)
> 

Yes please! I'm so glad to have you on my side...
-Sven

Re: [Numpy-discussion] Re: [SciPy-user] scipy 0.4.6 release?

[Ed S. <sch...@ft...>]

Travis Oliphant wrote:

> Ed Schofield wrote:
>
>> I think this is a good idea.  The most recent release (0.4.4) also isn't
>> compatible with the latest NumPy (0.9.4).  I could work on making a new
>> release this weekend if people agree. 
>
> I'll roll out NumPy 0.9.5 at the same time so we have two versions
> that work together.   There have been some bug-fixes and a few (minor)
> feature changes.  But, I am running out of numbers for 1.0 release :-)


That sounds good :)

How about a stream of 1.0 release candidates for Numpy, starting with
1.0-rc1?  For what it's worth, I think we should exercise some patience
and caution before releasing a 1.0 version of NumPy, because this is
likely to signify an API freeze.  The recent dtype changes are a case in
point -- the API is cleaner now, but the change required many small
changes in SciPy.  SciPy is lucky to have helpful developers close to
NumPy too, but some other projects won't be able to respond as quickly
to compatibility-breaking improvements.

Some things I have in mind: stronger type-checking for unsafe casts, and
ensuring operations on matrices return matrices ... ;)

-- Ed

[Numpy-discussion] Re: [SciPy-user] scipy 0.4.6 release?

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

Ed Schofield wrote:

>Erick Tryzelaar wrote:
>
>  
>
>>Any chance we could get a minor version bump to fix this and the 
>>dtypechar/dtype.char bug in Lib/weave/standard_array_spec.py (both 
>>already fixed in svn)? These two changes get my weave test code and then 
>>I can release my darwinports package. Thanks,
>> 
>>
>>    
>>
>I think this is a good idea.  The most recent release (0.4.4) also isn't
>compatible with the latest NumPy (0.9.4).  I could work on making a new
>release this weekend if people agree.
>  
>
I'll roll out NumPy 0.9.5 at the same time so we have two versions that 
work together.   There have been some bug-fixes and a few (minor) 
feature changes.  But, I am running out of numbers for 1.0 release :-)


-Travis

Re: [Numpy-discussion] NumPy SVN not bulding....

[<co...@ph...>]

co...@ph... (David M. Cooke) writes:

> Travis Oliphant <oli...@ee...> writes:
>
>> After changeset 2046, I'm not able to build NumPy.
>
> Obviously my fault then. I'll poke at it.
>
> [dave learns yet again to test before committing...]

Ok, 2048 fixes it. (Used a wrong variable name when refactoring)

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] NumPy SVN not bulding....

[<co...@ph...>]

Travis Oliphant <oli...@ee...> writes:

> After changeset 2046, I'm not able to build NumPy.

Obviously my fault then. I'll poke at it.

[dave learns yet again to test before committing...]

>
> This is what I'm getting...
>
>
> Revsion 2045 works fine.
>
>
> ##### msg: Extension instance has no attribute '__getitem__'
> Extension instance has no attribute '__getitem__'
>  FOUND:
>    libraries = ['ptf77blas', 'ptcblas', 'atlas']
>    library_dirs = ['/usr/lib/atlas']
>    language = c
>    define_macros = [('NO_ATLAS_INFO', 2)]
>    include_dirs = ['/usr/include/atlas']
>
> Warning: distutils distribution has been initialized, it may be too
> late to add an extension _dotblas
> Traceback (most recent call last):
>  File "setup.py", line 76, in ?
>    setup_package()
>  File "setup.py", line 63, in setup_package
>    config.add_subpackage('numpy')
>  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 543,
> in add_subpackage
>    config = self.get_subpackage(subpackage_name,subpackage_path)
>  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 533,
> in get_subpackage
>    config = setup_module.configuration(*args)
>  File "/home/oliphant/numpy/numpy/setup.py", line 10, in configuration
>    config.add_subpackage('core')
>  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 543,
> in add_subpackage
>    config = self.get_subpackage(subpackage_name,subpackage_path)
>  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 533,
> in get_subpackage
>    config = setup_module.configuration(*args)
>  File "numpy/core/setup.py", line 207, in configuration
>    config.add_data_dir('tests')
>  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 594,
> in add_data_dir
>    self.add_data_files((ds,filenames))
>  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 660,
> in add_data_files
>    dist.data_files.extend(data_dict.items())
> AttributeError: 'NoneType' object has no attribute 'extend'
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

[Numpy-discussion] NumPy SVN not bulding....

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

After changeset 2046, I'm not able to build NumPy. 

This is what I'm getting...


Revsion 2045 works fine.


##### msg: Extension instance has no attribute '__getitem__'
Extension instance has no attribute '__getitem__'
  FOUND:
    libraries = ['ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib/atlas']
    language = c
    define_macros = [('NO_ATLAS_INFO', 2)]
    include_dirs = ['/usr/include/atlas']

Warning: distutils distribution has been initialized, it may be too late 
to add an extension _dotblas
Traceback (most recent call last):
  File "setup.py", line 76, in ?
    setup_package()
  File "setup.py", line 63, in setup_package
    config.add_subpackage('numpy')
  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 543, in 
add_subpackage
    config = self.get_subpackage(subpackage_name,subpackage_path)
  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 533, in 
get_subpackage
    config = setup_module.configuration(*args)
  File "/home/oliphant/numpy/numpy/setup.py", line 10, in configuration
    config.add_subpackage('core')
  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 543, in 
add_subpackage
    config = self.get_subpackage(subpackage_name,subpackage_path)
  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 533, in 
get_subpackage
    config = setup_module.configuration(*args)
  File "numpy/core/setup.py", line 207, in configuration
    config.add_data_dir('tests')
  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 594, in 
add_data_dir
    self.add_data_files((ds,filenames))
  File "/home/oliphant/numpy/numpy/distutils/misc_util.py", line 660, in 
add_data_files
    dist.data_files.extend(data_dict.items())
AttributeError: 'NoneType' object has no attribute 'extend'

Re: [Numpy-discussion] numpy with ACML

[George N. <ag...@no...>]

> There is code for that on netlib:
> http://www.netlib.org/blas/blast-forum/cblas.tgz
>
> I used it myself for my C code before and it worked just fine.
>
> Piotr

Piotr,
Thanks. I got numpy to work using the cblas & acml. Details at the  
bottom of the email.
I then ran the bench.py tests on numpy [1 processor Opteron ?1.8 GHZ]  
and got slightly unexpected answers:

  numpy times given both linked to cblas+acml and not linked. Neither  
of numarray, Numeric  linked to any blas:
python bench.py
Tests    x.T*y   x*y.T     A*x     A*B   A.T*x    half    2in2
Dimension: 5
Array   0.5700  0.1600  0.1200  0.1600  0.6200  0.4300  0.4800 --acml 
+cblas
Matrix  3.1000  0.9300  0.4000  0.4600  0.6500  1.7000  2.6200--acml 
+cblas
Array   0.6400  0.1700  0.1500  0.1800  0.6100  0.3600  0.4000
Matrix  3.2300  0.6900  0.4100  0.4600  0.6700  1.4900  2.3400
NumArr  1.2100  2.8500  0.2700  2.8600  5.0000  4.1100  6.8300
Numeri  0.7300  0.1800  0.1600  0.2000  0.4100  0.3300  0.4300

Dimension: 50
Array   5.9200  0.8400  0.2900  6.9300  8.0900  2.3600  2.4500--acml 
+cblas
Matrix 30.5500  1.8500  0.6000  7.4500  0.9300  3.7100  4.6400--acml 
+cblas
Array   6.5900  2.7100  0.7500 25.3100  8.5000  0.5600  0.6100
Matrix 32.5200  3.2600  1.0200 25.6100  1.2900  1.7400  2.5900
NumArr 12.6600  3.9700  0.7400 27.7900  6.4900  4.5500  7.1900
Numeri  7.9700  1.5000  0.6500 24.2700  7.4200  0.6000  2.3200

Dimension: 500
Array   0.9800  3.2900  0.6100 65.0000 10.8600  2.3100  2.5500--acml 
+cblas
Matrix  3.5300  3.3500  0.6400 64.9300  0.6500  2.3300  2.6100--acml 
+cblas
Array   1.0900  4.5600  0.8300 589.0000 11.0700  0.1300  0.2600
Matrix  3.7000  4.5800  0.8400 593.7300  1.1700  0.1300  0.3200
NumArr  1.6700  3.3100  0.7700 417.5600  4.3900  0.8500  1.1000
Numeri  1.1900  3.5200  0.7800 559.8100  9.7400  0.8000  2.4100

-- acml+blas indeed speeds up matrix multiplication by factor of 10.

but
  --doesn't really help vector dot products.
  --slows down searching operations half, 2in2 by factor of 10.

Matrices generally much slower than arrays, except for A.T*x, which  
is ~10x faster for matrices.

I also tried with the goto blas library linked in with cblas. Similar  
results, except slightly faster x.T*y. But trickier to get linked.

--George Nurser


------------------------------------------------------------------------ 
----------------------------------------------------

making the cblas.a library was straightforward. I just changed the  
flags in Makefile.LINUX to:

CFLAGS = -O3 -DADD_ -pthread -fno-strict-aliasing -m64 -msse2 - 
mfpmath=sse -march=opteron -fPIC
FFLAGS =  -Wall -fno-second-underscore -fPIC -O3 -funroll-loops - 
march=opteron -mmmx -msse2 -msse -m3dnow
RANLIB = ranlib
BLLIB = where libacml.so lives/libacml.so

then link Makefile.LINUX to Makefile.in and make.

The resulting cblas.a must then be moved or linked to libcblas.a in  
the *same* directory as the libacml.so.

This directory then needs to be added to the $LD_LIBRARY_PATH if it  
is not a standard one.

I needed a site.cfg in numpy/numpy/distutils/site.cfg as follows:
[blas]
blas_libs = cblas, acml
library_dirs = where libacml.so lives
include_dirs =  where cblas.h lives

[lapack]
language = f77
lapack_libs = acml
library_dirs = where libacml.so lives
include_dirs = where acml *.h live

Then numpy and scipy both seem to build fine. numpy passes  
t=numpy.test(), scipy passes scipy.test(level=10).

[Numpy-discussion] Patch for scalartypes.inc.src

[Christopher S. <ch...@ps...>]

I ran into a couple bugs in scalartypes.inc.src:

   - The switch statement in PyArray_ScalarAsCtype was missing some 
breaks.

   - When SIZEOF_LONGDOUBLE == SIZEOF_DOUBLE, PREC_REPR and PREC_STR
      should both be 17, not 15.  (This matches what's done in 
floatobject.c for Python's
      float.)

The attached patch (against SVN revision 2045) fixes both problems.


Cheers,
Chris

Re: [Numpy-discussion] RE: [Numpy-user] possible error with isarrtype

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

Gerard Vermeulen wrote:

>On Wed, 01 Feb 2006 11:15:09 -0500
>"Colin J. Williams" <cj...@sy...> wrote:
>
>[ depration + style ]
>
>  
>
>>[Dbg]>>> import types
>>[Dbg]>>> dir(types)
>>['BooleanType', 'BufferType', 'BuiltinFunctionType',
>>'BuiltinMethodType', 'ClassType', 'CodeType', 'ComplexType',
>>'DictProxyType', 'DictType', 'DictionaryType', 'EllipsisType',
>>'FileType', 'FloatType', 'FrameType', 'FunctionType', 'GeneratorType',
>>'Instance
>>Type', 'IntType', 'LambdaType', 'ListType', 'LongType', 'MethodType',
>>'ModuleType', 'NoneType', 'NotImplementedType', 'ObjectType',
>>'SliceType', 'StringType', 'StringTypes', 'TracebackType', 'TupleType',
>>'TypeType', 'UnboundMethodType', 'UnicodeType', 'XRan
>>geType', '__builtins__', '__doc__', '__file__', '__name__']
>>[Dbg]>>>
>>
>>    
>>
>
>Isn't the types module becoming superfluous?
>
>  
>
That's the point I was trying to make.  ArrayType is to ndarray as 
DictionaryType is to dict.  My understanding is that the use of 
types.DictionaryType is discouraged.

-Travis

[Numpy-discussion] Examples of new (nested) record-types

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

I've just checked in some tests for the nested-record support in numpy.  
These tests were written by Francesc Alted and are very useful (they 
helped track down at-least two reference-counting errors). 

But, a big utility they have is to show a method for defining and 
constructing arrays of nested records.  Anybody wanting to figure out 
how to use that facility in NumPy better would benefit by looking at the 
code in

<site-packages>/numpy/core/tests/test_numerictypes.py

in the SVN version of NumPy.

-Travis

P.S.  Here is an example of the kind of structure he makes arrays of in 
this file...

# This is the structure of the table used for nested objects (DON'T PANIC!):
#
# +-+---------------------------------+-----+----------+-+-+
# |x|Info                             |color|info      |y|z|
# | +-----+--+----------------+----+--+     +----+-----+ | |
# | |value|y2|Info2           |name|z2|     |Name|Value| | |
# | |     |  +----+-----+--+--+    |  |     |    |     | | |
# | |     |  |name|value|y3|z3|    |  |     |    |     | | |
# +-+-----+--+----+-----+--+--+----+--+-----+----+-----+-+-+
#

After defining an array of these guys you could get at an array of  y3 
fields using

a['Info']['Info2']['y3']

Or,

reca = a.view(recarray)

reca.Info.Info2.y3


-Travis

[Numpy-discussion] Re: NumPy Behavior

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

Jay Painter wrote:

>Travis,
>
>I updated to the latest svn code this morning and ran some mmlib tests.
>Your commit has fixed the segmentation fault/illegal instruction error,
>but the mmlib test suite fails.  I'll look into it tonight, it may just
>be intentional differences between Numeric and NumPy.  I'll let you know
>what I find.
>  
>
Be sure to look over the list of differences in the sample chapter of my 
book (available at numeric.scipy.org)

The numpy.lib.convertcode module can be used to make most of the changes 
(but there may be a few it misses). 

>As I've been working with Numeric, I have often desired some particular
>features which I'd be willing to work on with NumPy.  Maybe these have
>come up before?
>
>1) Alternative implementations of matrixmultiply() and
>eigenvalues()/eigenvalues() for symmetric matrices.  For example, there
>is a analytic expression for the eigenvalues of a 3x3 symmetric matrix.
>
>2) New C implemented vectorM and matrixMN classes which support the
>array interface.  This could allow for lower memory usage via pool
>allocations and the customized implementations in item #1.  The ones I
>wish were there are:
>
>class vector3:
>class vector4:
>class matrix33:
>class matrix44:
>class symmetric_matrix33:
>class symmetric_matrix44:
>
>Given this, here's a useful function for graphics applications:
>
>matrixmultiply431(type matrix44, type vector3)
>
>This function multiplies the 4x4 matrix by the three dimensional vector
>by implicitly adding a fourth element with a value of 1.0 to the vector.
>  
>
This is actually a benefit of the array interface.  It allows many 
different objects to *be* arrays and allow fast converions when 
possible.   Specialized small-arrays are a good idea, I think, just like 
specialized (sparse) large arrays.   Perhaps it would make sense to 
define a base-class array object that has only a very few things defined 
like the number of dimensions, a pointer to the actual memory, the 
flags, and perhaps a pointer to the typeobject.   This would leave 
things like how the dimensions are stored up for sub-classes to define.

-Travis

Re: [Numpy-discussion] numpy.dtype problem

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

Francesc Altet wrote:

>A Dimecres 01 Febrer 2006 15:46, Christopher Hanley va escriure:
>  
>
>>The following seems to have stopped working:
>>
>>
>>In [6]: import numpy
>>
>>In [7]: a = numpy.ones((3,3),dtype=numpy.int32)
>>
>>In [8]: a.dtype.name
>>---------------------------------------------------------------------------
>>exceptions.MemoryError                               Traceback (most
>>recent call last)
>>
>>/data/sparty1/dev/devCode/<console>
>>
>>MemoryError:
>>    
>>
>
>Below is a patch for this. It seems to me that Travis is introducing
>new *scalar data types. I'm not sure if they should appear in this
>case, but perhaps he can throw some light on this.
>  
>
No, I'm not introducing anything new.  I just changed the name of the 
scalar type objects.  They used to be conveying type information for the 
array (but that is now handled by the dtype objects), and so I changed 
the name of the scalars from <x>_arrtype to <x>scalar to better convey 
what they are. 

The code in the name attribute getter was expecting an underscore which 
isn't there anymore.

-Travis

Re: [Numpy-discussion] RE: [Numpy-user] possible error with isarrtype

[Gerard V. <ger...@gr...>]

On Wed, 01 Feb 2006 11:15:09 -0500
"Colin J. Williams" <cj...@sy...> wrote:

[ depration + style ]

> [Dbg]>>> import types
> [Dbg]>>> dir(types)
> ['BooleanType', 'BufferType', 'BuiltinFunctionType',
> 'BuiltinMethodType', 'ClassType', 'CodeType', 'ComplexType',
> 'DictProxyType', 'DictType', 'DictionaryType', 'EllipsisType',
> 'FileType', 'FloatType', 'FrameType', 'FunctionType', 'GeneratorType',
> 'Instance
> Type', 'IntType', 'LambdaType', 'ListType', 'LongType', 'MethodType',
> 'ModuleType', 'NoneType', 'NotImplementedType', 'ObjectType',
> 'SliceType', 'StringType', 'StringTypes', 'TracebackType', 'TupleType',
> 'TypeType', 'UnboundMethodType', 'UnicodeType', 'XRan
> geType', '__builtins__', '__doc__', '__file__', '__name__']
> [Dbg]>>>
> 

Isn't the types module becoming superfluous?

[packer@zombie ~]$ python -E
Python 2.4 (#2, Feb 12 2005, 00:29:46)
[GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> long
<type 'long'>
>>> int
<type 'int'>
>>> str
<type 'str'>
>>> dict
<type 'dict'>
>>> 

Gerard

Re: [Numpy-discussion] numpy.dtype problem

[Francesc A. <fa...@ca...>]

A Dimecres 01 Febrer 2006 15:46, Christopher Hanley va escriure:
> The following seems to have stopped working:
>
>
> In [6]: import numpy
>
> In [7]: a =3D numpy.ones((3,3),dtype=3Dnumpy.int32)
>
> In [8]: a.dtype.name
> -------------------------------------------------------------------------=
=2D-
> exceptions.MemoryError                               Traceback (most
> recent call last)
>
> /data/sparty1/dev/devCode/<console>
>
> MemoryError:

Below is a patch for this. It seems to me that Travis is introducing
new *scalar data types. I'm not sure if they should appear in this
case, but perhaps he can throw some light on this.

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Index: numpy/core/src/arrayobject.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- numpy/core/src/arrayobject.c	(revision 2043)
+++ numpy/core/src/arrayobject.c	(working copy)
@@ -8132,18 +8132,21 @@
 static PyObject *
 arraydescr_typename_get(PyArray_Descr *self)
 {
=2D        int len;
=2D        PyTypeObject *typeobj =3D self->typeobj;
+	int len;
+	char *w_unders;
+	PyTypeObject *typeobj =3D self->typeobj;
 	PyObject *res;
=20
=2D	/* Both are equivalents, but second is more resistent to changes */
=2D/* 	len =3D strlen(typeobj->tp_name) - 8; */
=2D
 	if (PyTypeNum_ISUSERDEF(self->type_num)) {
 		res =3D PyString_FromString(typeobj->tp_name);
 	}
 	else {
=2D		len =3D strchr(typeobj->tp_name, (int)'_')-(typeobj->tp_name);
+		w_unders =3D strchr(typeobj->tp_name, (int)'_');
+		if (w_unders !=3D NULL)
+		  len =3D w_unders-(typeobj->tp_name);
+		else
+		  /* '_' not found! returning the complete name! */
+		  len =3D strlen(typeobj->tp_name);
 		res =3D PyString_FromStringAndSize(typeobj->tp_name, len);
 	}
 	if (PyTypeNum_ISEXTENDED(self->type_num) && self->elsize !=3D 0) {

Re: [Numpy-discussion] RE: [Numpy-user] possible error with isarrtype

[Colin J. W. <cj...@sy...>]

Travis Oliphant wrote:
> Colin J. Williams wrote:
>
>> One of the deprecated names is ArrayType.  This seems to be closer to 
>> the Python style than ndarray.
>
>
> Not really.
I agree with what you say below, but doesn't ArrayType have a greater
similarity to the Python types than ndarray?

[Dbg]>>> import types
[Dbg]>>> dir(types)
['BooleanType', 'BufferType', 'BuiltinFunctionType',
'BuiltinMethodType', 'ClassType', 'CodeType', 'ComplexType',
'DictProxyType', 'DictType', 'DictionaryType', 'EllipsisType',
'FileType', 'FloatType', 'FrameType', 'FunctionType', 'GeneratorType',
'Instance
Type', 'IntType', 'LambdaType', 'ListType', 'LongType', 'MethodType',
'ModuleType', 'NoneType', 'NotImplementedType', 'ObjectType',
'SliceType', 'StringType', 'StringTypes', 'TracebackType', 'TupleType',
'TypeType', 'UnboundMethodType', 'UnicodeType', 'XRan
geType', '__builtins__', '__doc__', '__file__', '__name__']
[Dbg]>>>

I presume that the aim is still that numpy will become a part of the
Python offering.

Colin W.
> Rather than test:
> type(var) == types.IntType
> you should be testing
> isinstance(var, int)
>
> just like rather than testing
> type(somearray) == ArrayType
>
> you should be testing
> isinstance(somearray, ndarray)
>
> Python style has changed a bit since 2.2 allowed sub-typing builtings
>
> -Travis
>

[Numpy-discussion] numpy.dtype problem

[Christopher H. <ch...@st...>]

The following seems to have stopped working:


In [6]: import numpy

In [7]: a = numpy.ones((3,3),dtype=numpy.int32)

In [8]: a.dtype.name
---------------------------------------------------------------------------
exceptions.MemoryError                               Traceback (most 
recent call last)

/data/sparty1/dev/devCode/<console>

MemoryError:


Chris

[Numpy-discussion] Re: Numerical Mathematics Consortium vs. scipy and numpy

[<hu...@co...>]

Christopher Barker wrote:

> In general,
> unfortunately, it looks to be quite commercially-focused: how does one
> get the open source community to be represented in this kind of thing?

I do not know the details, but one of the members of the consortium - Scilab
consortium - is kind of open-source. Well, their license is not purely free
(http://www.scilab.org/legal/license.html,
http://www.scilab.org/legal/index_legal.php?page=faq.html#q6), but it is
definitely not a commercial project. Perhaps some Scilab people could
answer some open-source related questions.

Note that I am not related to the NMC in any way, it is really that I only
found this link and as a newcomer to Python computing community, I am
simply interested what are the attitudes towards these issues here.   

Zdenek

Re: [Numpy-discussion] RE: [Numpy-user] possible error with isarrtype

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

Colin J. Williams wrote:

> One of the deprecated names is ArrayType.  This seems to be closer to 
> the Python style than ndarray.


Not really. 

Rather than test:
type(var) == types.IntType 

you should be testing
isinstance(var, int)

just like rather than testing
type(somearray) == ArrayType

you should be testing
isinstance(somearray, ndarray)

Python style has changed a bit since 2.2 allowed sub-typing builtings

-Travis

Re: [Numpy-discussion] RE: [Numpy-user] possible error with isarrtype

[Colin J. W. <cj...@sy...>]

Fernando Perez wrote:
> O'Keefe, Michael wrote:
>>> Now, the data-type object itself is the preferred way.  I need to 
>>> figure
>>>  out what to do with these functions now and see if they even have 
>>> any use anymore.
>>
>>
>> Thanks Travis.
>>
>> With regard to what to do with the functions, I only ended up trying 
>> them
>> because they were there. From my point of view, I'd love to learn how to
>> code the "right" way. To that end, any means of informing the user of
>> "deprecated" functions (or just taking them out) would be fine with me.
>> However, I realize some may have legacy code and so I would defer to 
>> their
>> opinions.
>
>
> Python has a proper framework for deprecation warnings.  I'd say we 
> use that, and Travis can ruthlessly deprecate anything that's just 
> compatibility noise.
>
> Perhaps 1.0 can keep old but deprecated things around (numpy will see 
> a LOT of use once 1.0 comes out, far more than the current svn testing 
> crowd).  Then, as of 1.1 or 1.2 or whatever, those can be removed.
>
> Cheers,
>
> f
>
One of the deprecated names is ArrayType.  This seems to be closer to 
the Python style than ndarray.

Colin W.

Re: [Numpy-discussion] gfortran, numpy build

[Matthew B. <mat...@gm...>]

> numpy.distutils has already support for both g95 and gfortran compilers.
> Run
>    python setup.py config_fc --help-fcompiler
> to see a list of supported Fortran compilers.

Oops - sorry, I completely missed that - and thanks a lot for the
pointer.  For those as slow as I am, the build command seemed to be:

python setup.py config --fcompiler=3Dgnu95 build

I am afraid this is a sign that I am lost in the build system.  Is
there a good place to start to get to grips with options like the
above?

And, is there a simple way to pass my favorite compiler optimization
flags into the build?

Thanks a lot,

Matthew