View Single Post
  #7   Spotlight this post!  
Unread 25-02-2015, 23:14
John's Avatar
John John is offline
Registered User
AKA: John Gillespie
FRC #1153 (Roborebels)
Team Role: Mechanical
 
Join Date: Sep 2011
Rookie Year: 2009
Location: Walpole MA
Posts: 71
John is just really niceJohn is just really niceJohn is just really niceJohn is just really niceJohn is just really nice
Re: Quotes from the Chief Engineer and I

Quote:
Originally Posted by wireties View Post
How members of an array are stored and accessed is a function of the programming language. It is not something one should worry or argue about since the language will reference and de-reference everything for you. "Row" and "Column" mean nothing to the compiler. Notation has nothing to do with the physical location since memory is laid out so one accesses word-sized elements in sequence. In C and C++ matrices and arrays are really done with pointer arithmetic - google it.
I would disagree that you shouldn't care about how elements of a multidimensional array are stored. Knowledge of the underlying structure in physical memory can make a significant difference in performance of code.

Say you have a matrix that you are representing as a 2D array:
|a b c |
|d e f |
|g h i |

C/C++ structures this in row-major order. This means that the elements are physically arranged sequentially in memory in this order:

a, b, c, d, e, f, g, h, i

Fortran structures this in column-major order. Physically, they are represented as:

a, d, g, b, e, h, c, f, i

Each element is at a particular "address" in memory, which is usually expressed as a hexadecimal number. The elements of the array will be stored sequentially. This means that if element 'a' is stored at 0x1AFF3114, then (in C/C++) element 'b' will be stored at 0x1AFF3115, 'c' at 0x1AFF3116, and so on. In Fortran, 'd' would be at 0x1AFF3115, 'g' at 0x1AFF3116, 'b' at '0x1AFF3117' and so on.

Why does this matter? It is much faster to access elements sequentially than nonsequentially for most physical storage media, sometimes even orders of magnitudes faster. It won't make much of a difference for simple problems with 3x3 or other small matrices, but when dealing with very large matrices with thousands or even millions of elements (which appear in many real engineering problems, for example, the matrices created by FEA software-) it becomes very important.

As a result, it is useful to know what order your programming language lays out its multidimensional arrays in memory, and to write your algorithms to access them in sequential order when possible.