Бинарные функции и хеширование с учетом местоположения (LSH)

Я изучаю FLANN, библиотеку для приблизительного поиска ближайших соседей.

Для метода LSH они представляют объект (точку в пространстве поиска) в виде массива целых чисел без знака. Я не уверен, почему они это делают, а не представляют точку просто как двойной массив (который будет представлять точку в многомерном векторном пространстве). Может быть, потому что LSH используется для бинарных функций? Может ли кто-нибудь рассказать больше о возможном использовании unsigned int в этом случае? Зачем unsigned int, если вам нужны только 0 и 1 для каждой функции?

Спасибо


person user1796942    schedule 12.01.2013    source источник


Ответы (1)


Обратите внимание, что я буду ссылаться на последний выпуск FLANN, т. е. flann-1.8.3 на момент написания.

Для метода LSH они представляют объект (точку в пространстве поиска) в виде массива целых чисел без знака.

Нет: это неправильно. Класс LshIndex включает метод buildIndexImpl, реализующий LSH-индексирование. Поскольку LSH в основном представляет собой набор хеш-таблиц, эффективное индексирование происходит в классе LshTable.

Элементарный метод индексации, то есть метод, который индексирует один вектор признаков (также известный как дескриптор или точка) за раз:

/** Add a feature to the table
 * @param value the value to store for that feature
 * @param feature the feature itself
 */
void add(unsigned int value, const ElementType* feature) {...}

Примечание. В методе buildIndexImpl используется альтернативная версия, которая просто выполняет итерацию по функциям и вызывает описанный выше метод для каждой из них.

Как видите, этот метод имеет 2 аргумента, которые являются парой (ID, descriptor):

  1. value, который равен unsigned int, представляет собой уникальный числовой идентификатор вектора признаков (он же индекс признаков).
  2. feature представляет сам вектор признаков

Если вы посмотрите на реализацию, то увидите, что первый шаг состоит в хэшировании значения дескриптора для получения соответствующего ключа корзины (= идентификатор слота, указывающий на корзину, в которой будет храниться этот идентификатор дескриптора):

BucketKey key = getKey(feature);

На практике хэш-функция getKey реализуется только для бинарных дескрипторов, т. е. дескрипторов, которые могут быть представлены в виде массива unsigned char:

// Specialization for unsigned char
template<>
inline size_t LshTable<unsigned char>::getKey(const unsigned char* feature) const {...}

Может быть, потому что LSH используется для бинарных функций?

Да: как указано выше, реализация FLANN LSH работает в пространстве Хэмминга для бинарных дескрипторов.

Если вы будете использовать дескрипторы с реальными значениями (в R**d), вам следует обратиться к оригинальному документу., в котором содержится информация о том, как преобразовать векторы признаков в двоичные строки, чтобы использовать пространство Хэмминга и хеш-функции.

Может ли кто-нибудь рассказать больше о возможном использовании unsigned int в этом случае? Зачем unsigned int, если вам нужны только 0 и 1 для каждой функции?

См. выше: значение unsigned int используется только для хранения связанного идентификатора каждого вектора признаков.

person deltheil    schedule 13.01.2013