0

I am working with a 16x16x16 cube of information, at each position I need to store a pair(int,int). In most use cases the majority of the cube will be holding (0,0), but there is potential for every position to hold unique information.

It might be worth noting that the only relation between the information being held in the pair(int,int) is that they are in the same position.

  1. The first value is likely to only be 0-9 but can be another value
    • represents an attribute of that position.
  2. The second value represents a pattern it will be 0-6 or a combination of 1-6 in ascending order(eg 12, 123456)
    • it describes the relation between the current position and the 6 adjacent positions.
    • The second value can technically just be 0-64 but for my sanity while working with it I have used that pattern.

I am currently just using a 3d array but that seems like such a large waste considering that the majority of the array holds the same (0,0) value. I should also mention that I do not access this information often outside of saving and during setup.

If anyone has a suggestion for a better storage structure I would appreciate your input.

UberAffe
  • 332
  • 2
  • 3
  • 15
  • I would suggest to stick to int[][][]. It will save you a lot of computation space. You could have used link list, but the computation involved to access information will not be worth the troubles. – zookastos Jul 17 '15 at 16:07
  • @Nalin Agrawal I was asking more because of memory space rather than computation speed/space, a 3d array for me would be like an array of 8,192 int's and only about 1/4 or less will be used in most cases. – UberAffe Jul 17 '15 at 17:04

1 Answers1

0

The first that that came to mind was defining your own classes for Cube, pair, and a 3-tuple, something like the following:

public class IntTuple {

    private final int x;
    private final int y;
    private final int z;

    public Tuple(int x, int y, int z) {
        this.x = x;
        this.y = y;
        this.z = z;
    }

    public int getX() { return x; }
    public int getY() { return y; }
    public int getZ() { return z; }
}

And a similar class for your pair. Then the Cube can be something like:

public class Cube {

    private HashMap<IntTuple, IntPair> cubeMap = new HashMap<IntTuple, IntPair>();
    private zeroPair = new IntPair(0, 0);

    public addPair(IntTuple coords, IntPair pair) {
        cubeMap.put(coords, pair);
    }

    public IntPair getPair(IntTuple coords) {
        if (cubeMap.containsKey(coords))
            return cubeMap.get(coords);
        else
            return zeroPair;
    }
}

In terms of storage you reduce some overhead as you only store coordinates with non-zero pairs, and you have fast access with the hashmap. Only one zero pair is created and you will always return that one reference.

If you wanted a little greater scalability, you could make all three classes with generic types so you could re-use the structures for storing objects other than integers.

adamconkey
  • 4,104
  • 5
  • 32
  • 61
  • Thanks, this solves it in a memory friendly manner. Curious, why does HashMap seem to get used more often than map or dictionary? As far as I can tell they are almost the same. – UberAffe Jul 17 '15 at 20:21
  • Map is an interface so in itself it cannot be instantiated - HashMap implements the Map interface. Dictionary is an abstract class so again it cannot be instantiated, but HashTable extends it and provides concrete implementations of the abstract methods. There is an informative post on the distinction between HashMap and HashTable: http://stackoverflow.com/questions/40471/differences-between-hashmap-and-hashtable – adamconkey Jul 17 '15 at 20:31