Expose seed setting capability in kmedoids.

[kisaacs]

Added a function to set the random seed so I can keep track of what it is and reproduce results.

[tgamblin]

@kisaacs: This looks ok, but did you look at how the parallel algorithms set their seeds? They rely on having the same seed on each process, and they bcast it out on every invocation of capek() and xcapek(). So this setter won't actually work for the parallel algorithms.

I think the right way to address that is to record in kmedoids whether the user overrode the seed, and have the parallel algorithms take the user's value from rank 0 and bcast it if he did. Of course, that could confuse things and get you a deadlock if the user only calls set_seed() on one rank. In which case you might just skip the bcast and document that the user needs to call set_seed() with the same value on all ranks or it's an error, which is more in the spirit of MPI and it's the user's fault if he screws up.

Thoughts?

[kisaacs]

@tgamblin It seemed different enough in spirit that I didn't attempt to insert a corresponding set_seed in par_kmedoid. To make them similar, I would move the time/bcast seed setting to the constructor, remove it from capek/xcapek and then the user can set_seed as you suggested without recording whether the seed was overriden. This change should be transparent to users who don't want to explicitly set a seed. Sound good?

[kisaacs]

Oh wait, looking more closely at how the par_ version is used, I see that won't work and yes we need to record whether the seed has been set.

[tgamblin]

Looks good to me. Thanks!