Каковы нерешенные вопросы в чисто функциональных структурах данных?

Этот вопрос вдохновлен другим вопросом о том, что нового в ПФДС с момента публикации книги Окасаки в 1998 году .

Я начну с двух вопросов, которые у меня есть:

Существует ли чисто функциональная структура данных набора, которая приближается к скорости хеш-таблиц? Попытки еще не там.
Существуют ли чисто функциональные деревья пальца с добавлением O (1)? На данный момент лучшим является O (LG LG N), разработанный Капланом и Тарьяном.

Какие другие чисто функциональные проблемы структуры данных открыты?

big-list ds.data-structures functional-programming оборота jbapple
источник

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

Джон Харроп

Ответы:

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

В этом контексте я считаю, что постоянный поиск союзов является важной открытой проблемой. Есть бумага Кончона-Филлиата, которая упоминалась в другой ветке. Комментатор уже поднял проблему с их так называемым постоянным массивом: он действительно только полупостоянный. Но предположим, что вы заменили его хеш-кодом или другим действительно постоянным массивом, который ведет себя лучше в худшем (и, возможно, среднем) случае, но хуже в лучшем случае. Это все еще оставляет важный вопрос открытым:

Статья дает формальное доказательство правильности в Coq. Но они не могут справиться с амортизированной сложностью ни формально, ни неформально. Это очень не ясно мне , что сложно за кадром мутация приводит к ожидаемому амортизационной сложности во всех случаях. Когда я в последний раз думал об этом, я был несколько уверен, что смогу создать контрпример, если приложу к этому усилия. Даже если я ошибаюсь в этой последней части, отсутствие надлежащего анализа является серьезным пробелом; Понятно, что классический анализ амортизации UNION-FIND Траяна не переносит напрямую.

оборота в Vognsen
источник

Один из кандидатов на полностью постоянные (но не постоянные) массивы представлен в Confluently Persistent Tries для эффективного контроля версий . Авторы утверждают, что замедление O (lg lg n) опережает замедление O (lg lg m) Дитца и его коллег, где m - количество операций, выполненных над массивом.

jbapple

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

Jbapple

Какие другие чисто функциональные проблемы структуры данных открыты?

Вот один из них:

Что такое чисто функциональный эквивалент слабой хеш-таблицы?

Джон Харроп
источник

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

Джейсон С

Хорошо, я укушу Что за слабая хеш-таблица?

Джеффс

Это хеш-таблица, которая позволяет собирать мусор, если только она (и другие слабые карты) содержат ссылки на нее.

Havvy

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

Нил Кришнасвами

@NeelKrishnaswami, я не думаю, что это так. Вы можете создавать слабые структуры данных, которые не создают недетерминизм, например, слабую таблицу, которая не поддерживает перечисление (или подсчет). См. Пример wiki.ecmascript.org/doku.php?id=harmony:weak_maps .

Сэм Тобин-Хохштадт