No episódio de hoje de horror na programação... Nos documentos do Python sobre a função random.seed(), somos informados "Se a é um int, ele é usado diretamente." [1] Mas se você usar 3 ou -3 como semente, na verdade você obtém o mesmo objeto rng, produzindo os mesmos fluxos. (TIL). No nanochat, eu estava usando o sinal como uma (o que eu pensava ser) maneira inteligente de obter diferentes sequências de rng para divisões de treino/teste. Daí um 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 depende do número ser sem sinal. Então: se o argumento é um PyLong, use seu valor absoluto." seguido por n = PyNumber_Absolute(arg); que chama explicitamente abs() na sua semente para torná-la positiva, descartando o bit de sinal. Mas este comentário também está errado/misleading. Nos bastidores, o Python chama o algoritmo Mersenne Twister MT19937, que no caso geral tem 19937 bits de estado (não zero). 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 sobre o algoritmo que "depende do número ser sem sinal". Uma decisão foi tomada para não incorporar o bit de sinal (o que, na minha opinião, foi um erro). Um exemplo trivial poderia ter sido mapear n -> 2*abs(n) + int(n < 0). Finalmente, isso nos leva ao contrato do random do Python, que também não está totalmente descrito nos documentos. O contrato que é mencionado é que: mesma semente => mesma sequência. Mas nenhuma garantia é dada de que sementes diferentes produzem sequências diferentes. Portanto, em princípio, o Python não faz promessas de que, por exemplo, seed(5) e seed(6) são fluxos rng diferentes. (Embora isso seja comumente 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 seus comportamentos de treino/teste em aprendizado de máquina. Um dos mais divertidos erros de programação que encontrei recentemente. Nos vemos no próximo episódio. [1] [2]