|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#16
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
Quote:
|
|
#17
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
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. |
|
#18
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
The other day I had to go find an IEEE-1200 to preferably USB or VGA or anything that would work with an old printer. Just imagine the look on the guy at RadioShack's face when I asked for one. He asked me what VGA was! |
|
#19
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
|
|
#20
|
|||
|
|||
|
Re: Quotes from the Chief Engineer and I
If you have to comment your code out the wazoo, because you are breaking the conventions, you might be doing something wrong...
|
|
#21
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Oh, obviously. Good code should speak for itself! But we were just pointing out if you do something weird there is always the option to comment it!
|
|
#22
|
|||
|
|||
|
Re: Quotes from the Chief Engineer and I
Quote:
And commenting isn't really an option, it's more of a requirement, for anything! Think of it like homework that is assigned, but not collected. Sure, you MIGHT be okay not doing it every now and then, but really, you have to do it. |
|
#23
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
Turns out it ended an if statement. Boy was I tired. |
|
#24
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
|
|
#25
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
Quote:
Quote:
Agreed but that is not at all what the OP was talking about. |
|
#26
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
I think it really depends on who's going to be reading it. I usually comment as much as I can for teaching examples. But for personal projects I usually write the code and then go back and comment. If what I did doesn't make sense to me I will probably try to rewrite it in a less confusing manner, but if that isn't possible I'll comment it. I try to do this because if it doesn't make sense to me, the author, then it won't make sense to anyone!
|
|
#27
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
The OP was talking of basic concepts, not efficient linear algebra algorithms.
|
|
#28
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
|
|
#29
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Quote:
|
|
#30
|
||||
|
||||
|
Re: Quotes from the Chief Engineer and I
Since I guess no one else has mentioned it, the only reason OP is "correct" is because in Java "2d" arrays neither row-major nor column-major. Java arrays aren't truly multidimensional (all data contiguously stored in rm or cm order) they're just arrays of arrays.
Last edited by Spoam : 26-02-2015 at 01:15. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|