Re: Problem with inheritance and arbitrary "features" support (via
templates).
* KRao78:
On 13 Nov, 13:02, "Alf P. Steinbach" <al...@start.no> wrote:
It works with the compiler I am using at the moment (Visual Studio
Professional 2008).
Nope.
Have you tested this?
Of course not.
It's invalid code when you instantiate it.
You think it's working because you haven't actually instantiated it.
Moreover (at least to my understanding), it never inherits from the
same object more then once, as the specializations provided below are
used when only one or two template arguments are specified by the
user.
If the above is never instantiated as-is, then don't define N, don't use
defaults on the template parameters, and don't define the class. Like
template< class T1, class T2, class T3>
class Feature;
That's it.
No, if the user specifies all three template parameters then we need
the inheritance to all three classes T1, T2, T3 and this does not
cause any issues.
For that you need inheritance from all three classes, not defaults on the
template parameters.
Try this.
Keep in mind that when you code you're creating a fine machine. You wouldn't
create a machine by trowing in parts higgedly-piggedly, now would you? Don't do
that when programming, either.
The default argument is needed so that:
Feature<Gaussian,Exponential,Poisson> -> Feature<T1,T2,T2> is used
(which inherits from T1,T2,T3)
Feature<Gaussian,Exponential> -> Feature<T1,T2,N> is used (which
inherits from T1,T2)
Feature<Gaussian> -> Feature<T1,N,N> is used (which inherits from T1)
I still fail to see the problem.
Say I have some code that requires the generation of Exponential and
Gaussian samples.
Then, for the user, it makes perfect sense to be able to work with
objects of type
Rvg<Exponential,Gaussian>* rvgPtr (Rvg stands for Random Variate
Generator) and use it like:
double sample = rvgPtr->gaussian( mu , sigma ); //Where mu and sigma
are doubles
double sample2 = rvgPtr->exponential( mu );
Conceptually we are dealing with a specific random variate generator
(an aggregate of algorithms and one random number generator), so
separating the Gaussian and Exponential "features" is confusing.
Moreover, as in most applications there is the need to work with
multiple distributions, passing around lot of pointers is seriously
inconvenient. The previous version of the library did so and I am
rewriting it for a good reason.
It's unclear where you get all those pointers from.
Are you allocating random number generators dynamically?
Yes. I am going to use Smart Pointers with them.
In that case the appearance of pointers doesn't have much to do with your classes.
It has to do with your decision to allocate dynamically, possibly for the
purpose of sharing.
But what is the purpose of sharing them?
But really I will just select one object (between the possible
candidates) that generate samples accordig to different distributions.
To pass an object by reference, use a C++ reference, not a pointer.
The example above was from the GSL library which is in C.
As stated my intention was to provide a similar inteface, with minimal
performance impact and gretaer generality.
Anyways, at the design level a random number generator is one thing, and a
distribution is another thing that *uses* an rng.
So that means something like
class RandomVariateGenerator
{
public:
virtual double next() = 0;
};
class Gaussian:
public RandomVariateGenerator
{
private:
Random myRng;
public:
double next() { ... }
};
It's as simple as that.
But it's not that simple.
Because for example the CUDA random variate generator just consistes
in some functions that returns samples from distributions (the
connection between the random number generators and random variate
generators is not exposed in the sense that there is no such thing as
a function wich takes in random numbers and returns random variates).
Sorry, that's not meaningful to me.
I respectfully submit that there's something fundamental that you're
overlooking. :-)
And anyway using what you are proposing I would have to work with
multiple pointers, which is my intention to avoid.
Where on earth do you get this pointer stuff from?
Just forget it.
There's no need for it with what you've explained so far, just a random decision
to allocate things dynamically, which you generally don't have to.
This is why I made the original post.
Although as I recall in C++0x the designers managed to mess up even something
this simple. They were thinking in mathematical terms, not in practical terms.
Sort of like hiring a chemist as a chef because she's awfully good with
chemistry, and hey, cooking involves chemistry, right?
As my library will be primarly used by statisticians/mathematicians,
not by expert C++ programmers, I think it makes sense to write it in
such a way that the target users find it intuitive.
That would mean simple and reliable, yes? <g>
I think that something among the lines the GSL library interface is
what I should aim for.
I'm unfamiliar with that so can't comment on its suitability.
Cheers & hth.,
- Alf