0

I am about to start a simulation/modelling project.

Let's say I have a component of type A, characterised by a set of data (a parameter like temperature or pressure,a PDE and some boundary conditions,etc.) and a component of type B, characterised by a different set of data(different or same parameter, different PDE and boundary conditions). Let's also assume that the functions/methods that are going to be applied on each component are the same (a Galerkin method for example).

If I were to use an FP approach, each component would be broken down to data parts and the functions that would act upon the data in order to get the solution for the PDE. This approach seems simpler to me assuming that the parameters are constant. What if the parameters are not constant(for example, temperature increases suddenly and therefore cannot be immutable)?

What would be the best approach to tackle the problem of the mutability of parameters?

I come from a C++/Fortran background, plus I'm not a professional programmer, so correct me on anything that I've got wrong.

heaptobesquare
  • 29
  • 3
  • 2
    Your question is far too vague to give a good answer to. – Yuushi Oct 02 '12 at 00:29
  • Ok,give me a sec to make it a bit more specific. – heaptobesquare Oct 02 '12 at 00:30
  • This kind of question isn't factual or specific enough for this site, you may have better luck at the [programmers SE.](http://programmers.stackexchange.com/) – GManNickG Oct 02 '12 at 00:30
  • First, I don't think one's particularly less time consuming than the other for someone who is really used to both approaches. Second, you could for example make the temperature a function of the time (`temperature :: Time -> Double`), or use some of the mechanisms we have to emulate mutability, or have local mutability, or just plain mutability (through `IORef`s and such). Also, modeling in Haskell isn't necessarily data on one side and functions on the other. Your data could embed functions! `data Foo = Foo { f :: Int -> Int, g :: Double -> Double -> Double, somePair :: (Double, Double) }` – Alp Mestanogullari Oct 02 '12 at 01:09
  • @Alp Mestanogullari: Thank you very much for your answer! I didn't know that data could embed functions,that is what I'm actually after! I thought about temperature being a function of time but then how would I deal with time's mutability? (I am going to change to the question and title again, in order to address only the issue of mutability of parameters. I'm sorry if my question was initially too vague,I'm a first-timer here in stack overflow). – heaptobesquare Oct 02 '12 at 01:47
  • Function Reactive Programming may be of interest to you. I don't know if it has ever been applied to simulation/modelling so far. Let me know when your new question is up. – Alp Mestanogullari Oct 02 '12 at 12:19
  • @Alp Mestanogullari: My current question is: "What would be the best approach to tackle the problem of the mutability of parameters?" About Functional Reactive Programming,how is it different from using the other mechanisms to express mutability? – heaptobesquare Oct 02 '12 at 16:55
  • It's totally different, and may be relevant in your case. You should google it, really. It's not about mutability, it's about a way of modelling. Also, you should post this on haskell-cafe, I think there are a few scientists using haskell, so you may get good answers there. – Alp Mestanogullari Oct 02 '12 at 19:17
  • @Alp Mestanogullari: Thank you, I'll take a look at Functional Reactive Programming ASAP. – heaptobesquare Oct 02 '12 at 21:36

1 Answers1

4

Just because something can change doesn't mean it can't be modelled with immutable data.

In OOish style, lets say you have something like the following:

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

Obviously calculationA and calculationB depend on some_obj, and you're even manually threading some_obj through as inputs to both calculations. You're just not used to seeing that that's what you're doing because you think in terms of invoking a method on an object.

Translating halfway to Haskell in the most obvious way possible gives you something like:

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

It's really not that much trouble to manually pass some_obj as an extra parameter to all the functions, since that's what you're doing in OO style anyway.

The big thing that's missing is that in OO style calculationA and calculationB might change some_obj, which might be used after this context returns as well. That's pretty obvious to address in functional style too:

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

The way I'm used to thinking of things, this is "really" what's going on in the OOP version anyway, from a theoretical point of view. Every mutable object accessible to a given piece of imperative code is "really" an extra input and an extra output, passed secretly and implicitly. If you think the functional style makes your programs too complicated because there are dozens of extra inputs and outputs all over the place, ask yourself if the program is really any less complicated when all that data flow is still there but obscured?

But this is where higher abstractions (such as monads, but they're not the only one) come to the rescue. It's best not to think of monads as somehow magically giving you mutable state. Instead, think of them as encapsulating patterns, so you don't have to manually write code like the above. When you use the State monad to get "stateful programming", all this threading of states through the inputs and outputs of functions is still going on, but it's done in a strictly regimented way, and functions where this is going on are labelled by the monadic type, so you know it's happening.

Ben
  • 68,572
  • 20
  • 126
  • 174
  • Thank you for your very insightful answer! The way Haskell handles operations on data looks actually less complicated from the OOP one and I think it does show on what data the operations are made, in contrast with some_object.calculationA for example. They are essentially the same but as you already said in OOP, "data flow is still there but obscured". So, higher abstractions do what an OOP method does but you know on which data operations are done? – heaptobesquare Oct 02 '12 at 17:09
  • @heaptobesquare *One* use of concepts such as monads is to help you write computations which have access to an environment of some kind (this access can be read only, read/write, or write only, depending on the monad you use). There are many other things you can do with these sorts of concepts; far too many for a comment or even an answer on SO. It's much easier to understand things like monads on their own terms than to think of them as how you implement concepts from other programming languages. – Ben Oct 04 '12 at 03:29