FP-моделирование - вопрос об утилизации

Question

Я собираюсь начать проект моделирования/моделирования.

Предположим, что у меня есть компонент типа A, характеризующийся набором данных (параметр, такой как температура или давление, PDE и некоторые граничные условия и т. Д.) И компонент типа B, отличающийся другим набором данных (разные или одинаковые параметры, разные PDE и граничные условия). Предположим также, что функции/методы, которые будут применяться к каждому компоненту, будут одинаковыми (например, метод Галеркина).

Если бы я использовал подход FP, каждый компонент был бы разбит на части данных и функции, которые будут действовать на данные, чтобы получить решение для PDE. Этот подход кажется мне более простым, полагая, что параметры постоянны. Что делать, если параметры не постоянны (например, температура внезапно увеличивается и, следовательно, не может быть неизменной)?

Что было бы лучшим подходом к решению проблемы изменчивости параметров?

Я пришел из фона C++/Fortran, плюс я не профессиональный программист, поэтому поправьте меня на все, что у меня получилось.

Answer 1

Просто потому, что что-то может измениться, не означает, что он не может быть смоделирован с неизменяемыми данными.

В OOish стиле, позволяет сказать, что у вас есть что-то вроде следующего:

a = some_obj.calculationA(some, arguments); 
b = some_obj.calculationB(more, args); 
return combine(a, b) 

Очевидно calculationA и calculationB зависит от some_obj, и вы даже вручную резьб some_obj через качестве входных данных для обоих вычислений. Вы просто не привыкли видеть, что это то, что вы делаете, потому что вы думаете с точки зрения вызова метода на объект.

Переводя на полпути к Haskell самым очевидным образом это возможно дает вам что-то вроде:

let a = calculationA some_obj some arguments 
    b = calculationB some_obj more args 
in combine a b 

Это действительно не так много хлопот, чтобы вручную передать some_obj в качестве дополнительного параметра ко всем функциям, так как это то, что вы» в любом случае, в стиле OO.

Невероятно, что в стиле OO calculationA и calculationB может измениться some_obj, который может быть использован после этого контекста. Это довольно очевидно, обратиться в функциональном стиле тоже:

let (a, next_obj) = calculationA some_obj some arguments 
    (b, last_obj) = calculationB next_obj more args 
in (combine a b, last_obj) 

Я так привык к мысли о вещах, это «действительно», что происходит в версии ООП в любом случае, с теоретической точки зрения. Каждый измененный объект, доступный для данного куска императивного кода, «действительно» является дополнительным вводом и дополнительным выходом, переданным тайно и неявно. Если вы считаете, что функциональный стиль делает ваши программы слишком сложными, потому что есть десятки дополнительных входов и выходов повсюду, спросите себя, действительно ли программа действительно менее сложна, когда все эти потоки данных все еще остаются там, но скрыты?

Но это, где более высокие абстракции (такие как монады, но они не единственные) приходят на помощь. Лучше не думать о монадах, как-то волшебно, давая вам изменчивое состояние. Вместо этого подумайте о них как об инкапсулирующих шаблонах, поэтому вам не нужно вручную писать код, как указано выше.Когда вы используете монаду State, чтобы получить «программирование с сохранением состояния», все эти потоки состояний через входы и выходы функций все еще продолжаются, но это делается строго регламентированным образом, и функции, в которых это происходит, помечены монадического типа, поэтому вы знаете, что это происходит.