Чи часто не використовувати бібліотеки для стандартних числових алгоритмів, і чому?

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

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

Забув згадати: я спеціально запитую про C і C ++, на відміну від мов, таких як Python, де явна перевага (швидкість виконання) від використання бібліотеки.

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

• Код, перевірений сотнями / тисячами / більше користувачів
• Код, який надалі буде оновлюватися та вдосконалюватися в майбутньому, без жодної роботи з вашого боку
• Оптимізований код, який є більш ефективним і, можливо, більш масштабованим, ніж те, що ви написали б у першій спробі
• Залежно від бібліотеки, встановивши інтерфейс до неї у своєму коді, ви можете отримати доступ до багатьох алгоритмів, якими ви зараз не користуєтесь, але можете захотіти в майбутньому

В останньому пункті вище, я думаю про великі бібліотеки, такі як Trilinos або PETSc . Я можу підкріпити це декількома конкретними особистими прикладами в розробці PyClaw . Хоча було б просто паралелізувати Clawpack з MPI-дзвінками, ми вирішили використовувати PETSc. Це дозволило нам обмежити паралельний код у пакеті менш ніж на 300 рядків Python, але ще краще, розмістивши наші дані у форматі PETSc, ми отримали негайний доступ до неявних вирішувачів PETSc, що дозволяє поточній роботі над неявним вирішувачем у PyClaw. Як другий приклад, PyClaw спочатку включав реконструкцію WENO п'ятого порядку, але ми врешті вирішили покластися на PyWENOпакет для цього. Це було величезним виграшем, оскільки PyWENO може автоматично генерувати підпрограми WENO будь-якого порядку на кількох мовах.

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

У зв'язку з функцією бібліотеки є значна накладні витрати програміста, особливо якщо ця бібліотека новачка для програміста. Часто простіше просто переписати прості алгоритми, а не з'ясувати специфіку певної бібліотеки. Коли алгоритми стають складнішими, така поведінка перемикається.

Python домігся зменшення цієї накладних витрат за допомогою таких інструментів, як pip / easy_install та рівномірний інтерфейс структури даних (тобто кожна бібліотека, здається, приймає та створює масивний масив).

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

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

А тепер уявіть, що у вас виникає потреба в певному інструменті, який не знаходиться в тій ланцюжку інструментів (це трапилося зі мною минулого місяця). У вас є три варіанти

1. Згорніть свою власну. З усіма ризиками та клопотами, які пов'язані з цим.
2. Викресліть десь код із бібліотеки і включіть його в проект. Це означає, що вам доведеться продовжувати технічне обслуговування, і що вам доведеться зрозуміти чийсь код, коли це станеться.
3. Заходьте до людей, які підтримують ланцюжок інструментів, благайте їх про необхідне, а потім чекайте циклу випуску, щоб отримати його. Ці хлопці досить чуйні, але вам доведеться зробити це для цього без робочого коду або після того, як ви зробили (1) або (2).

Вибрати дуже просто (1). Можливо, занадто просто.

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

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

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

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

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

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

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

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

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

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

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

Мої 2 копійки.

Я думаю, що про це взагалі простіше писати, ніж просто про C / C ++. По-перше, бібліотеки на таких мовах, як Python, не обов'язково використовуються для отримання швидкої вигоди, навіть якщо це є наслідком. Я думаю @David досить добре висвітлював причини.

Беручи це зверху, мовна реалізація певною мірою диктує, до яких бібліотек ви маєте доступ. Найчастіше використовувані мови в обчислювальній науці включають C, C ++, Python, Perl, Java, Fortran та R. Менш поширеними прикладами можуть бути Ocaml та Common Lisp. Тепер, оскільки більшість цих мов написані на C, вони мають природний інтерфейс зовнішньої функції до C. Однак, не так просто викликати, скажімо, бібліотеку Perl з Python чи навпаки. Тож на практиці люди прагнуть до будь-якого

1. Використовуйте бібліотеку, написану мовою їхньої реалізації, звичайно те, що є частиною стандартних бібліотек або іншим чином широко доступним, або

2. Виклик бібліотеки C / C ++ через мови FFI. Це передбачає, що обгортку вже не існує, оскільки, якщо вона є, її не легко відрізнити від (1).

(2), як правило, важче, тому що вам доведеться самостійно обгортати функцію C / C ++. Також вам доведеться або зв'язати бібліотеку, або додати додаткову залежність. З цієї причини люди швидше використовують вбудовані бібліотеки мов, а не використовують GSL, наприклад, на C.

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

Отже, це стає проблемою оптимізації в аналізі витрат / вигод. Мій досвід полягає в тому, що навіть для порівняно стандартних методик, таких як MCMC, я зазвичай закінчую написання власного коду, оскільки він краще відповідає тому, як я розробляю загальне програмне забезпечення.

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

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

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

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

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

На додаток до всього, що вже було сказано вище, я повторю свою відповідь на запитання "Fortran vs C ++": Найцінніший актив програміста - це її час. Так, зовнішні залежності часто незручні. Але витрачати час на повторну реалізацію, налагодження та тестування алгоритмів, які вже реалізували інші, майже завжди нерозумно, і результат також рідко буде таким же хорошим, як код, який написали експерти з певної теми. Повторно використовуйте те, що зробили інші!

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

"Повторне використання - це насамперед соціальне явище. Я можу використовувати чуже програмне забезпечення за умови, що це

1. це працює
2. це зрозуміло
3. вона може співіснувати
4. він підтримується (або я готовий його підтримувати сам, здебільшого я не є)
5. це економно
6. Я можу його знайти.

"- Б. Струструп, Мова програмування на C ++ 2 видання (1991), с. 383.

Інші вагомі причини були дані для використання бібліотек, а також для прокатки власних процедур.

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

Звичайно, багато що залежить від конкретного додатку та скільки разів буде викликана рутина бібліотеки. Чому б ви називали бібліотечну процедуру для функцій Бесселя в мільярди разів, якщо вам потрібно лише кілька значущих цифр для невеликого діапазону x, а якась більш проста техніка буде достатньо для ваших потреб?

Мало додати, нам доведеться повторно використовувати код, мова йде про стійкість коду та внесок у суспільство, але це все вище.

Причина, чому ми не використовуємо повторно код, полягає в тому, що якщо ви починаєте програміст, важко зрозуміти код інших. Особливо складно з розширеним C ++, і ви можете робити деякі трюки і в чистому С.

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

Реальність полягає в тому, що ми можемо дізнатися більше за допомогою та зчитування коду, ніж програмування самостійно з нуля.

Лінь рухає мене більшу частину часу, я думаю, також і більшість людей. З тієї ж причини деякі пишуть код з нуля, а інші використовують наявні бібліотеки.

Алгоритми бібліотек забезпечують на відміну від власних реалізацій:

• Вони родові та шаблонні. Пізніше ви можете повторно перемежувати свою реалізацію, не турбуючись про зміну власного коду, який, як передбачається, має багато обмежень.
• Існує економія порівняно із виродженими випадками вхідних даних. Багато алгоритмів обчислювальної геометрії, наприклад, опуклі корпусні, повинні обробляти, наприклад, колінеарність трьох точок. Ви можете ігнорувати ці випадки, якщо ви ніколи не плануєте поширювати свій код, а також не хочете часто використовувати його в майбутньому.
• Вони забезпечують мінімальну складність виконання для очікуваної або гіршої конфігурації вводу. Алгоритми вищого рівня є алгоритмами, що будують цегли, часто алгоритмами нижчого рівня, наприклад алгоритмами сортування, або спеціальними типами даних. Швидке сортування може бути найпоширенішим вибором для сортування даних, але якщо ваша реалізація алгоритму повинна гарантувати n (log (n)), ви не можете його використовувати.
• Вони ефективні з використанням пам'яті
• Вони додатково оптимізовані
• Якщо він підтримується, набагато більш закритим, щоб взагалі не було "помилок", особливо якщо ви працюєте з основною гілкою. Ніщо не є більш перевіреним, ніж добре розподілена бібліотека. Не кожна помилка виходить з ладу, не кожна помилка дає необґрунтовані результати. Реалізація алгоритму може все-таки дати прийнятні результати, не такі хороші, як призначені. Чим менше бачна помилка, тим менше ймовірність, що ви як одна людина навіть можете її виявити.

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

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

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

Перезапис алгоритму самостійно дає свободу відвідуванню. Ваш проект може не підтримувати GPL- офіс GSLНаприклад, .

Ліцензія може бути єдиним обмеженням, яке не залежить від точки зору шукачів.