Skip to main content ↑ ↓
Topic: Mathematical Randomness (Read 150170 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Mathematical Randomness

Reply #15 –
Or just use my drop-in replacement for random number generation in Sphere:
http://forums.spheredev.org/index.php/topic,76.msg963.html#msg963
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Mathematical Randomness

Reply #16 –
Quote from: Flying Jester – on

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

Re: Mathematical Randomness

Reply #17 –
You know what would be even better? If you could manually seed Math.random() to begin with. :P

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

Re: Mathematical Randomness

Reply #18 –
Quote from: DaVince – on

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

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!
 

Re: Mathematical Randomness

Reply #20 –
Quote from: Flying Jester – on

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.

Re: Mathematical Randomness

Reply #21 –
There is very little stopping a standard from providing a builtin random number generator that can accept an arbitrary seed.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Mathematical Randomness

Reply #22 –
@Radnen: Go tell that to ECMA. ;-)

Re: Mathematical Randomness

Reply #23 –
Alright, seeing how long it's taking to get 'const' by, I think a standard would take time there. :P
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Mathematical Randomness

Reply #24 –
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.

Re: Mathematical Randomness

Reply #25 –
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.

Re: Mathematical Randomness

Reply #26 –
Quote from: Flying Jester – on

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.