표준 수치 알고리즘에 라이브러리를 사용하지 않는 것이 일반적입니까? 그 이유는 무엇입니까?

GSL 과 같은 과학 계산 라이브러리에서는 많은 수치 알고리즘 (통합, 미분, 보간, 특수 함수 등)을 사용할 수 있습니다 . 그러나 종종 이러한 기능을 "수동으로"구현 한 코드를 볼 수 있습니다. 반드시 공개 배포 용이 아닌 작은 프로그램의 경우, 계산 과학자들이 필요할 때 숫자 알고리즘을 직접 구현하는 것이 일반적입니까? 그렇다면 GSL과 같은 링크 를 피해야 하는 특별한 이유가 있습니까? 아니면 다른 것보다 "전통적인 것"입니까?

나는 코드 재사용에 대한 열렬한 팬이기 때문에 묻습니다 . 가능한 경우 기존 구현을 사용해야한다고 제안합니다. 그러나 나는 일반적인 프로그래밍보다 과학 계산 에서 원리가 덜 가치있는 이유가 있는지 궁금합니다 .

언급을 잊어 버렸습니다 : 라이브러리를 사용하면 명확한 이점 (실행 속도)이있는 Python과 같은 언어와 달리 C 및 C ++에 대해 구체적으로 묻습니다.

나는 모든 것을 직접 구현했지만 최근에는 라이브러리를 훨씬 더 많이 사용하기 시작했습니다. 루틴을 직접 작성해야하는지 여부에 대한 문제 외에도 라이브러리를 사용하면 몇 가지 매우 중요한 이점이 있다고 생각합니다. 도서관을 이용하면

• 수백 / 수천 / 많은 사용자 가 테스트 한 코드
• 귀하의 작업없이 향후 에도 계속 업데이트 되고 개선 될 코드
• 첫 번째 시도에서 작성하는 것보다 더 효율적 이고 확장 가능한 최적화 된 코드
• 라이브러리에 따라 코드에서 인터페이스를 설정하면 현재 사용하지 않지만 향후 원하는 많은 알고리즘에 액세스 할 수 있습니다

위의 마지막 글에서 Trilinos 또는 PETSc 와 같은 큰 라이브러리를 생각하고 있습니다. PyClaw 개발에서 몇 가지 구체적인 개인 사례를 통해이를 강화할 수 있습니다 . Clawpack 을 MPI 호출과 병렬 처리하는 것이 간단했지만 PETSc 를 사용하기로 선택했습니다. 이를 통해 패키지의 패럴 코드를 300 줄 미만의 Python으로 제한 할 수 있었지만 PETSc 형식으로 데이터를 저장하여 PETSc의 암시 적 솔버에 즉시 액세스하여 PyClaw의 암시 적 솔버에 대한 현재 작업을 가능하게했습니다. 두 번째 예로서, PyClaw는 처음에 수작업 5 차 WENO 재구성을 포함했지만 결국 PyWENO 에 의존하기로 결정했습니다.이것에 대한 패키지. PyWENO가 여러 언어로 어떤 순서의 WENO 루틴을 자동으로 생성 할 수 있기 때문에 이것은 큰 이득이었습니다.

마지막으로, 라이브러리를 사용하는 경우 개선 사항을 개발하거나 버그를 찾아 다시 기여할 수 있으며 , 이는 다른 많은 사람들에게 도움이되는 반면, 자신의 코드를 디버깅하거나 개선하면 혜택을 볼 수 있습니다.

특히 라이브러리가 프로그래머에게 새로운 라이브러리 인 경우 라이브러리 함수에 링크하는 데 상당한 프로그래머 오버 헤드가 있습니다. 특정 라이브러리의 특성을 파악하는 대신 간단한 알고리즘을 다시 작성하는 것이 더 간단한 경우가 많습니다. 알고리즘이 복잡 해짐에 따라이 동작이 전환됩니다.

파이썬은 pip / easy_install과 같은 도구와 균일 한 데이터 구조 인터페이스 (즉, 모든 라이브러리가 numpy 배열을 가져와 생성하는 것처럼 보입니다)를 사용하여이 오버 헤드를 줄이는 데 뛰어났습니다.

제가 지금 참여하고있는 프로젝트 중 하나는 입자 물리 검출기 클래스를위한 유연한 시뮬레이션 및 분석 패키지를 작성하는 것입니다. 이 프로젝트의 목표 중 하나는 앞으로 수십 년 동안 이러한 것들에 사용될 코드 기반을 제공 하는 것입니다.

이 시점에서 우리는 이미 24 가지의 의존성을 가지고 있으며 , 빌드 프로세스가 악의를 불러 일으켜 신뢰할 수있는 툴체인을 제공하기 위해 Fermilab 컴퓨팅 센터에서 관리되는 별도의 프로젝트를 분리했습니다.

이제 그 툴체인에 없는 툴이 필요하다고 상상해보십시오 (지난달에 나에게 일어난 일). 세 가지 선택이 있습니다

1. 당신은 자신의 롤. 모든 위험과 번거 로움이 있습니다.
2. 라이브러리에서 코드를 긁어내어 프로젝트에 지시하십시오. 앞으로는 유지 보수 작업을 수행해야하며, 그러한 상황이 발생하면 다른 사람의 코드를 이해해야합니다.
3. 툴체인을 유지 관리하는 사람들에게 가서 필요한 것을 구걸 한 다음 릴리스주기를 기다려야 합니다. 이 사람들은 반응이 좋지만 작업 코드없이 또는 (1) 또는 (2)를 마친 후에 사례를 만들어야합니다 .

선택하기가 매우 쉽습니다 (1). 아마도 너무 쉬울 것입니다.

필자 는 일부 알고리즘이 다른 알고리즘보다 다시 구현 될 가능성이 높은 것이 일반적 이라고 생각합니다 .

라이브러리 설치가 성가신 방법, 직접 알고리즘을 구현하는 것이 얼마나 어려운지, 최적화하기가 얼마나 힘든지, 라이브러리가 요구 사항에 얼마나 잘 맞는지 간에는 절충이 필요합니다. 또한 때로는 라이브러리를 사용하는 것이 과도합니다. 필자는 몇 번만 호출했기 때문에 프로그램 중 하나에서 느린 이분법 알고리즘을 사용했으며 그 목적으로 라이브러리를 추가하고 싶지 않았습니다.

잘 최적화 된 버전을 작성하는 것이 쉬운가요? 그렇다면, 그렇게하는 것이 좋습니다. 필요한 것을 정확히 얻을 수 있으며 다른 사람의 작업에 의존하지 않습니다. 그러나 물론 당신은 무엇을하고 있는지 알아야합니다. 간단한 알고리즘조차도 구현하기 까다로울 수 있습니다.

이에 대한 연구가 궁금 하겠지만 편견의 관점에서 과학자들은 종종 선형 대수 및 난수 생성기를 위해 라이브러리를 사용하며 나머지 코드는 대부분 수제로 만듭니다.

라이브러리를 사용하는 대신 알고리즘을 구현하면 모델을 더 잘 이해하고 제어 할 수 있다고 생각합니다. 과학적 계산을 위해 일부 프로그램을 코딩 할 때 내가하는 일을 이해하는 것이 중요합니다. 중요한 알고리즘을 구현하면 문제를 더 잘 이해하고 더 잘 제어 할 수 있습니다.

반면에 솔루션을 얻는 데 필요한 라이브러리를 선택하는 것이 쉬운 일이 아니므로 달성하려는 목표가 무엇인지, 왜 원하는지 확신 할 때 이미 구현 된 알고리즘을 검색하는 것이 좋습니다.

알고리즘이 복잡한 경우 직접 코딩하면 작업 별 기능을 사용하여 솔루션의 성능 / 품질을 향상시킬 수 있습니다. 때로는 알고리즘을 약간 변경해야합니다. 작성한 코드를 알고 원하는 방식으로 편집 할 수 있으면 더 쉽습니다.

한 가지 대답은 숫자 코드에 약간의 변형이있어서 라이브러리에서 캡슐화하기가 실제로 어렵다는 것입니다. 설치가 쉽고 입력 및 출력이 분명한 웹 소프트웨어와 비교하여이 기능을 사용하십시오. 프레임 워크 또는 프레임 워크 (Trilinos / PETSc)처럼 작동하는 큰 라이브러리를 잡고 커뮤니티 코드를 사용하는 이점을 얻기 위해 해당 생태계를 사용하는 사람들이 더 일반적이라고 생각합니다.

라이브러리 사용 여부를 결정하기 전에 라이브러리 사용이 코드에 얼마나 도움이되는지 알고 싶을 것입니다. 키 계산 커널에 대해 최적화 된 라이브러리를 사용하려면 직접 작성하는 것보다 훨씬 효율적일 것입니다.

그러나 프로그램 실행 중 한 번만 호출되는 특수 루틴을 작성하는 경우 라이브러리에 필요한 프레임 워크에 맞게 코드를 조정하는 것이 가치가 없을 수 있습니다.

(생각해야 할 또 다른 것 : 라이브러리를 활용하기 위해 얼마나 많은 아키텍처를 다시 작성해야합니까? 코드를 수정하는 데 소요되는 시간이 효율성이나 수치 정확도의 해당 이득으로 보상되지 않는 한, 그렇지 않을 수 있습니다 이상적으로는 데이터 구조와 알고리즘을 처음 설계 할 때 계획 한 것이므로 라이브러리의 "흐름"이 처음부터 고려됩니다.)

내 2 센트

C / C ++보다는 일반적으로 작성하는 것이 더 쉽다고 생각합니다. 첫째, 파이썬과 같은 언어로 된 라이브러리는 결과가 있더라도 속도 이점을 얻는 데 반드시 필요한 것은 아닙니다. @David 가 그 이유를 잘 다루었 다고 생각 합니다.

언어 구현을 맨 위에서 가져 오면 어느 라이브러리에 액세스 할 수 있는지가 결정됩니다. 계산 과학에서 일반적으로 사용되는 언어에는 C, C ++, Python, Perl, Java, Fortran 및 R이 있습니다. 덜 일반적인 예는 Ocaml 및 Common Lisp입니다. 이제 이러한 언어의 대부분이 C로 작성 되었으므로 C에 대한 자연적인 외부 함수 인터페이스 가 있습니다. 그러나 파이썬에서 Perl 라이브러리를 호출하는 것은 쉽지 않습니다. 실제로 사람들은

1. 구현 언어로 작성된 라이브러리, 일반적으로 표준 라이브러리의 일부이거나 광범위하게 사용 가능한 것 또는

2. 언어 FFI를 통해 C / C ++ 라이브러리를 호출하십시오. 이것은 랩퍼가 존재하지 않는 것으로 가정합니다. 랩퍼가 있으면 (1)과 쉽게 구별 할 수 없기 때문입니다.

C / C ++ 함수를 직접 랩핑해야하기 때문에 (2)는 일반적으로 더 어렵다. 또한 라이브러리를 번들로 제공하거나 추가 종속성을 추가해야합니다. 이러한 이유로 사람들은 예를 들어 C에있는 GSL을 사용하지 않고 내장 언어 라이브러리를 사용할 가능성이 높습니다.

분포에서 랜덤 샘플을 생성하거나 적분의 직교와 같은 기본 수치 루틴을 생성하는 것과 같은 매우 일반적인 루틴의 경우 일부 라이브러리를 재사용하는 것이 쉽고 일반적입니다. 구현하려는 기능이 더 복잡 해짐에 따라 다른 라이브러리에서 원하는 정확한 기능을 찾을 가능성이 기하 급수적으로 높아질 수 있으며, 심지어는 기능을 검색하고 최종적으로 조정하는 데 많은 시간을 소비 할 수 있습니다 필요합니다 (예 : 코드 스타일 / 디자인이 문제가 될 수 있음). 그리고 위에서 논의한 바와 같이, 라이브러리의 일부에만 접근 할 수 있습니다. 반면에 알고리즘이 복잡하고 주요 초점이 아닌 경우 스스로 알고리즘을 구현하는 것은 어려울 수 있으며 물론 그 성가신 속도 문제를 해결해야합니다.

따라서 이것은 비용 / 이익 분석에서 최적화 문제가됩니다. 내 경험은 MCMC와 같은 비교적 표준적인 기술조차도 전체 소프트웨어를 설계하는 방법에 더 적합하기 때문에 일반적으로 자체 코드를 작성하는 것입니다.

물론 코드를 사용하지 않더라도 다른 사람들의 코드에서 배울 수 있습니다. 그러나 과학자들이 실제로 얼마나 자주 귀찮게하는지 모르겠습니다. 다른 사람들의 코드를 배우는 것이 소프트웨어 엔지니어 일 것입니다.

저의 2 학년 역학 코스를 되돌아 보면, 내가 알고있는 알고리즘의 자체 버전을 구현 한 이유 중 일부는 내가 그렇게하는 법을 배운 것입니다. 저학 물리학 교육에서 도서관과 인터페이스하고 링크하는 방법을 배운 단일 사례는 생각할 수 없습니다. FORTRAN에서 결합 된 뉴턴 방정식의 솔루션을 계산하여 회전 골프 공의 좌표 목록을 처음으로 보는 것을 좋아합니다. 처음부터 물건을 계산할 때 나오는 스릴과 만족 (자존심조차도)이 있습니다.

테스트 된 라이브러리를 가능한 많이 사용해야한다고 생각합니다. 대부분의 사람들은 수치 컴퓨팅 전문가가 아니며 테스트를 거친 라이브러리에서 사용 가능한 것만 큼 정확하고 신중하게 솔루션을 구현할 수 없을 것입니다. 그러나 주어진 응용 프로그램에 필요한 기능 조합을 구현하는 사용 가능한 라이브러리가없는 경우가 있습니다. 나는 이것이 내가 일하는 기술 분야에서 일어나는 것을 보았다. 기존 코드는 모든 경우를 해결하지 못했으며 누군가가 처음부터 솔버를 구현했습니다.

근본적인 문제는 종종 응용 프로그램과 라이브러리 간의 인터페이스에 있습니다. 응용 프로그램 프로그래머는 문제점 (예 : 매트릭스)을 라이브러리에 전달할 때 종종 손실되는 문제점에 대해 알고 있습니다. 이 지식은 그것을 활용하는 것이 고도로 최적화 된 라이브러리를 사용하는 것의 이점을 상쇄하는 것입니다. 결과적으로 응용 프로그램 프로그래머는 지식을 활용하는 자체 구현을 "롤"합니다.

따라서, 정말 좋은 라이브러리는 그러한 지식이 응용 프로그램에서 라이브러리로 전달되어야 라이브러리가이를 활용할 수 있어야합니다.

위에서 언급 한 모든 것 외에도 "Fortran vs C ++"질문에서 답을 반복하겠습니다. 프로그래머가 가진 가장 소중한 자산은 그녀의 시간입니다. 그렇습니다. 외부 의존성은 종종 어색합니다. 그러나 다른 사람들이 이미 구현 한 알고리즘을 다시 구현하고 디버그하고 테스트하는 데 시간을 소비하는 것은 거의 항상 어리석은 일이며 전문가가 특정 주제에 대해 작성한 코드만큼 좋은 결과는 거의 없습니다. 다른 사람들이 한 일을 재사용하십시오!

내가 작업하는 그룹은 라이브러리를 가능한 많이 사용합니다. 나는 소수의 프로그래머 중 한 명이며 나머지 사람들은 그 일에 대한 프로그래밍을 선택했습니다. 그들은 손대지 말아야 할 곳을 알기 위해 자신의 한계를 충분히 알고 있습니다. IMSL이 선호되는 라이브러리입니다. GSL과 같은 것은 라이센스 기관으로 인해 금지되어 있습니다. 비록 이것이 연방 기관이고 우리는 어쨌든 우리의 소프트웨어를 제공하지 않습니다.

"재사용은 주로 사회적 현상입니다. 다른 사람의 소프트웨어를 사용하면

1. 효과가있다
2. 이해할 수있다
3. 그것은 공존 할 수있다
4. 그것은 지원됩니다 (또는 나는 그것을 직접 기꺼이 지원합니다, 대부분은 아닙니다)
5. 경제적입니다
6. 찾을 수 있습니다.

"— B. Stroustrup, C ++ 프로그래밍 언어 2 판 (1991) p. 383.

다른 사람들이 라이브러리를 사용하고 자신의 루틴을 롤링해야하는 몇 가지 이유가 있습니다.

라이브러리 루틴이 다루는 광범위한 값이나 루틴이 제공하는 정확성이 필요하지 않다는 것을 사전에 알고 있기 때문에 특정 애플리케이션에 대한 계산 속도를 높일 수도 있습니다.

물론 많은 것은 특정 응용 프로그램과 라이브러리 루틴이 몇 번이나 호출되는지에 달려 있습니다. 작은 범위의 x에 대해 소수의 중요한 수치 만 필요하고 일부 간단한 기술로 필요한 경우 베셀 함수에 대해 라이브러리 루틴을 수십억 번 호출하는 이유는 무엇입니까?

추가 할 것이 거의없고, 코드를 재사용해야합니다. 코드 지속 가능성과 사회에 대한 기여에 관한 것이지만 그 이상입니다.

우리가 코드를 재사용하지 않는 이유는 프로그래머가 시작하면 다른 코드를 이해하기 어렵 기 때문입니다. 고급 C ++에서는 특히 어렵고 순수한 C에서도 몇 가지 트릭을 수행 할 수 있습니다.

처음에는 메소드를 이해하지만 라이브러리에서 구현되지는 않지만 일반적인 인터페이스, 오류 제어 및 규칙으로 라이브러리를 사용하는 방법을 이해하는 경우가 많으며 숙련 된 프로그래머가 문서화 한 경우가 많습니다. LU 인수 분해와 같은 표준 방법을 구현하는 것이 더 좋은 착각을 제공합니다. 또한 새로운 프로그래머는 다른 운영 체제에 대한 코드 테스트, 검증 및 이식성의 가치를 과소 평가합니다. 따라서 최종 이유는 게으름입니다. 자체 코드를 작성하는 것이 더 빠르고 쉬운 솔루션처럼 보입니다.

실제로는 직접 프로그래밍하는 것보다 코드를 사용하고 읽는 방식으로 처음부터 더 많은 것을 배울 수 있습니다.

게으름은 대부분의 시간 동안 나를 운전합니다. 대다수의 사람들도 생각합니다. 같은 이유로, 일부는 처음부터 코드를 작성하고 다른 라이브러리는 기존 라이브러리를 사용합니다.

라이브러리 알고리즘은 자체 구현과 대조적으로 제공합니다.

• 그것들은 일반적이며 템플릿입니다. 나중에 제약 조건이 많은 자체 코드를 변경하지 않고도 구현을 다시 매개 변수화 할 수 있습니다.
• 입력 데이터의 대소 사례가 줄어 듭니다. 볼록 껍질 (convex hull) 알고리즘과 같은 많은 계산 기하학 알고리즘은 예를 들어 3 개의 점의 공선 성을 처리해야합니다. 코드를 배포 할 계획이없고 나중에 자주 코드를 재사용하지 않으려는 경우 이러한 경우를 무시할 수 있습니다.
• 예상 또는 최악의 입력 구성에 대해 최소한의 런타임 복잡성을 제공합니다. 높은 수준의 알고리즘은 브릭을 구축 할 때 종종 낮은 수준의 알고리즘 (예 : 정렬 알고리즘 또는 특수 데이터 유형)을 갖습니다. 빠른 정렬이 데이터를 정렬하는 가장 일반적인 선택 일 수 있지만 알고리즘 구현에서 n (log (n))을 보장해야하는 경우이를 사용할 수 없습니다.
• 그들은 메모리 사용 효율입니다
• 그들은 더 런타임 최적화되어 있습니다
• 지원되는 경우, 특히 메인 브랜치에서 작업하는 경우 일반적으로 "버그"가 없도록 폐쇄됩니다. 잘 분산 된 라이브러리보다 더 테스트 된 것은 없습니다. 모든 버그가 다운되는 것은 아니며 모든 버그가 부당한 결과를 낳지는 않습니다. 알고리즘의 구현은 의도 한대로 좋지 않은 결과를 여전히 수용 할 수 있습니다. 버그가 눈에 띄지 않을수록 한 사람으로서 버그를 감지 할 가능성도 줄어 듭니다.

나는 여전히 이해하기 쉬운 하나의 알고리즘 버전을 구현하기 위해 새 필드를 입력 할 때 여전히 좋다고 생각합니다. 총 시간이 많이 걸립니다. 나는 Press et al이라는 책을 사서 읽었습니다. 나는 그 구현 이전과 구현 중에 항상 많은 이론을 읽었습니다. 그리고 필드의 일반적인 개념을 이해하고 실제로 함정을 경험 한 후에는 모든 측면에서 더 나은 라이브러리 구현으로 넘어갈 시간입니다. 라이브러리 필드에 "hello world"알고리즘을 직접 작성하면 더 나은 라이브러리 사용자가 될 것입니다.

더 큰 팀에서 일하는 경우 팀이 특정 라이브러리를 사용하든 아니든 자신의 선택이 아닐 수도 있습니다. 핵심 팀이 결정을 내릴 수 있습니다. 또한 자체 시간 계획을 사용하여 프로젝트에 라이브러리 바인딩을 담당하는 사람이있을 수 있습니다. 다른 사람의 결정에 의존하지 않고 자신의 시간 계획으로 할 수있는 하나의 알고리즘을 다시 작성합니다.

당신이 혼자 있고 배포하고 싶다면 다른 문제가 있습니다. 가장 유용한 리소스로 다른 많은 소스 코드를 고려합니다. 모든 정보 학자들에게 많은 사람들이 여기에 동의 할 것입니다. 정보학 이외의 응용 분야에서는 사전 컴파일 된 실행 파일을 창에 제공해야 할 수도 있습니다. Linux에서는 오픈 소스 사용 라이브러리의 경우 비교적 쉽게 구성 할 수 있습니다.

독자적으로 알고리즘을 다시 작성하면 자유를 얻게됩니다. 귀하의 프로젝트를 지원하지 않을 수 있습니다 GPL 의 lisence GSL 예를 들어.

책임은 reseachers 관점과 독립적 인 유일한 제한 사항 일 수 있습니다.