시뮬레이션 및 모델링을위한 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.