W dniu poniedziałek, 8 stycznia 2018 14:21:00 UTC+1 użytkownik Maciej Sobczak
napisał:
> > Mylisz się.
> > Pewne strategie implementacji rekurencji działają wolniej
> > (i zużywają więcej zasobów) od typowych strategii implementacji
> > iteracji, i tyle.
> > Istnieją strategie, pozwalające implementować rekurencję
> > ogonową (czyli taką, która realizuje iterację) bez narzutu.
>
> Tak, jak kompilator zamieni rekurencję na iterację, to działa tak szybko, jak
iteracja. Nie jest jednak prawdą, że bez narzutu, bo tym narzutem może być też
większy koszt kompilacji i optymalizacji kodu. Bo co przepłacać?

Jest dokładnie odwrotnie.
Jeżeli przyjmiesz strategię kompilacji polegającą na tym,
że adres powrotu przekazujesz przez rejestr, a nie przez stos
(i to kompilowana funkcja ma wiedzieć, czy wartość rejestru
ma być odłożona na stosie), to nie dość, że masz mniej odwołań
do pamięci i koszt wywołania funkcji Ci maleje, to optymalizację
rekurencji ogonowej masz w zasadzie za darmo.
Mówienie w tym kontekście o "wyższym koszcie kompilacji i optymalizacji
kodu" jest pretensjonalne, zważywszy na to, jakich innych optymalizacji
dokonują współczesne kompilatory.

> Natomiast iteracja zawsze działa tak szybko, jak iteracja. I zawsze jest tak tania,
jak iteracja.

Nie ma czegoś takiego, jak "zawsze".
Jeżeli w Pythonie 2.0 iterujesz po range(n), to w skład kosztu
iteracji wchodzi zainicjalizowanie n komórek pamięci na wektor,
sama iteracja plus odśmiecenie tej pamięci.

> > > Moja iteracyjna definicja przodka była prostsza od Twojej rekurencyjnej.
> >
> > W jaki sposób chciałbyś uzasadnić, że była prostsza?
>
> Już pisałem: mniej liter, krótsza gramatycznie, nie odwołuje się do definiowanego
pojęcia.

Ale odwołuje się do frazy "i tak dalej", która - w przeciwieństwie
do rekurencji - nie jest zrozumiała sama przez się.

Tak samo jak x[[1 ;; ;; 10]] nie jest zrozumiałe samo przez się.

> > > Moja iteracyjna metoda wyboru elementów z listy też była prostsza.
> >
> > W jaki sposób chciałbyś uzasadnić, że była prostsza?
>
> Ma mniej liter? Mniej razy się pomylę? Mniej bugów będę tam poprawiał?

Jeżeli elementy są indeksowane od 0, to już się pomyliłeś i będziesz musiał
poprawić buga.

> > > Co musisz zmienić w swoim przykładzie, żeby wybrać z listy co dziesiąty
element?
> >
> > Pewnie musiałbym zmienić więcej.
>
> To zmień i pokaż. Bo szczerze mówiąc nie za bardzo mi się chce szarpać w
nieskończoność o filozofię natury, istoty, prostoty, czy czego tam.
> Na razie niczego użytecznego w tej dyskusji nie ustaliliśmy.

Jeżeli nie będziemy definiować używanych przez siebie pojęć, to
raczej niczego użytecznego nie ustalimy.
Jeżeli pod pojęciem prostoty będziemy rozumieć ilość znaków,
to nagle okaże się, że programy w APLu są najprostsze, albo
że Perl jest zasadniczo jakieś 30% prostszy od Pythona.

> > Co nie oznacza, że Twoje rozwiązanie
> > jest prostsze, tylko to, że Twoje rozwiązanie można łatwiej dostosować
> > do pewnej klasy zmian wymagań (z czym się zasadniczo zgadzam)
>
> To też jest użyteczna miara prostoty. Jeśli coś można łatwiej do czegoś dostosować,
to chyba dobrze, co? Po co przepłacać?

Nikt nie mówi, że to źle. Ale to, że coś łatwo do czegoś dostosować,
niekoniecznie jest miarą prostoty.

Na przykład łatwo dostosować telewizor do tego, żeby wyświetlił
jakiś obraz, niż namalować taki obraz na ścianie. A jednak ściana
jest czymś prostszym, niż telewizor.

> Jeszcze raz, co dziesiąty z szeregu wystąp: x[[1;; ;;10]].
>
> Pokaż wersję rekurencyjną i uzasadnij, że zawsze będzie to rekurencja ogonowa, bo
przecież nie chcemy, żeby tak prosta rzecz działała wolniej, niż potrzeba.

Ja widzę, że zupełnie nie rozumiesz, o co mi chodzi.
Jeżeli nie chcesz nawet spróbować zrozumieć, i będziesz się
w kółko upierał z jakąś niezdefiniowaną naturalnością i prostotą
rozumianą jako ilość znaków, to dalsza dyskusja raczej nie ma sensu.