Яка найскладніша структура даних ви використовували в практичній ситуації? [зачинено]

Проросток цього питання з'явився під час дискусії, яку я мав з парою колег-розробників з галузі.

Виявляється, що у багатьох місцях керівники проектів насторожено ставляться до складних структур даних, і, як правило, наполягають на тому, що існує у стандартній бібліотеці / пакунках. Загальна ідея схожа на те, щоб використовувати комбінацію того, що вже є, якщо продуктивність серйозно не перешкоджає. Це допомагає зберегти базу коду простою, що для недипломатичного означало б "у нас велике виснаження, і новіші, які ми наймаємо, не можуть бути такими хорошими".

Тож жодних фільтрів для цвітіння та пропускних списків чи гри на деревці для вас не потрібно. Тож ось питання (знову ж таки): яка найскладніша структура даних ви робили чи використовували в офісі?

Допомагає зрозуміти, наскільки хороше / складне програмне забезпечення в реальному світі.

Використовували пропускні списки для пошуку. Там, де я працюю, є стандартна реалізація, і всім рекомендується її використовувати. Використовували спроби patricia для ефективного зберігання та отримання ip-адрес. Знову реалізація вже була присутня.

Я розробник Java. Java Collection Framework може вирішити мої 90% проблеми зі структурою даних, інші 10% потребують зусиль. Я думаю, якщо ви дійсно розумієте складний стандартний ліб, написаний експертами, ви знайдете, що вони допомагають у більшості випадків.

Складні структури даних важко підтримувати в реальному світі. Щоб уникнути псування коду, я поділю неприємності на деякі менші. Кожна невелика проблема може бути вирішена Java Collection Framework . Можливо, рішення не найрозумніше (йому потрібно більше пам’яті та повільніше), але воно працює і просте в обслуговуванні. Це компроміс.

Якщо мені потрібно написати складну структуру даних, я підберу підручник :)

Найскладнішою структурою даних, яку я використав у роботі, було тріє. Однак це було двадцять років тому.

Проблема з розробкою промислового програмного забезпечення полягає в тому, що більшість промислових програмістів не є грамотами з інформатики (CompSci); отже, методики, які середній бал CompSci сприймає як належне, вважаються занадто складними у дотриманні програмістів з хлібним маслом.

Відсутність загальних знань CompSci у галузі є серйозною проблемою. Наприклад, я втратив підрахунок кількості розробників програмного забезпечення, яких я зустрів, які не розуміють таких виразів, як! (A! = 5 && b! = 3) та a == 5 || b == 3 логічно еквівалентні. Кожен, хто знає, як застосувати теорему DeMorgan, може визнати, що ці вирази логічно еквівалентні. Більшість випускників, які не є CompSci, ніколи не чули про теорему DeMorgan. Якщо опитувати будь-яку істотну базу коду, ви знайдете безліч випадків виразів, які заперечують негативні логічні субпрекси. Читання коду, який містить заперечені негативні логічні підвираження, майже завжди покращується шляхом перетворення цих виразів у їхню негативну форму.

Я одного разу написав календарну чергу (O (1) пріоритетної черги) для моделювання на основі подій, в якому профілювання показало, що існуюча купа є вузьким місцем.

Я також випустив продукт, який містив машину з кінцевим станом з приблизно 80000 станами - код для його генерування був, щонайменше, химерним.

Давно, давно, в галактиці ... Працював над командою, яка використовувала "приятелі буфери" Кнута в RTOS в асемблері.

Крім того, Гра життя Конвея з 256 поколіннями для світу 1024 х 1024.

Насправді не використовувалося нічого надто особливого, з нуля це був би список, що з подвійним зв'язком .

Не дуже захоплююче, я використовував інші структури. Але ваше запитання сказано з нуля.

Дерево хештелів, що містить загальні списки фінансових даних - навіть не запитуйте. Іноді хочеться, щоб я був ковбоєм. Ах, просте життя під зірками ...

Мені довелося написати кругову структуру з подвійним зв'язаним списком з нуля для алгоритму танцювальних посилань для вирішувача судоку. Здавалося, спроектувати кубик Рубіка. Вся структура складала в основному список списків - кожен вузол вказував на чотири інші.

Я колись використовував зважене дерево довжиною шляху для спеціалізованого кешу. Це було весело. Також написав власну процедуру управління купою для malloc()заміни, але багато людей зробили це.

Задумавшись, найбільш "складна" структура даних, яку я зробив з нуля, - це моделювання мережі елементів, що базувалася на подвійних зв'язках списків. Але це було роки тому, коли я раніше займався програмуванням на системному рівні.

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

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

Чи враховується пріоритетна черга? Це з’являється майже в кожному написаному нами додатку в реальному часі. Він став частиною стандартної бібліотеки Java лише нещодавно (Java 1.5).

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

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