[AccessD] Array dimensions, Row - Col or Col Row

To put it more basic terms, consider geometry.  The x-y coordinate system is
always defined as x (the horizontal component), then y (the vertical
component).  Just looking at a 2-d matrix, columns should be the x, rows
should be the y.  The theory behind why it should be any different is beyond
me.



Mark



-----Original Message-----
From: MartyConnelly [mailto:martyconnelly at shaw.ca] 
Sent: Sunday, February 22, 2004 3:37 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Array dimensions, Row - Col or Col Row


Generally in mathematical matrix notation for a Matrix  M i,j   i is the 
row and j is the column, However in computers Arrays are either broken 
down as column major or row major. Meaning what part of the Array is 
stored contiguously in memory. Those who wish to consider a 2-D numeric 
array as an analogue for a
matrix consider column-major (columns stored contiguously) to be more 
"natural," since the mathematical convention is to divide matrices into
"column vectors."  When linear systems, linear eigensystems, or other 
linear-algebra-based disciplines are discussed in the mechanical 
engineering, electrical
engineering, physics, and mathmatical literature , it is far more common 
to speak of "column vectors" than "row vectors".
All programs that manipulate matrices take advantage of one particular 
memory layout.  If you ignore it, you'll suffer a huge performance hit. In
Fortran the memory layout for arrays is column-major. Fortran orders 
things the way the mathematical literature has made us accustomed to 
seeing them.
I am not sure which is contiguous in memory  in VBA. rows or columns. I 
would have to fiddle around to find out.

If I remember right APL treats an ordinary vector as either a column 
vector or row vector depending on use or context.

However:
Compilers don't know anything about rows or columns. Most C and C++ 
compilers store two dimensional arrays
in exactly the same way that Fortran compilers store them. The only 
difference is that C array subscripts appear
in reverse order from Fortran array subscripts. The problem is that both 
C and Fortran programmers
associate the left and right subscripts of a two dimensional array with 
the row and column indices respectively.
Fortran programmers tend to think of two dimensional arrays as 
collections of column vectors so they naturally think of
one dimensional arrays as column vectors.  C programmers,on the other 
hand, tend to think of two dimensional arrays
as collections of row vectors so they naturally think of one dimensional 
arrays as row vectors.
This screws you up calling C routines from Fortran because you have to 
generally transpose the matrix or array.

To further mess up things, Some Fortran compilers have an option to take 
care of the following:
 For the inner loop of a matrix-matrix product
Most RISC machines like DOT (dot-product) operation best, but some 
vector-instruction machines like the
AXPY(constant-times-a-vector-plus-a-vector) best.

This can be a real bag of worms!

 

 Welz wrote:

> Pet peeve - Microsoft documentation and book authors that insist that
> the the first dimension of 2 dimensional array is the row and the 
> second is the column.  I see that this carries over into the .Net 
> books I'm reading.  When was the last time you used a Recordset 
> .getRows method and had the first index refer to the record and the 
> second to the field?  When was the last time you redimensioned an 
> array to add a column rather than to add or remove a number of rows 
> (records)?  How often does a table/query change in size as to the 
> number of rows (records) in comparison to the number of columns (fields)?
>
> It doesn't really matter which it is, but with the old versions of
> VB/A, you could only resize the last index of a multi-dimensioned 
> array (without copying to a new array anyway) so the only practical 
> usage is to add rows to a fixed number of columns which is in fact how 
> it was implemented.  Then the authors (Dianne Zak for example) and 
> even Microsoft help deliberately explain them to be varArray(RowIndex, 
> ColIndex) when in the actual practical implementation it is nearly 
> always (ColIndex, RowIndex).
>
> It doesn't matter which it is because it is really just an abstract
> data structure that you can in theory map as you please.  The problem 
> I have is when documentation insists on defining it in an impractical 
> manner in the context of getrows and other database usage making it 
> obvious that the VB data people didn't speak with the VB language 
> people.  I had hoped that by .Net they would have a chance to write 
> new documentation and finally get it right but I've been reading the 
> Sybex Maastering Visual Basic .NET Database Programming, Visual Basic 
> .NET Developer's Handbook and Mastering Visual Basic .NET and 
> Evangelos Petroutsos keeps right on defining it backwards when he 
> could have just shut up.
>
> Why is it that within a single company and a single development
> platform, developers insist on driving on different sides of the 
> road?  Is there a means to lodge a complaint with Microsoft so that 
> the next time they replace the entire language they might finally get 
> the documentaion consistent?
>
>
> Ciao
> Jürgen Welz
> Edmonton, Alberta
> jwelz at hotmail.com
>

-- 
Marty Connelly
Victoria, B.C.
Canada



_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com