>> > Perhaps we could avoid using a sequential PRNG in distort() >> > altogether? Replace the std::rand() subroutine calls with some kind >> > of function calls that lack internal state, just hashing the initial >> > seed with the previous node coordinates somehow?
Hm, interesting alternative. Or, keep using std::rand, but reseeding for each node with std::srand(seed + node->id())? >> So I think we can immediately accommodate the patch – it certainly does no >> harm – am I missing something? > > > We can instantly accommodate the patch, in the same sense that I can > instantly sell you the Brooklyn Bridge for cash, but in each case > there's an implied promise (distortions with the same seed will always > produce the same results; you'll end up with a valid deed) that would > end up being violated later. I don't like breaking backwards > compatibility, and so I don't like getting into situations that would > back us into a corner where we'd eventually have to break backwards > compatibility. Doesn't the current implementation have the same implied promise, just in a weaker form? I.e., "distortions will always produce the same results"? If my understanding is correct, distorting a serial mesh and a parallel mesh won't produce the same result right now. In that sense, the patch wouldn't make a big difference really, except maybe increasing the chance of a user falling for the promise. Which could be reduced again by disclaiming clearly in the documentation... Roman ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
