the latest xkcd on my internet is about a programming language that attempts to eliminate off-by-one errors via "every time an integer is stored or read, its value is adjusted up or down by a random amount between 40 and 50". The title text clarifies that this generates off-by-40-or-50 errors instead.
I'm looking a little into engaging cpython with a goal of implementing something like this. It's maybe not the best choice -- the interpreter is only used for one language, the language has other interpreters written for it, and i haven't yet found a single unified place to engage integer stores and loads -- but it's a language that I've been engaging recently, and recently spammed around engaging the bytecode of, which seems quite rare for me. it's 0613 ET. i'm looking for mentions of 'random' in the cpython source to figure out how to generate a random number :s random.py -> imports _random and from os imports urandom os.py -> imports * from posix or nt depending on platform Modules/_randommodule.c -> contains this line: #include "pycore_pylifecycle.h" // _PyOS_URandomNonblock() Here are some interesting floating point constants: static PyObject * _random_Random_random_impl(RandomObject *self) /*[clinic end generated code: output=117ff99ee53d755c input=26492e52d26e8b7b]*/ { uint32_t a=genrand_uint32(self)>>5, b=genrand_uint32(self)>>6; return PyFloat_FromDouble((a*67108864.0+b)*(1.0/9007199254740992.0)); } how much is one 9.007 quadrillionth? something to do with doubles or floats, 67.1 million, and 27 and 26 bit integers! i guess the 67.1 million would be to generate a higher bit integer, and the 9.007 quadrillion would be to scale it within 0 and 1. funny at first to see large integer constants in a floating point division context but makes sense. blurp arright ummm genrand_uint32 is a manual inline implementation and operates on a RandomObject :/ comments say that it's MT19937 hiroshima-u.ac.jp . 9.007 quadrillion is pow(2, 53). the python comments say "likely vain hope" regarding performing multiply-by-reciprocal rather than divide. the authors of the comments were maybe unaware that this optimization could double your frame rate in the 80s and 90s, and spreading of newer such optimizations dropped after hardware advanced. 67.1 million is pow(2,26). current options: - initializing and using random state using this compiled mt19937 module - using code from nt or posix module to compute random - including my own random header or such - placing a manual implementation of a generation algorithm i'm visiting Modules/posixmodule.c it's notable that these functions have comments along the lines of "clinic end generated code" ... but i'm guessing it's the signatures that are generated, not the bodies os_urandom_impl in posixmodule.c hands off to _PyOS_URandom it looks like posixmodule.c defines both the "posix" and the "nt" modules conditioned on platform looks like both _PyOS_URandom _PyOS_URandomNonblock are pulled in from pycore_pylifecycle.h the definitions though are in Python/bootstrap_hash.c . it defines a few different random number generators, strange to see this after the inline generator from the japanese university code. usually these two things would be unified together. notably these random number generators i'm not seeing them in the header file yet win32_urandom -> calls BCryptGenRandom, a windows call py_getrandom -> calls getrandom(), a linux kernel syscall py_getentropy -> calls getentropy() dev_urandom -> reads /dev/urandom lcg_urandom -> manual linear congruential generator pyurandom -> hands off to the first 4 above in order if available, does not use lcg_urandom _PyOS_URandom* -> hand off to pyurandom so to generate a number between 40 and 50 i suppose i'd call a _PyOS_URandom function and read 1 byte. i could keep a bit cache if i were fancy, but would likely make more sense to spend time on ensuring integer stores and loads are properly effected.