No episódio de hoje de terror na programação... Na documentação do Python da função `random.seed()`, somos informados de que... "Se a for um int, ele é usado diretamente." [1] Mas se você usar 3 ou -3 como semente, você obtém exatamente o mesmo objeto RNG, produzindo os mesmos fluxos. (Aprendi algo novo hoje). No nanochat, eu estava usando o sinal como uma maneira (que eu achava) inteligente de obter sequências RNG diferentes para as divisões de treino/teste. Daí o bug complicado, porque agora treino = teste. Encontrei o código CPython responsável em cpython/Modules/_randommodule.c [2], onde na linha 321 vemos em um comentário: "Este algoritmo pressupõe que o número não tenha sinal. Portanto: se o argumento for um PyLong, use seu valor absoluto." seguido por n = PyNumber_Absolute(arg); que chama explicitamente a função abs() na sua semente para torná-la positiva, descartando o bit de sinal. Mas esse comentário também está errado/enganoso. Internamente, o Python chama o algoritmo Mersenne Twister MT19937, que, no caso geral, possui 19937 bits (diferentes de zero) de estado. O Python pega seu int (ou outros objetos) e "distribui" essa informação por esses bits. Em princípio, o bit de sinal poderia ter sido usado para aumentar os bits de estado. Não há nada no algoritmo que "depende do número ser sem sinal". Decidiu-se não incorporar o bit de sinal (o que, na minha opinião, foi um erro). Um exemplo trivial seria mapear n -> 2*abs(n) + int(n mesma sequência. Mas não há garantia de que sementes diferentes produzam sequências diferentes. Portanto, em princípio, o Python não garante que, por exemplo, `seed(5)` e `seed(6)` sejam fluxos de números aleatórios diferentes. (Embora isso seja assumido implicitamente em muitas aplicações.) De fato, vemos que `seed(5)` e `seed(-5)` são fluxos idênticos. E você provavelmente não deveria usá-los para separar os comportamentos de treino/teste em aprendizado de máquina. Um dos erros de programação mais divertidos que encontrei recentemente. Nos vemos no próximo episódio. [1] https://t.co/srv1ZBlDsi [2]
Agradeço a ericsilberstein1 no GitHub por ter identificgithub.com/karpathy/nanoc…co/18o1CiivgN (Não é um bug grave e só aparece na avaliação da tarefa sintética SpellingBee, mas mesmo assim).