STL bind1st counterpart for unary function

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

re: STL bind1st counterpart for unary function

Fred Ma wrote:
[color=blue]
> 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?[/color]

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));

re: STL bind1st counterpart for unary function

Rolf Magnus wrote:[color=blue]
>
>
> 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));[/color]


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