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 wa
nt 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++, t
his 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
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.