Hash vs constant vs package vs other for data structure

[oldtechaa]

I'm using an AoAoA currently for a data structure. An example of its use would be like this: $notes[$x][$y][0] = ... As you can see, the first two dimensions refer to the location of an object and the third refers to properties of that object such as flags and other data. My problem is that although the indices always refer to the same data member, it's not very readable or maintainable if you forget the index number for the data you want.

A couple solutions I've thought of are below:

• Use an AoAoH instead, and refer to each data member by name
• Use constant declarations to name each index
• Use upper-case variables to show their status as constant names for indices
• Use a package with setter and getter functions or public data members and use an AoA with the package objects as the contents
• Get other ideas from PM

What do you think? I don't want to use any external CPAN distributions and I'd like the solution to not require too much boilerplate. Thanks for your time.

[haukex]

1. Use an AoAoH instead, and refer to each data member by name
2. Use constant declarations to name each index; Use upper-case variables to show their status as constant names for indices
3. Use a package with setter and getter functions or public data members and use an AoA with the package objects as the contents

The first is probably the way I would go. The second is probably mostly useful if performance is a concern; also it would of course mean you don't have to change your data structure. The third OO approach might be useful if your objects not only have properties, but also methods.

The only thing to take into consideration with the first solution is that you don't have automatic protection against typos in property names like you do in the other two solutions. One possible solution is locked hashes, like I showed here, but note also what I mentioned lower down in that same thread (here) in regards to that they might be deprecated someday.

[oldtechaa]

I don't have methods, so I don't believe I'll go the OO route. It seems like the constant or uppercase methods perform better, are just as readable, and don't make me change my data structure. What are the advantages of the hash method?

[haukex]

What are the advantages of the hash method?

Two that I can think of off the top of my head are that you can have sparse property sets (e.g. if one object has {foo=>1,bar=>2} and the other has {quz=>1,baz=>2}, whereas you'd need four array elements to cover that, a bit of a waste), and that textual serializations of the data would be self-documenting. But if neither of those are a concern to you, then at the moment I can't think of major disadvantages to using constants for the array indicies.

[FreeBeerReekingMonk]

perl -MData::Dumper -E '$A[3][5][0]="foo"; die Dumper \@A'

output:

$VAR1 = [
          undef,
          undef,
          undef,
          [
            undef,
            undef,
            undef,
            undef,
            undef,
            [
              'foo'
            ]
          ]
        ];

Long? Just try 300 by 500!

perl -MData::Dumper -E '$A{3}{5}{0}="foo"; die Dumper \%A'

output:

$VAR1 = {
          '3' => {
                   '5' => {
                            '0' => 'foo'
                          }
                 }
        };

smaller, but slower to iterate through if you have lots of entries. Still you can use an intermediate variable that acts like a pointer:

perl -MData::Dumper -E '$A{3}{5}{0}="foo"; $v = $A{3}{5}; $v->{1}="bar
+"; die Dumper \%A'

if you have fixed dimensions... you can also try: $NUM = $x + $y*$WIDTH so if you have 300 pixels wide, (x,y)=(3,5) becomes 3+5*300 = 1503

but check if you will not run above your maxint: 718414 with that method

[AppleFritter]

Given this...

the first two dimensions refer to the location of an object and the third refers to properties of that object such as flags and other data

...I'd definitely do this:

Use an AoAoH instead, and refer to each data member by name

YMMV, of course.

[Laurent_R]

The best way to store your data really depends on what you're doing with it afterwards. Also a top level hash might be better if your data points are sparse.

Assuming that you'll never use the horizontal coordinate (abscissa) without the vertical coordinate (ordinate), you might even store them as a concatenated value in a hash, thereby simplifying your data structure by removing one level of nested-ness:

my %notes; # notes is now a hash
#...

$notes{"$x;$y"}[0] = ...

or:

$notes{"$x;$y"}{...} = ...

[oldtechaa]

This is an interesting technique. It would certainly work and I do have a sparse data set, but it doesn't seem clearer. What are the performance impacts of this?

[Laurent_R]

What are the performance impacts of this?

It would have to be measured, i.e. bench-marked, with real data.

However, my gut feeling is that removing one level of nested-ness is likely to speed up things a bit, but probably not by a large margin. I doubt that you really care about the difference for what you're doing. So, don't worry too much about performance, unless you really have to.

The hash solution (especially with concatenated keys) is very likely to use far less memory, at least with sparse data. Suppose you've got only one data point with coordinates (800, 1200). With an array of arrays, you have to allocate essentially 800 * 1200 array slots, that's quite a lot or memory for just one data piece. But with a hash you need to allocate only one or two hash entries; even considering that a hash entry uses more memory than an array entry, there is a significant win here.

[Laurent_R]

but it doesn't seem clearer

Granted, but it makes things simpler (and easier) if you need to traverse your entire data structure. You essentially get a better data abstraction if you think in terms of "location", rather than "x-y coordinates".

[oldtechaa]

I should probably note here that since I do have a sparse data set, the array members are undefined until needed.

[Anonymous Monk]

"As you can see, the first two dimensions refer to the location of an object and the third refers to properties of that object such as flags and other data."

However you later state: "I don't have methods, so I don't believe I'll go the OO route."

Well, too late. You already have and now you are trying to change the rules. Instead you should store the fact that an object is on the canvas and it's location. Use an array to store this info like so:

my @widgets = (
 { object => $object, x => $x_location, y => $y_location },
 { object => $object, x => $x_location, y => $y_location },
 { object => $object, x => $x_location, y => $y_location },
);

Note that those variables names are just placeholders for the real variables and their data. This way you only have to be concerned with the grid points that actually have data.

[Anonymous Monk]

This thread seems like a lot of premature optimization. If you don't have an actual performance problem (too much memory used, or some operation is taking too long), then don't worry about it, and definitely don't spend any time re-engineering your existing code.

[oldtechaa]

It actually was originally intended just to find a way to make my 3D array more readable. Optimization is a side-point that I feel must be taken into consideration when choosing a better solution.

[BrowserUk]

FWIW: my preference would be for the use of enum for the constants, and stick with the AoAoA (unless sparsity is required):

use enum qw[ X Y ];

[oldtechaa]

This was another option I didn't add to the list, but sparse data support would be nice.

[Anonymous Monk]

"the first two dimensions refer to the location of an object ..."

Why? This seems to be the root of your problem.

[oldtechaa]

This array is holding the data from a custom GTK widget and I need to know every point in a grid on the widget to store data from. Obviously, a two-dimensional access is the easiest way of managing it.

[Anonymous Monk]

This makes no sense ...