Serving the Quantitative Finance Community

 
User avatar
Cuchulainn
Topic Author
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Architecture and Design

November 25th, 2011, 4:02 pm

Thijs,I have removed it! What do you think?
Last edited by Cuchulainn on November 24th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Architecture and Design

November 25th, 2011, 4:25 pm

QuoteOriginally posted by: outrunI LOVE YOU! Impressive, does it work/run? Will check it tonight! (on the road at the moment)Flattery will get you nowhere Of course it works! I never post pseudo code!
 
User avatar
Cuchulainn
Topic Author
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Architecture and Design

November 25th, 2011, 5:31 pm

For homework, I want more general container
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

Architecture and Design

November 25th, 2011, 5:37 pm

Just a quick note, regarding this part:QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunthanks!I'm not sure if this is correct, but here is an idea I had:I've quite often used "std::sort" "std::map" etc with my own user-defined compare like below. Could you do the same for the f() in your example and eliminate the need of boost::function?It could be possible but why would you want to eiminate the need for boost function? it is a *protocol* and already subsumes any kind of function you throw at it. You can define any comparitor and use it to instantiate the boost function. It is the same as .NET delegate type vs delegate instance.Do you want to make the s/w so generic that even boost function has been templated away? If so, then the code will be very difficult to understand.and this part:template <typename ReturnType, typename T, typename FO>struct MultipleRole2{ // Simple pipes and filter with a common data //boost::function<ReturnType (T& x)> f; // 'Intrinsic' compute function FO f; // ...}IMHO, some of the difficulty will disappear when using a clear, descriptive naming convention: ReturnType is an example, very good!Instead of "FO" I'd suggest a name corresponding to a concept that FO models -- in this case, the point is not that it's a function object (it could be anything callable, incl. boost::function (or std::function in C++11!), C-style fn ptr, and fn obj, too!) -- and at the same time it's nice for it to be refined enough s.t. the arity is clear -- so, perhaps UnaryOperation? Then, users familiar with the STL should immediately recognize the name and the concept (already documented for us by the SGI, so that's another plus :]) and know what's going on."The basic function object concepts are Generator, Unary Function, and Binary Function: these describe, respectively, objects that can be called as f(), f(x), and f(x,y). (This list could obviously be extended to ternary function and beyond, but, in practice, no STL algorithms require function objects of more than two arguments.) All other function object concepts defined by the STL are refinements of these three. "http://www.sgi.com/tech/stl/functors.ht ... tmlInstead of T perhaps Scalar or even something along the lines of UnaryOperation::ArgumentType -- the second choice is an example of constraining the type to an associated (here: dependent) type, which was actually a subject of a heated discussion on Boost Dev as "Boost.Algorithm design question":http://boost.2283326.n4.nabble.com/Boos ... 76424.html(with both sides making some good points -- incidentally, Cuch & outrun: since we're likely having to (re)make this choice, what do you think is a good design decision here and why?)Of course if we decide on dependent types, then we could go further and specifically say UnaryOperation::ReturnType instead of ReturnType, but that's subject to discussion...
Last edited by Polter on November 24th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Architecture and Design

November 26th, 2011, 7:20 am

QuoteOriginally posted by: outrunThe dependent type discussion is one people have polarizing strong opinions without outlook for consensus because both have pros and cons. I try to come up with an integration of both.Would defaulting to a default trait class type for the dependent type solve it? That way you can explicit specify the type, add your own traits template specialization, or just default to the predefined generic traits.template <FO, ArgumentType = trait<FO>::argument_type>...Can you explain what the traits do? Now that std::function exists (good remark, Polter) can we not just use it as in my original design? Just an idea. QuoteInstead of T perhaps Scalar or even something along the lines of UnaryOperation::ArgumentType --We should standardise on template parasmeter names asap. There is a finite set of possibilities and categories, e.g. Scalar. Numeric, etc. QuoteThe dependent type discussion is one people have polarizing strong opinions without outlook for consensus because both have pros and cons. What are these pros and cons?
Last edited by Cuchulainn on November 25th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Architecture and Design

November 26th, 2011, 4:05 pm

I have seen that template template parameters can resolve some abtruse traits syntax. ttp template <FO, ArgumentType = trait<FO>::argument_type>What If we write ... <XYZ, trait<ABC>> then the compiler won't pick this up? STL is similar: stack<double, list<char>> s;
Last edited by Cuchulainn on November 27th, 2011, 11:00 pm, edited 1 time in total.