Another Deep Vexing Question on Array Nomenclature

[Dimster]

Ok, maybe not that deep and vexing. The question goes more to the SAMU value of naming the Array (ie Speed, Accuracy, Memory Usage).

Which approach to the Name given to an array would be more advantageous - The Data it contains in the Name itself or the Data it contains in the elements of the array?

For example - say you have a file containing 18 different pieces of Data. You want to retrieve this data in 3 different groups so you set up 3 different arrays to do this. Which is the better named array for doing this in terms of SAMU.

Three arrays with Data in the elements of the arrays:
Dim GroupA(1 to 6): Dim GroupB(7 to 12):Dim GroupC(13 to 18)

Three array with Data in the name of the array:
Dim Group16(1 to 6):Dim Group712(1 to 6):Dim Group1318(1 to 6)

Seems I have a mixture of these two approaches and was thinking I should stay consistent with just one approach as the program gets larger.

[SMcNeill]

Why not just:

DIM Array(17)
Group = Index \ 6
Index = Group * 6 + DesiredElement

So, for example, Index 2 is in group 0.  Index 8 is in group 1.

To find the 3rd element of the 3rd group would be index 3 * 6 + 3 = 21.  (Remember to start counting from 0.)

One simple array to store all the data, and just some basic math to utilize the indexes in groupings.

[granzeier]

Ok, maybe not that deep and vexing. The question goes more to the SAMU value of naming the Array (ie Speed, Accuracy, Memory Usage).
...

I had never heard of the SAMU method/value/whatever. When I Googled it, nothing obvious came up.

If you are talking about naming conventions for your array variable names, I have always used (and taught my programming students) the idea that the variable name should give a good description of the data contained within.

If that is not what you mean by "SAMU," please give more information.

[Dimster]

Hi granzeier - appears you then would favor the Group1318 (1 to 6) approach over the GroupC (13 to 18) as Group1318 expresses the Data in the array name better. I do tend to name my arrays just as you suggest. In Steve's example, I could use the original Data file which carries all 18 pieces of Data rather than break them out into the 3 separate groups but find I get confused on what Data I'm working with within the original Data file.

SAMU is my own term. I found the larger my program became, the greater the need for labeling arrays more effectively, making the arrays smaller with better directed formulas seemed to result in faster and more accurate results in the various calculations. Every now and then I encountered "Out of Memory" which I tracked back to a very poorly designed calculation formula and a redimmed array. Thus the SAMU goal for array creation was born.

So I'm thinking is there any difference in terms of Speed, Accuracy or Memory Usage of Group1318(1 to 6) v's GroupC(13 to 18).

They are likely way to small for Speed to be a factor as they are single arrays and a lot of my arrays are multi dimensional so I'm extrapolating the speed issue of a single array would be roughly the same for multi dimensional arrays.

 In terms of Accuracy, to access data item 15 - Group1318 would require something like
                                                                      If Dat = 15 then Group1318(Dat-18)
                                                                 - GroupC would require something like
                                                                     If Dat = 15 then GroupC(15)

In terms of memory, I don't think there is a difference. Each one has eliminated the "0" element, and each reserves 6 elements. At least I think that's right, 13 to 18 would not require more memory than 1 to 6. 

So I gather Steve, the name of the array may not be as important as the function of the array or accessing the data in the array. When it comes to SAMU it's all in the design of the array. I know that to be true but how do you keep the over all flow of your programs visual at a glance without some clarity to the name of the arrays and variables.

[Pete]

Why not just:

DIM Array(17)
Group = Index \ 6
Index = Group * 6 + DesiredElement

So, for example, Index 2 is in group 0.  Index 8 is in group 1.

To find the 3rd element of the 3rd group would be index 3 * 6 + 3 = 21.  (Remember to start counting from 0.)

One simple array to store all the data, and just some basic math to utilize the indexes in groupings.

+1 That's been my approach over the years when I encounter this type of array situation. I'm just careful to make a remark somewhere as to the algorithm I'm using, so I won't screw things up if I add to the program years later.

Pete

[Dimster]

Thanks Pete

[STxAxTIC]

This may be a perfect application for linked lists. Show me your ugliest, most weird-character-infested data you've got.

[Dimster]

Hello again STxAxTIC. I have been trying to follow your approach on a data base like file management with link list. Have to admit I'm having trouble visualizing it to adapt it in a simplified form that I could play around with - but nevertheless, if you'd like to see an example of the data I'm trying to organize and work with here are two different data files which do relate to each other. Basically I'm working with 50 Events and tracking over 100 difference aspects elements/sub events which interact with main 50 Events.

So here is the data 1 for only 1 of the 50 Events:

Code: QB64: [Select]

1. 3400,2,463
2. 3404,7,464
3. 3434,3,465
4. 3437,2,466
5. 3440,1,467
6. 3443,2,468
7. 3447,1,469
8. 3454,1,470
9. 3455,2,471
10. 3462,2,472
11. 3463,3,473

Data 2 - Here is data from another file containing different info on the very same Event

Code: QB64: [Select]

1. 3
2. -1
3. -6
4. 0
5. 11
6. -8
7. -9
8. 20
9. -6
10. -8

You can image, I have a lot of Data files to work with for each of 50 Events. And I have picked out only 10 entries from the 2 different files, each of those 2 files have just under a thousand entries as the data is covering about 30 years.

It is possible from this data for me to pin point a single day in the  past and a see what happened on that day for each of the 50 events. This becomes important if something that was not previously know for that day occurred to affect one or more of the 50 events. I then need to either alter the data for that day or in some case create a new record for that day. So Updating is an ongoing process as well.

So I'm not sure exactly how Linked List would work on a large scale and if my main connection to all the data (being the same 50 events) would actually count as a "Link" to all the data already. The storage of the Lists in a North,South,East,West orientation which you described in another Discussion Topic does have me intrigued, especially in terms of my SAMU mania.