Java большой datastructure для хранения матрицы

Двумерный массив будет более эффективным с точки зрения памяти. Вы можете использовать небольшую хэш-карту, чтобы сопоставить 952 места с числом от 0 до 951. Затем просто сделайте:

float[][] distances= new float[952][952];

Чтобы разобраться, просто используйте два поиска по хэшу, чтобы преобразовать два места в два целых числа и использовать их в качестве индексов в 2-м массиве.

Делая это таким образом, вы избегаете боксов чисел с плавающей запятой, а также накладные расходы на память большой хэш-карты.

Однако 906304 действительно не так много записей, вам может просто потребоваться увеличить максимальный размер кучи Xmx

Я бы хотел думали, что можно рассчитывать расстояния на лету. Предположительно кто-то уже сделал это, поэтому вам просто нужно узнать, какой алгоритм они использовали, и входные данные; например, долгота / широта условных центров каждого почтового индекса.

РЕДАКТИРОВАТЬ: Есть два обычно используемых алгоритма для нахождения (приблизительного) геодезического расстояния между двумя точками, заданного парами долгота / широта.

• Формула Викенти основана на приближении эллипсоида. Это более точно, но более сложно реализовать.

• Формула Хаверсина основана на сферическом приближении. Он менее точен (0,3%), но его проще реализовать.

Я поддержал ответы Чи и Бенджамина, потому что они говорят вам, что вам нужно делать, но пока я здесь, я хотел бы подчеркнуть, что с использованием хэш-кода двух строк прямо доставит вам неприятности. Вы, вероятно, столкнетесь с проблемой коллизий хэшей.

Это не было бы проблемой, если бы вы объединяли две строки (будьте осторожны, чтобы использовать разделитель, который не может появиться в позиционных обозначениях) , и позволяя HashMap творить чудеса, но предложенный вами метод, использующий хэш-коды для двух строк в качестве ключа, вызовет у вас проблемы.

Вам просто потребуется больше памяти. При запуске процесса Java запустите его следующим образом:

java -Xmx256M MyClass

Параметр -Xmx определяет максимальный размер кучи, поэтому это означает, что процесс может использовать до 256 МБ памяти для кучи. Если у вас все еще заканчивается, продолжайте увеличивать это число, пока не достигнете физического предела.

В последнее время мне удалось создать аналогичные реквизиты для моей магистерской диссертации.

Я закончил классом Matrix, который использует double [] , а не double [] [] , чтобы снизить затраты на двойное удаление ( data [i ] , который представляет собой массив, затем array [i] [j] , который представляет собой double ), позволяя виртуальной машине выделить большой непрерывный фрагмент памяти:

public class Matrix {

    private final double data[];
    private final int rows;
    private final int columns;

    public Matrix(int rows, int columns, double[][] initializer) {
        this.rows = rows;
        this.columns = columns;
        this.data = new double[rows * columns];

        int k = 0;

        for (int i = 0; i < initializer.length; i++) {
            System.arraycopy(initializer[i], 0, data, k, initializer[i].length);
            k += initializer[i].length;
        }
    }

    public Matrix set(int i, int j, double value) {
        data[j + i * columns] = value;
        return this;
    }

    public double get(int i, int j) {
        return data[j + i * columns];
    }
}

этот класс должен использовать меньше памяти, чем HashMap , поскольку он использует примитивный массив (упаковка не требуется): ему требуется только 906304 * 8 ~ 8 Мб ( для double s) или 906304 * 4 ~ 4 Мб (для float s). Мои 2 цента.

NB Я пропустил некоторые проверки для простоты

Стивен К. подметил правильную точку зрения: если расстояния очень велики, то вы, вероятно, могли бы сэкономить память, выполняя некоторые вычисления на лету. Все, что вам нужно, это место для долготы и широты для 952 почтовых индексов, а затем вы можете использовать формулу виценти для выполнения своих расчетов, когда вам нужно. Это приведет к тому, что ваше использование памяти в почтовых индексах будет O (n).

Конечно, это решение делает некоторые предположения, которые могут оказаться ложными в вашем конкретном случае, например, что у вас есть данные о долготе и широте для ваших почтовых индексов и что вы нас интересуют расстояния по прямой, а не что-то более сложное, например, маршруты проезда.

Если эти предположения верны,

Приведенные выше предложения относительно размера кучи будут полезны. Однако я не уверен, что вы дали точное описание размера вашей матрицы.

Предположим, у вас есть 4 местоположения. Затем вам нужно оценить расстояния между A-> B, A-> C, A-> D, B-> C, B-> D, C-> D. Это предполагает шесть записей в вашем HashMap (4 выберите 2).

Это наводит меня на мысль, что фактический оптимальный размер вашей HashMap составляет (952 выберите 2) = 452 676; НЕ 952x952 = 906,304.

Все это предполагает, конечно, что вы храните только односторонние отношения (то есть от A-> B, но не от B-> A, поскольку это избыточно), что я бы рекомендовал поскольку вы уже испытываете проблемы с пространством памяти.

Изменить: нужно было сказать, что размер вашей матрицы не оптимален, а не сказать, что описание было неточным.

Создайте новый класс с 2 слотами для имен местоположений. Всегда помещайте имя в алфавитном порядке в первый слот. Дайте ему правильный метод equals и hashcode. Дайте ему compareTo (например, отсортируйте в алфавитном порядке по именам). Бросьте их все в массив. Сортировать.

Кроме того, hash1 = hash2 не подразумевает object1 = object2. Никогда не делай этого. Это взлом.