STL bind1st counterpart for unary function

[Fred Ma]

Hello,

I have a random generator that takes a scaling factor as an
argument. Since it takes one argument, it is not a
generator in the sense defined by SGI's online STL
documentation. I'd like to use this as a generator in the
STL algorithm "generate". I know I have to change random
generator from its current implementation to make it
adaptable. But unlike the bind1st adapter, there isn't any
premade function adapter that reduces the arity of a unary
function by binding the argument to a constant. So I can't
use it in the STL generate algorithm without writing a
wrapper. It's not a big deal, but it's a bit of a waste to
write a wrapper just to fix the argument of the generator to
one constant value, and just to avoid rolling my own loop to
fill a container with random numbers. Of course I will
write my own one-line loop, but just out pedagogical
curiosity, is there a _simple_ way to use the STL generate
algorithm in this case, using only standardized libraries?

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

[Rolf Magnus]

Fred Ma wrote:

Hello,

I have a random generator that takes a scaling factor as an
argument. Since it takes one argument, it is not a
generator in the sense defined by SGI's online STL
documentation. I'd like to use this as a generator in the
STL algorithm "generate". I know I have to change random
generator from its current implementation to make it
adaptable. But unlike the bind1st adapter, there isn't any
premade function adapter that reduces the arity of a unary
function by binding the argument to a constant. So I can't
use it in the STL generate algorithm without writing a
wrapper. It's not a big deal, but it's a bit of a waste to
write a wrapper just to fix the argument of the generator to
one constant value, and just to avoid rolling my own loop to
fill a container with random numbers. Of course I will
write my own one-line loop, but just out pedagogical
curiosity, is there a _simple_ way to use the STL generate
algorithm in this case, using only standardized libraries?

Why don't you just let the generator's constructor take the argument
instead of its operator()? Something like:

struct random_generator
{
random_generator(double scale) : scale_(scale) {}
double operator()() { //do the magic }
double scale_;
};

And then you can just:

std::generate(container.begin(), container.end(), random_generator(10));

[Fred Ma]

Rolf Magnus wrote:

Why don't you just let the generator's constructor take the argument
instead of its operator()? Something like:

struct random_generator
{
random_generator(double scale) : scale_(scale) {}
double operator()() { //do the magic }
double scale_;
};

And then you can just:

std::generate(container.begin(), container.end(), random_generator(10));

Actually, it may be more complicated than I first thought.
I am using the same random generator at every possible
place where a random number is needed. The generator's
operator() is like most random generators (returning a
real number in the range [0.0,1.0). If I need an integer
from 0 to N-1, the object has a member function that takes
N as an argument. In fact, the member function is a
template, so it can just as easily take a real number R
and give back a real number in the range [0.0,R). Basically,
the member function takes the raw number in [0.0,1.0) and
multiplies it by the argument. For integers, truncation
ensures that the result is an integer in [0,N-1].

Anyway, enough about the insides. The problem is that I
don't want to be constructing all sorts of different
generator objects. The reasons are superstitious rather
than rational. I want to be able to recreate a simulation
by putting in the same random seed as was used the first
time I ran the simulation. Granted, I can still get
replicated behaviour if I ensure that any random generators
get initialized directly or indirectly by a common random
generator whos seed I supply. I'll look into that further
if the need becomes more pressing.

The more complicated problem is that the function is a
member function. I have to do a bit more review of Meyers
to see about how to make those things adaptable.

Thanks for pointing out your alternative. I have to read up
more to address the other possible difficulties.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6