Tag: perl

Opublikowane w

Częstość piątku trzynastego.

Czy naprawdę piątek przypada trzynastego dnia miesiąca częściej, niż inne dni tygodnia, jak wynika z tego wpisu? Postanowiłem to sprawdzić, metodą najdoskonalszą, czyli brute force. Co prawda tylko dla lat 1970-2037 czyli w Unix Epoch (pełne lata).

Kod był praktycznie gotowy z czasów obliczeń, czy pracownicy zyskają, czy stracą na wolnym 6. stycznia. Ostatecznie wygląda on tak:

a wynik działania wygląda tak:

DOW - ilosc
1 - 116
2 - 118
3 - 115
4 - 117
5 - 117
6 - 116
7 - 117
Suma: 816

1 - Monday, ... , 7 - Sunday

Piątek oznaczony jest cyfrą 5, jak widać występuje on jako trzynasty dzień miesiąca 117 razy, podobnie jak czwartek i niedziela , więcej w badanym okresie jest wtorków trzynastego (118), a najmniej śród (113).

Pozostaje pytanie, dla jakich dokładnie lat prowadzona była analiza w oryginalnym wpisie. Na oko wygląda na jakieś 335 lat, pytanie które dokładnie. W każdym razie w badanym okresie nic nie wskazuje na większą częstotliwość występowania piątku w trzynasty dzień miesiąca.

Opublikowane w

6 stycznia wolny – zysk czy strata dla pracowników?

Od pierwszego stycznia zmieniają się prawo pracy, a konkretnie zasady udzielania dni wolnych. Do tej pory, jeśli dzień wolny od pracy przypadał w sobotę, to pracownikowi przysługiwał w zamian za niego dzień wolny. Od 1 stycznia 2011 nie ma tego, za to do świąt dołącza 6 stycznia jako Objawienie Pańskie.
Zasadnicze pytanie: czy pracownicy na tym zyskują, czy tracą? Odpowiedź na to pytanie wbrew pozorom nie jest oczywista.
  • 1 stycznia
  • 1 maja
  • 3 maja
  • 15 sierpnia
  • 1 listopada
  • 11 listopada
  • 25 grudnia
  • 26 grudnia

(pomijam 4 święta ruchome, które w Polsce nigdy nie wypadają w sobotę), a do tego dochodzi od tego roku 6 stycznia.

Nie wdając się w matematykę (jakoś nie mam głowy do matematyki kalendarzowej, a nic sensownego mi nie wyszło przez chwilę namysłu), korzystam z metody najdoskonalszej, czyli pełnego przeglądu (AKA brute force) wg algorytmu: jeśli któreś z dotychczasowych świąt wypadnie w sobotę, to pracownicy tracą dzień, jeśli 6 stycznia nie wypadnie w sobotę ani w niedzielę, to pracownicy zyskują dzień.  I sumowanie strat i zysków…

Całość to nieładny bash (funkcja date) napędzana perlem, pisany na szybko.

Wynik? Miłe złego początki – przez najbliższe 10 lat stracimy, jako pracownicy, średnio rocznie 0,1 dnia wolnego, a w pierwszych 3 latach nawet będzie niewielki zysk, ale dla 25 lat – o ile przepisy się nie zmienią – stracimy łącznie 8 dni wolnych, czyli 0,32 dnia wolnego rocznie. Szczerze mówiąc, nie jest tak źle jak myślałem…

Ale zmiana jest ewidentnie niekorzystna dla pracowników. Gdyby miała miejsce w 1990 roku, to do tego roku tracilibyśmy średnio ponad pół dnia wolnego rocznie.

I skrypt do obliczeń:

Opublikowane w

Ile cyfr potrzeba, by numer konta był unikatowy?

Temat (nie)unikatowych numerów kont pojawił się w tej dyskusji nt. tokenów (dead link, domena przejęta), a szerzej opisany jest w tym wpisie, ile cyfr potrzeba, by numer rachunku bankowego był unikatowy. Przyznam, że nie miałem zielonego pojęcia nt. algorytmu weryfikacji numeru IBAN, ale na chłopski rozum kolizje zdarzą się wszędzie. Stwierdziłem, że najlepsza metoda nauki to napisać skrypt do sprawdzania. Oczywiście w Perlu. Przy okazji wyszło mi, że Perl średnio sobie radzi z dużymi liczbami, a Python dobrze, ale dzięki temu znalazłem pięknego gotowca w postaci modułu do sprawdzania poprawności numeru IBAN.

Pierwsze, co rzuca się w oczy, to fakt, że tak naprawdę numer IBAN jest zamieniany na liczbę, a czy jest poprawny określane jest tylko na podstawie jednego testu – jeśli reszta z dzielenia tej dużej cyfry przez 97 wynosi 1, to numer jest poprawny.

Chwila zabawy programem i okazuje się, że dla 3 brakujących cyfr w dowolnym miejscu rachunku można wygenerować ok. 10 kolizji. Pewnie ma to coś wspólnego z faktem, że 97 jest liczbą pierwszą, a samo 97 mieści się w każdym tysiącu właśnie 10-11 razy, ale tutaj już by się matematyk przydał i zasady podzielności przez 97 (hasło do Google cechy podzielności przez 97 nic sensownego nie znalazło niestety).

Inna szansa, że nasze PL na początku numeru (które wraz z następującymi po nim dwiema cyframi jest przesuwane na koniec i zamieniane na liczby patrz algorytm weryfikacji numeru IBAN) jest na tyle pechowe, że powoduje taką przykrą przypadłość. Ale to łatwo sprawdzić – dzięki użyciu ogólnej biblioteki skrypcik do bruteforce’owania numerów IBAN powinien działać dla wszystkich krajów.

Póki co konkluzja jest taka, że aby numer był unikatowy, to trzeba podać wszystkie cyfry. Przy dobrym wietrze może się zdarzyć, że 1 można opuścić.

PS. Nie cierpię słowa unikalny. Dla mnie oznacza ono możliwy do uniknięcia. Zamiast niego możnaby używać słowa unikatowy. Niestety SJP traktuje je jako synonimy.