Хобрук: Ваш путь к мастерству в программировании

Какую структуру данных я бы использовал для сортировки слов по частоте и положению букв?

У меня есть проект, над которым я работаю, и который я планирую реализовать как на Java, так и на ActionScript, поэтому я пометил оба языка.

Чтобы выполнить этот проект, мне нужно будет создать набор всех слов из заданного словаря заданной длины. Затем, после выбора буквы, мне нужно создать подмножества слов на основе ОБА положения буквы и частоты буквы. Например, если набор содержит

{this, time, pate, malt, that, teat, tote}

и пользователь выбирает букву «т», мне нужно разделить набор на подмножества так, чтобы:

Subset 1 (t___) = {this, time}
Subset 2 (__t_) = {pate}
Subset 3 (___t) = {malt}
Subset 4 (t__t) = {that, teat}
Subset 5 (t_t_) = {tote}

для каждого существующего подмножества (обратите внимание, что (_t__) не существовало, поэтому подмножество не было создано).

Какая структура данных была бы лучшим выбором для такой ситуации? Я программирую это как для java, так и для ActionScript, поэтому в идеале это была бы структура, которую я мог бы использовать для них обоих. Тем не менее, я не против полностью изменить структуры данных между языками, если это необходимо. Эти две программы будут отдельными реализациями для моей собственной практики; кроссплатформенная функциональность не требуется.

Некоторые вещи, которые я рассмотрел:

Попытки: обычно, когда я работаю с наборами слов, я использую узлы с Trie. Однако я не думаю, что это сработает в этом случае, потому что нет эффективного/элегантного способа разделить Trie на слова в зависимости от положения букв. Было бы ужасно неэффективно проходить по дереву для всего, что имеет конкретную букву в третьей позиции, а не в каких-либо других позициях, например. Так что не думаю, что попытки сработают.

Массивы: самые основные структуры данных. Легко и просто использовать. Вероятно, я мог бы заставить это работать, сохранив набор слов в виде массива строк, а затем используя серию сравнений, используя charAt() для строк, чтобы разделить их на подмножества. Однако это также не кажется очень элегантным, и я полагаю, что можно было бы использовать лучшую структуру.

ArrayLists: аналогичная проблема с массивами. Я не уверен, что реализация List все равно чем-нибудь поможет.

Словари/карты: единственное преимущество в том, что я использовал их раньше. Я вообще не думаю, что они подходят к ситуации.

23.01.2014

  • каков ваш собственный анализ на данный момент? Каковы ваши кандидаты с плюсами и минусами? 23.01.2014
  • Так у нас будет позиция буквы или длина слова в set ? т. е. какой вход мы будем иметь. ? 23.01.2014
  • Обновлен OP с моим первоначальным анализом 23.01.2014
  • @Looser: у нас будет длина слова. Все слова в начальном наборе будут иметь одинаковую длину (на самом деле они извлекаются из словаря в зависимости от их длины). Ввод будет символом, с которым мы сопоставляемся; мы будем разделять на наборы в зависимости от того, сколько персонажей / в какой позиции находятся персонажи. 23.01.2014
  • На данный момент я склоняюсь к тому, чтобы некоторое время обрабатывать списки слов. Это лучше, чем ArrayLists, потому что с Set мне не нужно беспокоиться о дубликатах. 24.01.2014

Ответы:


1
  1. Все слова в ArrayList говорят о элементах.
  2. Карта, которая имеет ключ как подмножество, т.е. t__,_t_ и значение как список индексов слов для каждого подмножества в списке 1 выше.

Теперь вам просто нужно перебрать список: 1 и заполнить вторую карту.

23.01.2014
  • Как будет работать подмножество в качестве ключа? Должен ли это быть массив логических значений, чтобы отслеживать позицию, например, 1000 для слов, начинающихся с буквы? Или мне придется динамически создавать регулярное выражение, чтобы отсортировать их? 23.01.2014

  • 2

    Вот структуры данных, которые я использовал.

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

    Во-вторых, я использовал HashMap> для сопоставления пар ключ/значение.

    В-третьих, ключи представляли собой строки, динамически создаваемые путем сравнения каждой буквы в charArray каждого слова с угаданной буквой. Если символ совпадал, я добавлял «1», иначе «0». Это оставило меня с ключом соответствующей длины, состоящим из 1 и 0, показывающим как номер, так и позицию каждого символа.

    Чтобы отсортировать слова, я создал этот ключ для каждого слова. Затем, если ключ уже существовал на карте, я добавлял его в HashSet, сопоставленный с этим ключом. В противном случае я создал новую пару ключ-значение с новым HashSet, содержащим новое слово.

    Это отлично сработало для моего размера тестовой выборки. Мне все еще нужно будет запустить его для словаря из 60000+ слов после того, как я закончу остальную часть своего кода и удостоверюсь, что он масштабируется, но он работает очень быстро, когда я имею дело только с несколькими сотнями.

    26.01.2014
    Новые материалы

    Структуры данных в C ++ - Часть 1
    Реализация общих структур данных в C ++ C ++ - это расширение языка программирования C, которое поддерживает создание классов, поэтому оно известно как C с классами . Он используется для..

    Как я опубликовал свое первое приложение в App Store в 13 лет
    Как все началось Все началось три года назад летом после моего четвертого класса в начальной школе. Для меня, четвертого класса, лето кажется бесконечным, пока оно не закончится, и мой отец..

    Что в лицо
    Очерк о возвращении физиогномики и о том, почему мы должны это приветствовать. История начинается со странной науки. Р. Тора Бьорнсдоттир, Николас О. Рул. Видимость социального класса по..

    Почему шаблоны проектирования и почему нет?
    Сложность — мать всех проблем в программировании. Программное обеспечение должно быть разработано с точки зрения того, кто его поддерживает, а не того, кто его пишет, потому что программное..

    Создание дизайна обуви с помощью машинного обучения
    Обувь. Что подождать? Я думал, что речь пойдет о машинном обучении! Ну это так. Если бы вы пошли на Amazon, сколько обуви вы бы нашли? Наверное, много, не так ли? Но много ли в них..

    GraalVM в 2022 году: итоги года
    2022 год был очень продуктивным для проекта и сообщества GraalVM. Вместе мы разработали множество новых функций, выпустили GraalVM для последних версий Java и новых платформ и увидели несколько..

    Быстрая разработка: волшебный мир больших языковых моделей
    РУКОВОДСТВО Быстрая разработка: волшебный мир больших языковых моделей Подход, основанный на данных, для получения наилучшего ответа Искусство и наука Можно ли совместить машинное..