시뮬레이션 및 모델링을위한 FP


12

시뮬레이션 / 모델링 프로젝트를 시작하려고합니다. OOP가 이런 종류의 프로젝트에 사용된다는 것을 이미 알고 있습니다. 그러나 Haskell을 연구하면서 구성 요소 시스템을 모델링하기 위해 FP 패러다임을 사용하는 것을 고려했습니다. 좀 더 자세히 설명하겠습니다 :

데이터 세트 (온도 또는 압력과 같은 매개 변수, PDE 및 일부 경계 조건 등)를 특징으로하는 유형 A의 구성 요소와 다른 데이터 집합을 특징으로하는 유형 B의 구성 요소가 있다고 가정 해 봅시다 (다른 또는 동일한 매개 변수, 다른 PDE 및 경계 조건). 각 구성 요소에 적용될 기능 / 방법이 동일하다고 가정합니다 (예 : Galerkin 방법). 상수가 아닌 매개 변수에는 오브젝트의 변경 가능 상태가 사용됩니다.

OOP 접근 방식을 사용하는 경우 각 유형의 데이터를 캡슐화하는 두 개의 객체, PDE 해결 방법 (코드 재사용에 상속이 사용됨) 및 PDE 솔루션을 작성합니다.

반면에 FP 접근 방식을 사용하는 경우 각 구성 요소는 PDE 솔루션을 얻기 위해 데이터 부분과 데이터에 작용하는 기능으로 분류됩니다. 상수가 아닌 매개 변수는 다른 함수 (예 : 시간)로 전달되거나 일종의 가변성 (돌연변이 에뮬레이션 등)으로 표현됩니다.이 접근법은 데이터에 대한 선형 연산이 사소한 것으로 가정하면 더 간단 해 보입니다.

결론적으로, FP 접근 방식을 구현하는 것이 OOP 방식에 비해 실제로 더 간단하고 관리하기 쉬울 것입니까 (pde를 해결하기 위해 다른 유형의 구성 요소 또는 새로운 방법 추가)?

나는 C ++ / Fortran 배경에서 왔으며 전문 프로그래머가 아니므로 내가 잘못한 것을 수정하십시오.

답변:


7

좋은 질문입니다, 나는 비슷한 선을 따라 생각하고 있습니다. 역사적으로, OO 패러다임은 컴퓨터 시뮬레이션의 필요성에서 생겨났습니다.- Simula 의 역사를보십시오 - 스몰 토크 와 같은 초기 OO 언어에도 불구하고 자신이하는 일을 알고있는 사람들 (예 : Alan Kay)이 만든 OO 언어에도 불구하고 OO는 과도하게 사용되고 있습니다. 너무 우연한 복잡성을 초래합니다 .

일반적으로 FP 스타일 프로그램은 OO 프로그램보다 짧고 테스트하기 쉽고 수정하기 쉽습니다. Rob Harrop이 그의 연설 에서 미래는 기능적입니까? 함수와 데이터보다 더 단순 해 질 수는 없습니다. 이 두 가지는 무한대로 구성되어 필요한 추상화를 구성합니다. 따라서 귀하의 질문에 대답하는 한 가지 방법은 (또는 그냥 쉬고 있습니까? :) 가장 높은 수준의 기능은 무엇이며 가장 높은 수준의 입력 데이터-> 출력 데이터는 무엇입니까? 그런 다음 이러한 "알파"함수와 데이터 유형을 다음 추상화 계층으로 나누고 필요에 따라 반복 할 수 있습니다.

귀하의 질문에 대한 또 다른 관점 (답변이 아님)은 StackOverflow 에서이 스레드 (면책 조항, 시작했습니다)를 보는 것입니다. 일부 답변은 매우 흥미 롭습니다 : https : //.com/questions/3431654/how-does- 기능적 프로그래밍-적용-시뮬레이션

이 시점에서 내 자신의 의견은, 당신이 명확한 방식으로 만 상호 작용하는 개별 객체 (예 : 컴퓨터 네트워크 모델)가 실제로 존재하지 않는 상황을 모델링하지 않는 한, 깨끗하고 메시지의 기능에 직접 매핑됩니다. OO 언어를 통과하는 패러다임-FP를 사용하는 것이 더 간단합니다. 시뮬레이션이 널리 보급되고 성능 요구 사항이 가장 중요한 게임 프로그래밍 커뮤니티에서도 숙련 된 개발자가 OO 패러다임에서 벗어나거나 더 많은 FP를 사용하고 있습니다 (예 :이 HN 토론 또는 FP에 대한 John Carmack의 의견 참조)


시뮬레이션에서 OOP를 의심하는 유일한 사람이 아니며 내 질문에 답변 해 주셔서 감사합니다. FP에 대한 John Carmack의 의견을 읽었으며 C ++에서 FP 측면을 구현하는 방법 (객체 복사 또는 입력을 수집하여 함수에 전달)에 대해 생각했지만 C ++로 프로젝트를 시작 해야하는지 여부를 다시 알 수 없습니다 FP 측면이 내장되어 있으므로 필요할 때만 가변성을 표현하므로 Haskell과 같은 FP 언어 대신. 비슷한 문제 / 질문이 있다고 생각하면서 Clojure 또는 FP를 계속 사용하셨습니까?
— heaptobesquare

@ heaptobesquare-예, 시뮬레이션을 작성한다는 목표로 Clojure-fu를 꾸준히 늘리고 있습니다. 아직 보여줄 준비가되어 있지는 않지만 쇼 스토퍼가 보이지 않으며 Clojure의 디자인은 아름답습니다. 예를 들어 필요한 경우 과도 / 변이를 사용할 수 있으며 에이전트는 비동기 측면에 적합합니다. 어느 시점에서 (언제 약속하지
— 않습니까)

Clojure를 살펴 보았지만 S- 표현을 좋아한다고 말할 수는 없습니다. 나는 그것이 실용적이라는 것을 알고 있습니다 (Lisp 코드는 데이터입니다).
— heaptobesquare

@heaptobesquare-s-expressions / Lisp 구문은 실제로 익숙해지기 매우 쉽습니다. 먼저 Clojure 모드가 있는 좋은 편집기 (Emacs 또는 vim, 내 투표는 Emacs, dev.clojure.org/display/doc/Getting+Started+with+Emacs 참조 )를 고르십시오 . 좋은 책을 얻으십시오 (예 : Programming Clojure ), 해킹을 시작하십시오. 기껏해야 몇 주 후, 구문은 배경에서 사라질 것입니다. 너무 완벽하게 일관성이 있기 때문에 기하 급수적으로는 덜 자주 생각하고 더 중요한 것들에 대한 정신적 순환을 해방시킵니다. :)
— limist

나는 확실히 그것을 시도 할 것이다. 리스프의 동질성은 결국 흥미 롭습니다.
— heaptobesquare

2

합리적인 복잡성의 거의 모든 작업에 대해 IMHO는 "FP 스타일 또는 OOP 스타일이 더 나은 선택"이라는 질문에 객관적으로 답변 할 수 없습니다. 일반적으로 이러한 상황에서 문제는 "FP 또는 OOP"가 아니라 문제 해결을 위해 두 패러다임의 가장 좋은 부분을 결합하는 방법입니다.

위에서 스케치 한 문제는 매우 수학적인 것으로 보이며, 일부 행렬 연산이 필요할 것이라고 추측합니다. OOP는 추상 데이터 유형을 모델링하는 데 매우 적합하며 행렬 연산은 행렬 작업을 통해 "매트릭스 객체"로 쉽게 구현할 수 있습니다. 모든 행렬 연산이 행렬 클래스의 일부인 방식으로이를 구현하면 함께 속하는 것을 함께 유지하는 데 도움이되므로 전체적인 구조를 양호하게 유지할 수 있습니다.

반면에 PDE는 함수에 대한 방정식이며 솔루션은 다시 함수일 수 있습니다. 따라서 해당 유형의 "컴포넌트"에 대한 기능적 접근 방식을 사용하면 자연스럽게 보일 수 있습니다. 이러한 함수에는 매트릭스 매개 변수가있을 수 있으며 OOP와 FP를 결합하는 방법의 한 예를 보여줍니다. 또 다른 예는 기능적 도구를 사용하여 특정 연산을 행렬의 모든 요소에 매핑하는 행렬 클래스 구현입니다. 따라서 여기에서도 "OOP 대 FP"가 아니라 "OOP와 FP를 결합한"이 최상의 결과를 제공합니다.


답변 주셔서 감사합니다! 따라서 C ++을 사용하는 경우 구성 요소의 데이터 (매개 변수, 경계 조건 및 PDE)를 객체로 캡슐화하고 함수 (경우에 따라 일부 상위 항목조차)를 정의합니다 매개 변수는 객체의 범위를 벗어나서 객체의 데이터에서 작동하는 효율적인 다른 기능입니다.
— heaptobesquare

@ heaptobesquare : 솔직히 말하면, 그것이 귀하의 경우에 효과적 일지 말할 수 없습니다 . 시도해보고 크게 생각하고 작은 것으로 시작하십시오. "추적자 코드"( artima.com/intv/tracer.html ) 프로그래밍을 시작 하여 가장 잘 작동하는 것과 그렇지 않은 것을 찾으십시오. 무언가가 제대로 작동하지 않는 것을 발견 한 상황이라면 리팩토링하십시오.
— Doc Brown

Haskell에는 BLAS / LAPACK 라이브러리에 대한 바인딩 인 Hmatrix 라이브러리와 OOP 방식을 개인적으로 선택 하는 매우 좋은 구문이 있습니다.
— paul

@ paul : 고마워요, 확실히 살펴 볼게요! Haskell 라이브러리는 일반적으로 일관성 있고 풍부한 컨텐츠입니까? 위키는 그렇게 말하지만 이것이 사실입니까?
— heaptobesquare

@ heaptobesquare : 내가 사용했던 유일한 Haskell 라이브러리는 Parsec (어셈블러 작성에 사용)이지만 사용하는 것을 좋아했습니다. Hmatrix와 Haskell OpenGL 바인딩에 대한 GHCI 탐색 만 수행했지만 꽤 멋져 보입니다. Hmatrix는 MATLAB만큼이나 간결한 것으로 보입니다 (매우 많이 사용했습니다). 제한된 경험을 통해 라이브러리는 일관성이 있습니다. Haskell은 소수의 간단한 빌딩 블록을 기반으로하기 때문입니다. Haskellers는 평범한 일을 좋아하지 않기 때문에 풍부합니다.)
— paul
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.