I was adding __all__ to the random module and I noticed this very unpythonic example in the module docstring: >>> g = Random(42) # arbitrary >>> g.random() 0.25420336316883324 >>> g.jumpahead(6953607871644L - 1) # move *back* one >>> g.random() 0.25420336316883324 Presuming backing up the seed is a reasonable thing to do (I haven't got much experience with random numbers), why doesn't the Random class have a jumpback method instead of forcing the user to know the magic number to use with jumpahead? def jumpback(self, n): return self.jumpahead(6953607871644L - n) Skip
[Skip Montanaro]
I was adding __all__ to the random module and I noticed this very unpythonic example in the module docstring:
>>> g = Random(42) # arbitrary >>> g.random() 0.25420336316883324 >>> g.jumpahead(6953607871644L - 1) # move *back* one >>> g.random() 0.25420336316883324
Did you miss the sentence preceding the example, starting "Just for fun"?
Presuming backing up the seed is a reasonable thing to do ...
It isn't -- it's just for fun.
(I haven't got much experience with random numbers),
If you did, you would have been howling with joy at how much fun you were having <wink>.
[Skip Montanaro]
I was adding __all__ to the random module and I noticed this very unpythonic example in the module docstring:
>>> g = Random(42) # arbitrary >>> g.random() 0.25420336316883324 >>> g.jumpahead(6953607871644L - 1) # move *back* one >>> g.random() 0.25420336316883324
[Tim]
Did you miss the sentence preceding the example, starting "Just for fun"?
In that vein, the example isn't compatible with doctest, is it? --Guido van Rossum (home page: http://www.python.org/~guido/)
[Skip Montanaro]
I was adding __all__ to the random module and I noticed this very unpythonic example in the module docstring:
>>> g = Random(42) # arbitrary >>> g.random() 0.25420336316883324 >>> g.jumpahead(6953607871644L - 1) # move *back* one >>> g.random() 0.25420336316883324
[Tim]
Did you miss the sentence preceding the example, starting "Just for fun"?
[Guido]
In that vein, the example isn't compatible with doctest, is it?
I'm not sure what you're asking. The example *works* under doctest, although random.py is not a doctest'ed module (it has an "eyeball test" at the end, and you have to be an expert to guess whether or not "it worked" from staring at the output -- not my doing, and way non-trivial to automate). So it's compatible in the "it works" sense, although it's vulnerable to x-platform fp output vagaries in the last few bits. If random.py ever gets doctest'ed, I'll fix that. Or maybe you're saying that a "just for fun" example doesn't need to be accurate? I'd disagree with that, but am not sure that's what you're saying, so won't disagree just yet <wink>.
[Skip] I was adding __all__ to the random module and I noticed this very unpythonic example in the module docstring: [Tim] Did you miss the sentence preceding the example, starting "Just for fun"? I did, yes. [Guido] In that vein, the example isn't compatible with doctest, is it? [Tim] I'm not sure what you're asking. I interpreted Guido's comment to mean, "why include a useless example in documentation?" I guess that was my implicit assumption as well (again, ignoring the missed "just for fun" quote). Either it's a useful example embedded in the documentation or it's a test case that is perhaps not likely to be useful to an end user in which case it should be accessed via the module's __test__ dictionary. guido-did-i-channel-you-properly-ly? yr's, Skip
I thought it was an excellent example for exactly the reasons Tim mentioned. I didn't try it, but I did wonder how long it would take :-). Jeremy
[Skip]
I interpreted Guido's comment to mean, "why include a useless example in documentation?" I guess that was my implicit assumption as well (again, ignoring the missed "just for fun" quote). Either it's a useful example embedded in the documentation or it's a test case that is perhaps not likely to be useful to an end user in which case it should be accessed via the module's __test__ dictionary.
The example is not useful in practice, but is useful pedagogically, for someone who reads the example *in context*: + It makes concrete that .jumpahead() is fast for even monstrously large arguments (try it! it didn't even make you curious?). + It makes concrete that the period of the RNG definitely can be exhausted (something which earlier docstring text warned about in the context of threads, but abstractly). + It concretely demonstrates that the true period is at worst a factor of the documented period, something paranoid users want assurance about because they know from bitter experience that documented periods are often wrong (indeed, Wichmann and Hill made a bogus claim about the period of *this* generator when they first introduced it). A knowledgable user can build on that example to prove to themself quickly that the period is exactly as documented. + If anyone is under the illusion (and many are) that this kind of RNG is good for crypto work, the demonstrated trivial ease with which .jumpahead can move to any point in the sequence-- even trillions of elements ahead --should give them strong cause for healthy doubt. Cranking out cookies is useful, but teaching the interested reader something about the nature of the cookie machine is also useful, albeit in a different sense. unrepentantly y'rs - tim
participants (4)
-
Guido van Rossum -
Jeremy Hylton -
Skip Montanaro -
Tim Peters