Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Robert K. <rk...@uc...>]

Soeren Sonnenburg wrote:
> On Sat, 2005-07-23 at 12:06 -0700, Robert Kern wrote:
> 
>>Soeren Sonnenburg wrote:
>>
>>>Dear all,
>>>
>>>I am new to numarray and as I am trying to use it day-by-day
>>>I am now wondering about certain numeric/numarray design issues. Please
>>>forgive me / correct me as I probably misunderstood certain issues.
>>>
>>>-- Why did you choose row-major instead of column major format as
>>>practiced by R/octave/matlab... Doesn't that mean performance problems
>>>as fortran/blas is optimized if you work with the transposed version ?
>>
>>Not everyone is interfacing with optimized FORTRAN code. Those who are 
>>are usually using ATLAS as their BLAS, and ATLAS has row-major versions 
>>of the BLAS subroutines. Row-major is C's convention and 
>>numarray/Numeric largely follow that. There are of course some 
>>performance issues when interfacing with FORTRAN code that expects 
>>column-major, but there would be other performance problems if 
>>numarray/Numeric were column-major and interfacing with row-major code.
> 
> Well but why did you change to the C version then ? Well maybe if it is
> about optimizing stuff seriously one could work with the transpose
> anyway...

Because numarray and Python are written in C. It's also consistent with 
lists-of-lists.

In [8]: L = [[0, 1],[2,3]]

In [9]: A = array(L)

In [10]: L[1][0]
Out[10]: 2

In [11]: A[1][0]
Out[11]: 2

In [12]: A[1,0]
Out[12]: 2

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter