> On Feb 3, 2015, at 20:22 , Peter Simon <[email protected]> wrote: > > Thanks, I will take a look at functors when I upgrade to 0.4. I'm not a very > sophisticated programmer (no functional programming experience). I looked up > but didn't understand the description of monads at Wikipedia. > > It seems like this feature isn't something that most people on this list want > or need, so maybe I'm suffering from "premature closure" on the problem I'm > actually interested in. The scenario I have in mind is an objective function > to be used in a black-box optimization (no information available other than > the objective function value). The objective function needs to do a lot of > expensive set-up computations when it is first called, but can re-use this > same data on the second and subsequent calls. Is having the objective > function save its state between calls not the right approach here? > > On Tuesday, February 3, 2015 at 4:26:40 PM UTC-8, Steven G. Johnson wrote: > On Tuesday, February 3, 2015 at 1:11:36 PM UTC-5, Peter Simon wrote: > I saw a suggestion from Miles Lubin in > https://groups.google.com/forum/#!topic/julia-opt/z8Ld4-kdvCI for avoiding > redundant calculations that appeared to involve saving state between function > calls, and I wonder what is the standard Julian way to do this. I'm asking > here because this seems to be a general Julia question. In Matlab I would > use a "persistent" variable. What is the corresponding idiom in Julia? > Closures? Or something else? > > I suppose you could simulate this with a functor object. That is, you define > a type that contains fields for the state you need to save, and overload > call(::MyType, args...) so that you can call your type as a function. (This > is a new feature in Julia 0.4.)
I would use an object-oriented approach here, as described in the previous paragraph: Define an object, and perform the expensive operations when the object is created, or the first time this object is called. > (You can probably also use monads if you want to go all functional...) A monad is a description of how such an object could look from the outside, and how you can combine multiple such objects. It doesn't say how it would be implemented. Monads wouldn't work here, since combining monads is different (is more restrictive) than calling functions. -erik -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from https://sks-keyservers.net.
signature.asc
Description: Message signed with OpenPGP using GPGMail
