Jürgen Welz
jwelz at hotmail.com
Sun Feb 22 16:02:20 CST 2004
Thanks Marty: Thinking about file streams and the manner in which records are stored in text files, a record is appended contiguously (row major) and it is implicit from the 2 k page locks in Access databases where you can fill a record with extra fields with up to 255 characters each to fake single record locking in Jet 3.5, it would appear that Access and .GetRows should be row major and that redim preserve would work to add or remove a record. I remember dabbling with 'safe arrays' to write a quick sort that moved rows at a time (or was it structs?) and my recollection is that arrays were akin to a sequential series of records, each made up of repeating column values. Can you imagine how inefficient it would be to sort records in a column major array? It's been 15 or so years since I've done any matrix math but your comments ring a bell. There is no doubt that an array assigned to the return value of getrows uses a (col, row) order and the help and every author I've read who says anything about it states that the indexes are (row, col). In terms of priority in retrieving a value from a record, it would make sense to locate the record first and then the value from the appropriate column. ie, find the person and then determine the age of that person rather than find the age column and then check them for the person. If one seeks the record first, perhaps the first index should be the record and the second the column but that reverses the index order resulting from getrows. When it comes to iterating elements, there is no advantage to row, col or col row as they are simply memory addresses. Working with blocks of memory rather than addresses is another matter entirely (ie sorting entire records). I would have been much happier about the help if it were consistent. If getrows returned (row, col) and the language allowed one only to redim the first dimension (so much easier to determine and code), then the help and the usage would be reconciled. Most programmers don't need to know how the array is stored in memory but they should know how to access the value of a row and column of a particular 'record' and all the help does is reverse the manner in which it is used with databases. I'd still like to know where a complaint of this nature stands a hope of getting consideration that will result in the help at least saying that arrays are (row, col) except when dealing with database records. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com >From: MartyConnelly <martyconnelly at shaw.ca> > >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 _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca