Or just use my drop-in replacement for random number generation in Sphere:
http://forums.spheredev.org/index.php/topic,76.msg963.html#msg963

It would be very possible to expose an API that has a random number generator with a configurable seed value, though.

Indeed, I was just responding to casiotone's assertion that the built-in Math.random() is good enough in most cases outside of cryptography (in which case you should be using an RNG designed for crypto anyway), which isn't the case if you need to set the seed value manually.  But yeah, that's the great thing about JS (and well, pretty much any language with first-class functions): It's very easy to override even built-in APIs with your own version.  In short, monkey-patching is awesome.

You know what would be even better? If you could manually seed Math.random() to begin with.

But yeah, I can see these being very useful for predictable random number generation!

You know what would be even better? If you could manually seed Math.random() to begin with.

But yeah, I can see these being very useful for predictable random number generation!

You can if you punch some duckmonkeys (read: polyfill the existing methods).  But definitely have to agree, it should have been standard.  Hell, even frigging QBasic used to let you set the random number seed!

There is very little stopping an engine from providing a builtin random number generator that can accept an arbitrary seed.

There is very little stopping an engine from providing a builtin random number generator that can accept an arbitrary seed.

The method to set the seed wouldn't be standard, though.

There is very little stopping a standard from providing a builtin random number generator that can accept an arbitrary seed.

@Radnen: Go tell that to ECMA. ;-)

Alright, seeing how long it's taking to get 'const' by, I think a standard would take time there.

In a way though, the lack of a standardized way to seed the generator makes sense though, now that I think about it; the JS standard only specifies behavior and tries to leave runtimes free to implement stuff any way they want.  Adding a seeding method would pretty much require all JS engines to interpret the seed the same way--which means by mathematical definition, they'd all have to use the same generator--not really an ideal state of affairs.

I would consider at least having the ability to seed a generator, even if the results were  inconsistent between engines, to be a good thing.

On the other hand, it wouldn't be all that difficult to make a shared library that uses the GNU standard library's random method and uses C-linkage, that is used by all the engines.

I would consider at least having the ability to seed a generator, even if the results were  inconsistent between engines, to be a good thing.

That could potentially break any program that saves random number seeds to a file for later use, e.g. in game saves, if the underlying JS engine ever changes.  In fact, Sphere is a perfect example of where that would be a problem.  Sphere 1.x, TurboSphere, Sphere-sfml, they all use different engines.  Best to leave this to external libraries, I think.