Page 2 of 3

F# / F Sharp

Posted: May 27th, 2013, 3:13 pm
by Polter
VivienB: I don't think there's anything necessarily inherently "uni-paradigm" about monads.Just think of them (or, in particular, of monadic binding with the bind operation >>= ) as a simple tool for, e.g., composing stuff, while maintaining separation of concerns: http://www.haskell.org/haskellwiki/MonadFor instance, here's how they can help in composing async ops (in an actor model framework) in C++:[PDF] http://github.com/boostcon/cppnow_prese ... raw=true// see slide 16/17, entitled "The Lack of Monads in C++" -- where the title explains the use of a library-based solution, since this feature is not in the core language; one could say that this could be even taken as an illustration of the point (which you seem to agree with) that tools associated with one paradigm can really shine when combined with others in a multiparadigm approach.

F# / F Sharp

Posted: May 27th, 2013, 3:25 pm
by VivienB
Thanks for the links.

F# / F Sharp

Posted: May 27th, 2013, 4:29 pm
by Polter
Interestingly, monadic IO is what makes Haskell impure: http://conal.net/blog/posts/the-c-langu ... ionalConal (the author of this post) seems to suggest this makes IO "an imperative crutch."Personally, I'm wondering whether, as opposed to being a problem, it's not a sign of pragmatism :-)

F# / F Sharp

Posted: May 27th, 2013, 5:36 pm
by Cuchulainn
QuoteOriginally posted by: VivienBQuoteOriginally posted by: chocolatemoney"Monads look like a patch to allow mutability in pure FP."Monads are much more than that.You might be right, I'm not that much familiar with monads.QuoteOriginally posted by: chocolatemoney.. If a PDE solves for the evolution of a system in time, then at some point, the PDE solver will inevitably need to deal with state (as opposed to a functional stateless implementation) Hence, one more reason to use monads and monadic functions (well, unless you just want to give up and go imperative)I don't see where you need states. I think PDE can be implemented in a pure functional style without using monad (or imperative prog).Btw, yes, in some case, I prefer to give up and go imperative. IMHO, whatever the paradigm, it is not a good idea to follow only this paradigm.I see monads (computational expressions) as data/worflow computational engines like a pipeline. But AFAIK this is generated data that is thrown away at some stage. Not every app is a pipeline.But there are other data types (e.g. a complex lattice model with complex node data and structure) and we want to have functions operating on it for ctor, forward+ backward induction, discrete div, early exercise etc. Then the functional model is perfect IMO (e.g. in C++ use std::function and std::bind for existing OO member functions and this works) and I reckon it will work for F# as well. Since it is syntax-based interface we can use the same data + algos for lattice interpolation models in numerical analysis.I think a two-layer model is good:1. Data (OOP + structs)2. Function (FP aproach + all that fold stuff) operating (read and write) on the data in level 1. You can use OOP for this layer using subtype polymorphism but explosion in the number of classes... Tuples are also very useful; how did we live without them in C++ for the last 25 years?Neither a pure OOP nor pure FP be? Gut feeling is pure FP is not the way to go.// Inside STL there's a wee FP model trying to escape (map and reduce).//Monads feel not even wrong. Category theory for FP

F# / F Sharp

Posted: May 27th, 2013, 6:51 pm
by Cuchulainn
What do you think of F# Math (II.) - Using matrices for graph algorithms.InnovativeOK,Can do the same in C# etc.Solution look for problemAdded value in FP , not data structure???

F# / F Sharp

Posted: May 28th, 2013, 6:32 am
by VivienB
QuoteOriginally posted by: CuchulainnI think a two-layer model is good:1. Data (OOP + structs)2. Function (FP aproach + all that fold stuff) operating (read and write) on the data in level 1. You can use OOP for this layer using subtype polymorphism but explosion in the number of classes...I agree with this model (assuming that some function, eg functions on matrix, are available an can be used functionally inside the FP part).QuoteOriginally posted by: CuchulainnTuples are also very useful; how did we live without them in C++ for the last 25 years?ADT are also very useful (not especially in this case), but are not in C++ (correct me if I'm wrong).

F# / F Sharp

Posted: May 28th, 2013, 7:15 am
by Cuchulainn
QuoteOriginally posted by: VivienBQuoteOriginally posted by: CuchulainnI think a two-layer model is good:1. Data (OOP + structs)2. Function (FP aproach + all that fold stuff) operating (read and write) on the data in level 1. You can use OOP for this layer using subtype polymorphism but explosion in the number of classes...I agree with this model (assuming that some function, eg functions on matrix, are available an can be used functionally inside the FP part).QuoteOriginally posted by: CuchulainnTuples are also very useful; how did we live without them in C++ for the last 25 years?ADT are also very useful (not especially in this case), but are not in C++ (correct me if I'm wrong).So, I think we agree on a ADT + FP model? ADTs are just types, yes? In this would be a class(?)In C++ 11 there is std::tuple (not quite an ADT) and also boost::tupleNiklaus Wirth was rightData Structures + Algorithms = Programs

F# / F Sharp

Posted: May 28th, 2013, 8:50 am
by VivienB
QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: VivienBQuoteOriginally posted by: CuchulainnI think a two-layer model is good:1. Data (OOP + structs)2. Function (FP aproach + all that fold stuff) operating (read and write) on the data in level 1. You can use OOP for this layer using subtype polymorphism but explosion in the number of classes...I agree with this model (assuming that some function, eg functions on matrix, are available an can be used functionally inside the FP part).QuoteOriginally posted by: CuchulainnTuples are also very useful; how did we live without them in C++ for the last 25 years?ADT are also very useful (not especially in this case), but are not in C++ (correct me if I'm wrong).So, I think we agree on a ADT + FP model? ADTs are just types, yes? In this would be a class(?)In C++ 11 there is std::tuple (not quite an ADT) and also boost::tupleNiklaus Wirth was rightData Structures + Algorithms = ProgramsADTs (I used this acronym for Algebraic Data Type, not for Abstract Data Type) are types that represent disjoint unions. It can be used to represent complex data structures instead of using classes. Here is a blog post that explain how to built ADTs in C++ using boost.In our case, it can represent the model parameters type for instance: [$]M=\oplus_i (\{model_i\} \times M_i[$]) where [$]M_i[$] is the set of parameters for the model [$]model_i[$].

F# / F Sharp

Posted: May 28th, 2013, 8:51 am
by Cuchulainn
Here's the kind of approach that I was alluding to; it is super-flexible. ADT Lattice is the level 1 object.

F# / F Sharp

Posted: May 28th, 2013, 9:24 am
by VivienB
I'm sorry, I didn't use C++ for a long time, so your code is not clear for me

F# / F Sharp

Posted: May 28th, 2013, 10:00 am
by chocolatemoney
Yes, we all agree on a mixed model, benefiting from the best of both worlds.Happy to read that my initial guess, back on Friday, has been confirmed.@Vivien:"I don't see where you need states. I think PDE can be implemented in a pure functional style without using monad (or imperative prog)."State, in my mind, is for example applying the scheme on the lattice from t=now to T=expiry, following the application of the ICs and eventually doing something else at expiry.I guess you refer to "lack of mutability" - I call it "state".I thought a monad could take care of the work pipeline.*PURE* Functional programming (scala) is something very new to me - I have been working with Scala for something like 1-2 years.I'd be happy to see your pure functional implementation of a PDE solver, if you could share...PS: Is F# the language of choice at LexiFi?

F# / F Sharp

Posted: May 28th, 2013, 10:06 am
by chocolatemoney
template <typename S, typename T, class Node> Node BackwardInduction(Lattice<S,T,Node, typeBin>& lattice, const std::function<Node (const Node& upper,const Node& lower)>& generator, const std::function<Node (const Node& node)>& endCondition) Shuld BackwardInduction return a void? Does it apply the scheme directly on the lattice, isn't it?

F# / F Sharp

Posted: May 28th, 2013, 10:25 am
by chocolatemoney
Pestering the thread again.Hey, I am not sure I am going in the right direction, but here is a state monad in scala.The idea is that the monad could pass along the lattice, instead of the fibonacci serie, and do all that has to be done.Bad idea?

F# / F Sharp

Posted: May 28th, 2013, 11:08 am
by Cuchulainn
QuoteOriginally posted by: chocolatemoneytemplate <typename S, typename T, class Node> Node BackwardInduction(Lattice<S,T,Node, typeBin>& lattice, const std::function<Node (const Node& upper,const Node& lower)>& generator, const std::function<Node (const Node& node)>& endCondition) Shuld BackwardInduction return a void? Does it apply the scheme directly on the lattice, isn't it?It return a value (e.g. price at t =0 or the value in the lattice interpolation method, e.g. Neville). But maybe a void is better and then just let the client ask for the value at the tip of the lattice.

F# / F Sharp

Posted: May 28th, 2013, 11:11 am
by Cuchulainn
QuoteOriginally posted by: VivienBI'm sorry, I didn't use C++ for a long time, so your code is not clear for me Ok C++ templates are awful cryptic I agree. Here is the V1 code and it feels like choco's state monad moving up the lattice?I am sure it is possible without [] but later.I see 'generator' as a lambda as in the style of STL or C# delegates.hth