Serving the Quantitative Finance Community

• 1
• 2

DevonFangs
Topic Author
Posts: 3004
Joined: November 9th, 2009, 1:49 pm

### boost::bind + boost::math::quantile

I'm lazy I know, but how can I get this work with a decent syntax? I guess I have to specify all the template args... The idea is that make_x calculates the quantile of all the values in x and stores them again in x (I know it doesn't make any sense, this is toy code).
Last edited by DevonFangs on March 25th, 2012, 10:00 pm, edited 1 time in total.

DevonFangs
Topic Author
Posts: 3004
Joined: November 9th, 2009, 1:49 pm

### boost::bind + boost::math::quantile

Done, I wrote a wrapper. Then just pass wrap_quantile<D> to boost::bind, and automatic template arg deduction works just fine.

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

QuoteOriginally posted by: DevonFangsI'm lazy I know, but how can I get this work with a decent syntax? I guess I have to specify all the template args... The idea is that make_x calculates the quantile of all the values in x and stores them again in x (I know it doesn't make any sense, this is toy code).Where the main()? (and include ..)
Last edited by Cuchulainn on March 25th, 2012, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

DevonFangs
Topic Author
Posts: 3004
Joined: November 9th, 2009, 1:49 pm

### boost::bind + boost::math::quantile

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: DevonFangsI'm lazy I know, but how can I get this work with a decent syntax? I guess I have to specify all the template args... The idea is that make_x calculates the quantile of all the values in x and stores them again in x (I know it doesn't make any sense, this is toy code).Where the main()? (and include ..)no time now to check if it compiles or not but something like this

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

I got a bunh of errors, so I tried C++ 11. I used cdf easier than quantile I fear your solution needs a couple of _1 (Bind and Lambda). I have become deskilled since C++ 11
Last edited by Cuchulainn on March 26th, 2012, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

This code does work, BUT "distribution_" is a _captured var_ (aka in closure), so use Phoenix .. or C++11. edit: I would say 1) use C++ 11 or 2) use a less ambitious design in short term or 3) Phoenix.http://en.wikipedia.org/wiki/Closure_%2 ... science%29
Last edited by Cuchulainn on March 26th, 2012, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

DevonFangs
Topic Author
Posts: 3004
Joined: November 9th, 2009, 1:49 pm

### boost::bind + boost::math::quantile

QuoteOriginally posted by: CuchulainnThis code does work, BUT "distribution_" is a _captured var_ (aka in closure), so use Phoenix .. or C++11. edit: I would say 1) use C++ 11 or 2) use a less ambitious design in short term or 3) Phoenix.http://en.wikipedia.org/wiki/Closure_%2 ... ksActually I got it working with boost::bind, using the wrapper I posted

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

QuoteOriginally posted by: DevonFangsQuoteOriginally posted by: CuchulainnThis code does work, BUT "distribution_" is a _captured var_ (aka in closure), so use Phoenix .. or C++11. edit: I would say 1) use C++ 11 or 2) use a less ambitious design in short term or 3) Phoenix.http://en.wikipedia.org/wiki/Closure_%2 ... ksActually I got it working with boost::bind, using the wrapper I posted You will need a wrapper for each new function?
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

DevonFangs
Topic Author
Posts: 3004
Joined: November 9th, 2009, 1:49 pm

### boost::bind + boost::math::quantile

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: DevonFangsQuoteOriginally posted by: CuchulainnThis code does work, BUT "distribution_" is a _captured var_ (aka in closure), so use Phoenix .. or C++11. edit: I would say 1) use C++ 11 or 2) use a less ambitious design in short term or 3) Phoenix.http://en.wikipedia.org/wiki/Closure_%2 ... ksActually I got it working with boost::bind, using the wrapper I posted You will need a wrapper for each new function?Not for each distribution, but for at least some functions (to be put in place of quantile) I think so. I guess one can add a template argument to the ThisClass class for the function to be bound and figure out while writing new functions which need a wrapper and which don't...

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

QuoteOriginally posted by: DevonFangsQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: DevonFangsQuoteOriginally posted by: CuchulainnThis code does work, BUT "distribution_" is a _captured var_ (aka in closure), so use Phoenix .. or C++11. edit: I would say 1) use C++ 11 or 2) use a less ambitious design in short term or 3) Phoenix.http://en.wikipedia.org/wiki/Closure_%2 ... ksActually I got it working with boost::bind, using the wrapper I posted You will need a wrapper for each new function?Not for each distribution, but for at least some functions (to be put in place of quantile) I think so. I guess one can add a template argument to the ThisClass class for the function to be bound and figure out while writing new functions which need a wrapper and which don't...Would a template template parameter work? if nothing else, it is another level of indirection. We discussed these before here.
Last edited by Cuchulainn on March 26th, 2012, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

In general, bind1st, bind2nd and std::bind is cryptic and somewhat confusing. Thinking at a higher level (mathematically) it is possible to do it in a more readable form (we could compare it with Meyers' example item #34) and my design can be generalised to other cases as well.I have also included OP's original problem with std::transform().
Last edited by Cuchulainn on April 4th, 2015, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

### boost::bind + boost::math::quantile

Notes:- std::bind1st, std::bind2nd have been deprecated since C++11 and are planned to be removed in C++17: http://en.cppreference.com/w/cpp/utilit ... l/bind12Of interest, the proposal, N4190, notes:QuoteThis defines bind1st()/bind2nd(), which were strictly superseded by bind(). (In the future, I'll argue that bind() itself has been superseded by lambdas and especially generic lambdas, so bind() should be deprecated, but that isn't part of this proposal.)- Storing lambdas (or function objects std::binder1st, std::binder2nd) in std::function is premature pessimization. Consider using type deduction instead (auto, decltype), perhaps with signatures similar to those in N3421 (linked below).- Check out proposal N3421, Making Operator Functors greater<>: http://www.open-std.org/jtc1/sc22/wg21/ ... 21.htmIt's been approved for C++14 and is already implemented in, e.g., Clang: http://libcxx.llvm.org/cxx1y_status.htmlPerhaps you may find it interesting for tackling these kinds of issues (if anything, you can take a look at Sections IV. Design Decisions and VIII. Implementation for ideas / inspiration).// There's also been a related interesting proposal: http://isocpp.org/files/papers/n3617.txt
Last edited by Polter on April 4th, 2015, 10:00 pm, edited 1 time in total.

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

Yes, I know. Perversely, bind1st and bind2nd feel mathematically more precise than std::bind. They basically implement partial function application. But yeah, they are old hat.I simulated bind by using lambda. It compiles and runs. It was a side-show to test the lambda functions.Quote Storing lambdas (or function objects std::binder1st, std::binder2nd) in std::function is premature pessimization.I don't understand anything in this sentence.I suppose the concern is performance? What's the advantage? I have not tested performance, yet.One thing I like about std::function<R (D)> is that it is close to maths i.e. F: D -> R. Most links are very technical and is for compiler builders; a good example of do and don'ts would be better.
Last edited by Cuchulainn on April 4th, 2015, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl

Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

### boost::bind + boost::math::quantile

Check out EMC++ (Effective Modern C++) by Scott Meyers.// The best-practices book for C++11 and C++14 :-)In particular, quoting selectively from Item 5: Prefer auto to explicit type declarations:QuoteIt's important to recognize that even setting aside the syntactic verbosity and need to repeat the parameter types, using std::function is not the same as using auto. An auto-declared variable holding a closure has the same type as the closure, and as such it uses only as much memory as the closure requires. The type of a std::function-declared variable holding a closure is an instantiation of the std::function template, and that has a fixed size for any given signature. This size may not be adequate for the closure it's asked to store, and when that's the case, the std::function constructor will allocate heap memory to store the closure. The result is that the std::function object typically uses more memory than the auto-declared object.And, thanks to implementation details that restrict inlining and yield indirect function calls, invoking a closure via a std::function object is almost certain to be slower than calling it via an auto-declared object. In other words, the std::function approach is generally bigger and slower than the auto approach, and it may yield out-of-memory exceptions, too. Plus, as you can see in the examples above, writing auto is a whole lot less work than writing the type of the std::function instantiation. In the competition between auto and std::function for holding a closure, it's pretty much game, set, and match for auto. (A similar argument can be made for auto over std::function for holding the result of calls to std::bind, but in Item 34, I do my best to convince you to use lambdas instead of std::bind, anyway.)It's important not to overlook the (aforementioned) exception safety implications! Note: http://en.cppreference.com/w/cpp/utilit ... ptionsThis has costs beyond performance (user-friendliness / complexity, maintenance)...Item 34: Prefer lambdas to std::bind is worth a look, too!
Last edited by Polter on April 4th, 2015, 10:00 pm, edited 1 time in total.

Cuchulainn
Posts: 65000
Joined: July 16th, 2004, 7:38 am
Location: Drosophila melanogaster
Contact:

### boost::bind + boost::math::quantile

Yes, I have the bookQuoteItem 34: Prefer lambdas to std::bind is worth a look, too!The example is too verbose IMO.My motivation for lambda/std::bind is Josuttis pages {31,499}. Once you read his examples it become clear. QuoteItem 5: Prefer auto to explicit type declarations:At least, it is less verbose and error-prone. That's a no-brainer.This is worth reading indeed. However, the conclusions in the book are not backed up by numbers. I agree; leave it to the compiler. QuoteThe result is that the std::function object typically uses more memory than the auto-declared object.And, thanks to implementation details that restrict inlining and yield indirect function calls, invoking a closure via a std::function object is almost certain to be slower than calling it via an auto-declared object. In other words, the std::function approach is generally bigger and slower than the auto approach,Sounds plausible; has it been quantified? e.g. std::function is n times slower and uses m times as much memory?Anyway, you can do a replace to auto in V2, yes? Problem solved.
Last edited by Cuchulainn on April 4th, 2015, 10:00 pm, edited 1 time in total.
"Compatibility means deliberately repeating other people's mistakes."
David Wheeler

http://www.datasimfinancial.com
http://www.datasim.nl