W dniu poniedziałek, 9 października 2017 14:25:28 UTC+2 użytkownik Maciej Sobczak
napisał:
> > W artykule jest napisane:
> [...]
>
> Nadal mamy deterministyczne strategie. Zwłaszcza ta z tworzeniem wielu kopii i
udawaniem, że jesteśmy w jednej z nich. Strategia ze zgadywaniem nie opisuje, na czym
ma zgadywanie polegać. Na domniemanym współczesnym komputerze to zgadywanie będzie
deterministyczne. Czyli wracamy do początku - a wynika to z tego, że kredą na tablicy
można sobie różne rzeczy napisać, ale krzem nie wszystko przyjmie tak samo łatwo.

Tak. Przy czym nie ma wymagania, żeby dyskutować tylko o rzeczach,
które można implementować na "domniemanym współczesnym komputerze"

> > No nie. Podałem przykład programu, który w istotny
> > sposób bazuje na losowości -- i jego działanie jako
> > takie nie jest w istocie deterministyczne
>
> Bo sobie włączyłeś tą losowość w ramy działania programu. Dla mnie to jest
zewnętrzne I/O.

Zewnętrzne I/O to jest coś zasadniczo innego od losowości.

> > Czyli Twoja argumentacja NIE ODNOSIŁA się do istoty
> > pojęcia,
>
> Co to jest "istota pojęcia"? Czy "istota programu" już nie wystarcza?

Możesz sobie poczytać np. tutaj
http://ebuw.uw.edu.pl/dlibra/docmetadata?id=122191

> > tylko do (chyba niezbyt dobrze zdefiniowanej?)
> > koncepcji "implementowalności pojęcia"
>
> Domniemując implementowalność na współczesnym komputerze, tak, pewne pojęcia mogą
mieć lub nie mieć sensu.

To, czy pojęcie ma sens, jest zagadnieniem różnym od tego,
czy da się je zaimplementować na współczesnym komputerze.

> > My, jako ludzie, chcemy, żeby kompilacja była deterministyczna,
> > bo chcemy wiedzieć, czego możemy się spodziewać po kompilatorach.
>
> Chcemy, żeby efekty uboczne były takie, jak mówi definicja języka. Reszta nas
zwykle nie interesuje i często nawet celowo jej nie dookreślamy. Np. mało kogo
interesuje stan swapa na dysku po wykonaniu programu - ta niedookreśloność pozwala
kompilatorom (czy ogólniej: systemowi uruchomieniowemu) na własną rękę podejmować
różne decyzje.

Tak. Bo stan swapa na dysku przed wykonaniem programu nie należy
w żadnej mierze do istoty kompilacji.

> > Wydaje mi się, że jednak poprawność kompilatora jest dość dobrze
> > określona.
>
> Zwykle jest celowo niedookreślona.

Poprawność kompilatora jest zazwyczaj określona przez semantykę języka
programowania (najczęściej semantykę operacyjną). Można oczywiście
stosować różne kryteria, np. obserwowalną równoważność zachowania
programu wyprodukowanego przez kompilator z tym samym programem
wykonanym przez interpreter języka. Kwestia dowodzenia poprawności
kompilatora jest interesująca i rozległa, ale samo pojęcie poprawności
kompilatora jest zupełnie jasne. Jasne jest np., że jeżeli rozważymy
wcześniej przytaczany przeze mnie program do wypisywania kwadratów liczb,
a ten program będzie po skompilowaniu wypisywał obraźliwe komunikaty
i podnosił liczby do sześcianu, to kompilator skompilował go niepoprawnie
(w świetle specyfikacji języka C).

> > to z perspektywy osób, które tworzą kompilatory, takie wymaganie
> > jest jak najbardziej na miejscu.
>
> Właśnie dla tych osób jest ważne, żeby użytkownicy pozostawili im swobodę w różnych
obszarach. Dzięki temu te osoby mogą między sobą konkurować.

Tzn. mówisz o tym, że dany fragment programu źródłowego można przekształcić
do różnych, ale równoważnych sobie (w sensie zachowania) programów. Owszem,
to jest prawda. Ale każdy kompilator jest deterministyczny (w takim sensie,
że jak kilka razy skompilujesz ten sam program źródłowy, to dostaniesz
ten sam program wynikowy)

> > Ja ze swojej strony w ogóle nie wypowiadałem się o komputerach,
> > tylko o programach.
>
> Interesujące. Ale po co takiemu bezkomputerowemu programowi kompilator? Czy
rozważania o deterministycznych kompilatorach dla programów bez komputerów nie są
trochę... przeteoretyzowaniem problemu?

Jak wspominałem, w swojej pracy proponuję model maszyny wirtualnej, który
co prawda jest działającym programem w języku Scheme, ale który można studiować
bez uruchamiania komputera -- tak naprawdę, jego wykonywalność
i implementowalność służą przede wszystkim temu, żeby zapewnić, że
w pracy nie ma błędów, i że używane w niej pojęcia są sensowne. Podobnie
kompilator nie ma znamion praktycznych, tylko ma wyjaśniać pewne ogólne
zasady, w oparciu o które funkcjonują kompilatory. Innymi słowy,
programy, które napisałem w swojej pracy, mają raczej charakter poznawczo
-dydaktyczny, niż praktyczny.