Які невирішені питання суто функціональних структур даних?

Це питання надихає ще одне питання про те, що нового у PFDS після публікації книги Окасакі в 1998 році .

Почну з двох питань, які у мене є:

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

Які ще суто функціональні проблеми структури даних є відкритими?

big-list ds.data-structures functional-programming

— jbapple
джерело

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

— Джон Харроп

Відповіді:

Я тлумачу це питання дещо ліберально. Для структур даних у стилі Окасакі запам'ятовування - це форма неявної мутації, яка побічно впливає на час роботи. Таким чином, я прийму питання, що стосується стійких структур даних у суворому розумінні, а не структур даних із суто функціональною реалізацією, які є підмножиною першої. Я маю на увазі, що ви повинні мати доступ до старих версій структури даних без штрафних санкцій, дерево версій може розгалужуватися довільно тощо.

У цьому контексті я вважаю, що стійкий УНІСНУВАННЯ є важливою відкритою проблемою. Є папір Конхона-Філлітре, про яку згадували в іншій темі. Коментолог вже підняв проблему зі своїм так званим постійним масивом: це дійсно лише напівстійкі. Але припустимо, ви замінюєте його хеш-трією або іншим справді стійким масивом, який веде себе краще в гіршому (і, можливо, середньому) випадку, але гірше в кращому випадку. Це все ще залишає важливим питання відкритим:

У документі наведено формальне підтвердження коректності в Coq. Але вони не вирішують амортизовану складність ні формально, ні неофіційно. Мені дуже не зрозуміло, що складна закулісна мутація призводить до очікуваної амортизованої складності у всіх випадках. Коли я востаннє думав про це, я відчував дещо впевненість, що зможу побудувати контрприклад, якщо докладу зусиль. Навіть якщо я помиляюся з приводу останньої частини, відсутність належного аналізу є головною прогалиною; зрозуміло, що класичний аналіз амортизації Траяна UNION-FIND безпосередньо не передає.

— На Вогнсена
джерело

Один кандидат для повністю стійких (але не конфузійно стійких) масивів представлений у Конфлюктно стійких спробах для ефективного контролю версій . Автори стверджують, що O (lg lg n) уповільнення, перемігши повільне уповільнення Дієца та інших (O lg lg m), де m - кількість операцій, виконаних на масиві.

— jbapple

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

— jbapple

Які ще суто функціональні проблеми структури даних є відкритими?

Ось один:

Який суто функціональний еквівалент слабкої хеш-таблиці?

— Джон Харроп
джерело

гм .... ОП задала відповіді без відповідей, тому це може бути кваліфікованим як відповідь на питання ОП.

— Jason S

Гаразд, я кусаю. Що таке слабка хеш-таблиця?

— Jeffε

Це хеш-таблиця, яка дозволяє його елементам збирати сміття, якщо лише вони (та інші слабкі карти) містять посилання на нього.

— Havvy

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

— Ніл Крішнасвамі

@NeelKrishnaswami, я не думаю, що це так. Ви можете створювати слабкі структури даних, які не створюють недетермінізму, наприклад слабку таблицю, яка не підтримує перерахування (або підрахунок). Для прикладу див. Wiki.ecmascript.org/doku.php?id=harmony:weak_maps .

— Сем Тобін-Хохштадт