Page 3 of 3

Re: Duck Typing

Posted: June 6th, 2017, 2:53 pm
by outrun
 You mean in the code you posted, or do you mean in the tag dispatching code I posted?
In general I think it's good to use C++11 features if those save you time or make things look cleaner. Meyers is very analytical and make rational design choices (instead of subjective design choices). If he suggest things than IMO that's always something to try and understand?

Do you have his "Overview of the new C++11/C++14" slides? That's a nice compact overview, pp  presenation style.

Re: Duck Typing

Posted: June 6th, 2017, 3:52 pm
by Cuchulainn
I am referring to replacing the typedef stuff in your code by the alias template. 
The limitations of typedef and pre-C+11 workarounds have been around since C++03. Now it might be possible to make the code more readable.

www.cppreference.com is the most precise account of C++11 for me. 

Re: Duck Typing

Posted: June 6th, 2017, 4:09 pm
by Cuchulainn
On another level, the Boost/C++11 community could (should) tell how to design using new C++11 features. Meyers discusses simple widgets classes which is not enough.

Now it looks like reverse engineering.

Re: Duck Typing

Posted: June 6th, 2017, 5:10 pm
by outrun
I am referring to replacing the typedef stuff in your code by the alias template. 
The limitations of typedef and pre-C+11 workarounds have been around since C++03. Now it might be possible to make the code more readable.

http://www.cppreference.com is the most precise account of C++11 for me. 
The typedef aren't template parameter dependent types, they are "tags", like little stickers "I'm American", "I'm a Call". The tags are nothing more than empty struct with unique names you want to glue to you class and which cary information for the compiler.  You *could* e.g. replace it with a variable "bool is_american;" but that's not good. The compiler won't know the value, it will consume memory, the code will need to test it run-time. I don't see how you can get around having to specify a list of tags?
...but I'm no expert on the new C++11/14 features! I went pretty deep in C++ in 2008, that's where I used these patterns, but now I'm no longer up to speed.

Re: Duck Typing

Posted: June 29th, 2017, 7:39 pm
by Cuchulainn
Duck typing and PBD is detailed design and too data oriented. What's more crucial is to pin down provides-requires interface between components. I don't want all the data being spread around in argument lists, at least not just yet.

Once the s/w contracts are in place, let each group design their own component. We tell them what interfaces we require and then they deliver. You can stick in any data you want as long as no other components see it.

Re: Duck Typing

Posted: June 29th, 2017, 7:51 pm
by Cuchulainn
Example: The main components in a MC solver, pure interface-driven. You can plug in any stuff you want as long as you respect the interface contract. It's a bit like hardware.
public interface ISde
{ // Standard one-factor SDE dX = a(X,t)dt + b(X,t)dW, X(0)given
  //                         dX = mu(X,t)dt + sig(X,t)dW


    double Drift(double x, double t);          // a (mu)
    double Diffusion(double x, double t);      // b (sig)

    // Some extra functions associated with the SDE
    double DriftCorrected(double x, double t, double B);
    double DiffusionDerivative(double x, double t);

    double InitialCondition
    {
        get;
        set;
    }

    double Expiry
    {
        get;
        set;
    }
}

public interface IFdm
{ // Interface for one-step FDM methods for SDEs

    // Choose which SDE model to use
    ISde StochasticEquation
    {
        get;
        set;
    }

    // Advance solution from level t[n] to level t[n+1]
    double advance(double xn, double tn, double dt, double WienerIncrement, double WienerIncrement2);
}


public interface IRng
{
    double GenerateRn();
}

public abstract class Rng : IRng
{
    public abstract double GenerateRn();
}


public interface IPricer
{
    void ProcessPath(ref double[] arr); // The path from the evolver
    void PostProcess();                 // Finish off computations
    double DiscountFactor();            // (simple) discounting function
    double Price();                     // Computed option price

}


public class MCBuilder<S, F, R>
    where S : ISde
    where F : IFdm
    where R : IRng

{
    // etc.
}

I can't think of any design that is more maintainable than this one (I've tried..)

Re: Duck Typing

Posted: June 29th, 2017, 8:01 pm
by Cuchulainn
To configure with a Builder just bung in the assemblies dll ! You can even load/unload dlls at run-time.

BTW the same design approach can be applied to a wide range of problems.
   MCBuilder<ISde, FdmBase, IRng> builder = new 
                           MCBuilder<ISde, FdmBase, IRng>(data);
        var parts = builder.Parts();
        var path = builder.GetPaths();
        var finish = builder.GetEnd();
        MCMediator mcp = new 
                      MCMediator(parts, path, finish, data.Item7);
        mcp.start();

Re: Duck Typing

Posted: June 29th, 2017, 8:41 pm
by outrun
Make drift etc. a non-member functions, it promotes loose coupling

double drift(SDE& sde, double x, double t);
etc.

Re: Duck Typing

Posted: June 29th, 2017, 8:48 pm
by Cuchulainn
Make drift etc. a non-member functions, it promotes loose coupling

double drift(SDE& sde, double x, double t);
etc.
I hear what you are saying, but what the compelling reason for this approach? And it's compile-time.
It's a design choice indeed. But C# does not support non-member unless it's a static method. 

I think your solution will be difficult to maintain. Just think of shared data. You need a class to hold it all together.
I welcome being proved wrong. Have you actually developed a MC prototype using the approach? Showing running code >> pseudocode.

Re: Duck Typing

Posted: June 29th, 2017, 8:54 pm
by Cuchulainn
Make drift etc. a non-member functions, it promotes loose coupling

double drift(SDE& sde, double x, double t);
etc.
I have the framework also in C++ (remember QFCL that got nuked ?) using the C# approach. I can try this non-member approach as well. and take a vote. Like at the snack bar you have Frites with {mayo, ketchup., peanut butter, HP sauce}. Some people are allergic to peanuts.

Those were the QFCL days
viewtopic.php?f=44&t=96115

Re: Duck Typing

Posted: June 29th, 2017, 9:14 pm
by outrun
Yes, give it a try in C++, I think it will scale better, the interface will be more like small lego bricks instead of monolithic interfaces (classes where you have to add members as you use them in new situations). 

IMO it's not a matter of taste but a design decision based rational/convincing arguments. I think we've talked about this a lot many times? It's amongst others in Effective C++,  this stackoverflow discussion give a good argument. And here is someone discussion how std::basic_string has too many member functions and how it could have been better.

Should be fun to experiment with these design choices!

Re: Duck Typing

Posted: June 30th, 2017, 8:11 am
by Cuchulainn
Yes, give it a try in C++, I think it will scale better, the interface will be more like small lego bricks instead of monolithic interfaces (classes where you have to add members as you use them in new situations). 

I already have tried this approach as I mentioned and it tends to be difficult as the size gets bigger, 

The (toy) examples on Stack are not useful for a number of reasons. I do not see them scaling well and they are too much focused on C++. The basic_string issue is a bit worn out at this stage. Maybe it works for small problems but I don't see how it can be applied to larger libraries and frameworks. It's undocumented AFAIK.

I need bigger examples for sparring with.

Re: Duck Typing

Posted: June 30th, 2017, 8:19 am
by Cuchulainn
On a more philosophical level (is it OK?) is that each developer has one or more models of realty. 

No two languages are ever sufficiently similar to be considered as representing the same social reality. The worlds in which different societies live are distinct worlds, not merely the same world with different labels attached. Edward Sapir
 
The diversity of languages is not a diversity of signs and sounds but a diversity of views of the world.
Wilhelm von Humboldt


Image

Re: Duck Typing

Posted: June 30th, 2017, 9:50 am
by outrun
The toy models at stackoverflow are of course not the reason why c++ expert advocate these rules.

But you are free to do whatever you like of course!

Re: Duck Typing

Posted: June 30th, 2017, 10:03 am
by outrun
I already have tried this approach as I mentioned and it tends to be difficult as the size gets bigger, 
Can you show it? This doesn't sound right. When done right it will scale much better.