SERVING THE QUANTITATIVE FINANCE COMMUNITY

Posts: 23951
Joined: September 20th, 2002, 8:30 pm

### sitmo C++ parallel random engine

Cuchulainn
Posts: 60246
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### sitmo C++ parallel random engine

Is there any new updates on the prng software? Cool (?) feature request would be to add these functions so that users don't have to do it themselves Thanks
Last edited by Cuchulainn on February 14th, 2014, 11:00 pm, edited 1 time in total.

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

### sitmo C++ parallel random engine

BTW, there's an interesting post by Ulrich Drepper which is somewhat on topic /* */, http://www.akkadia.org/drepper/blog/html/randomcc.html

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

### sitmo C++ parallel random engine

As for the interface discussion, these two proposals (from the 2014-01-pre-Issaquah mailing) raise some issues (with proposed solutions), might be worth a look:- A sample (random sampling) Proposalhttp://www.open-std.org/jtc1/sc22/wg21/docs/pa ... n3842.pdf- Random Number Generation is Not Simple!http://www.open-std.org/jtc1/sc22/wg21/ ... dfThoughts?

Cuchulainn
Posts: 60246
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### sitmo C++ parallel random engine

QuoteOriginally posted by: outrunNice ideas, I have no strong opinions about them..I once tried to add a multivariate normal distribution to boost math (the density pdf, cdf etc, *not* random sampling) and that was already too complicated: what to do with the cov, the x vector...? I couldn't solve the discussions at the time...A thing I would design different is the returning of a array container in the link in the first post (randomcc). There is a need for some pattern like than when generating random sample paths from an SDE. I would provide some "fill_sample_path(output_it, SDE, S0?, t0,dt? -or- t_iterator , ...)" function (this is just a sketch, I haven't thought this through except for the container access part) that gets passed an iterator of SDE::state elements that gets filled (random access for techniques like Brownian bridge, ...for forward Euler path generation a forward iterator would suffice) instead of returning a container.Thoughts?Write some working code up so that people can get an idea of how it works. Then they can give feedback.BTW what's against containers? In almost all cases developers use std::vector<double> anyways?
Last edited by Cuchulainn on February 18th, 2014, 11:00 pm, edited 1 time in total.

Cuchulainn
Posts: 60246
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### sitmo C++ parallel random engine

QuoteOriginally posted by: outrunI'd like to know this: why do you want NextDouble() instead of std::uniform_real_distributionProbably because you're in different language? .NET? That would lead to a generic .NET interface wrapper in top of C++11 engines?It does not have be called NextDouble()!! It's the signature of the function that is more important. And it is _not_ .NET-specific.The issue is prng must be extended by each client code in each language. No problem, just saying.
Last edited by Cuchulainn on February 18th, 2014, 11:00 pm, edited 1 time in total.

Cuchulainn
Posts: 60246
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### sitmo C++ parallel random engine

Instead of the iterator idea as 'driver' I find interfaces in .NET (as in the days of COM) leads to narrow interfaces and loose coupling.
Last edited by Cuchulainn on February 18th, 2014, 11:00 pm, edited 1 time in total.

Cuchulainn
Posts: 60246
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### sitmo C++ parallel random engine

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunNice ideas, I have no strong opinions about them..I once tried to add a multivariate normal distribution to boost math (the density pdf, cdf etc, *not* random sampling) and that was already too complicated: what to do with the cov, the x vector...? I couldn't solve the discussions at the time...A thing I would design different is the returning of a array container in the link in the first post (randomcc). There is a need for some pattern like than when generating random sample paths from an SDE. I would provide some "fill_sample_path(output_it, SDE, S0?, t0,dt? -or- t_iterator , ...)" function (this is just a sketch, I haven't thought this through except for the container access part) that gets passed an iterator of SDE::state elements that gets filled (random access for techniques like Brownian bridge, ...for forward Euler path generation a forward iterator would suffice) instead of returning a container.Thoughts?Write some working code up so that people can get an idea of how it works. Then they can give feedback.BTW what's against containers? In almost all cases developers use std::vector<double> anyways?A container is well defines and everybody knows them, just google the definition. It's useless to force people to use vector<double>, what the benefit of that limitation? Do you think writing a template and using design concepts is too difficult? For SDE one could use a vector of states to store a path. The state for stoch vol models could eg be 2 doubles, my hunch is that the SDE type should provide its "state type".As I mentioned, provide a simple C++ code case to test your hypothesis. And let developers give their opinions!And many developers are not all that comfortable with the STL concepts. And at the end of the day most developers use std::vector<double> anyways.However, I do see the point of using generic concepts, but it you know it's a helluva lot of work. An engineering compromise is usually what happens with developers.
Last edited by Cuchulainn on February 18th, 2014, 11:00 pm, edited 1 time in total.