W dniu wtorek, 3 października 2017 18:56:43 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Nie, nie jest. I w ogóle co to miałoby znaczyć - "czysto funkcyjnym"?
> >
> > Miałoby znaczyć tyle, że dla danego wejścia daje zawsze to samo wyjście.
>
> Biorąc pod uwagę deterministyczny sposób działania układów cyfrowych, każdy program
wykonany na takich układach tak działa. W każdym języku.
> Ale to oznacza też, że określenie "czysto funkcyjny" jest niepraktyczne, bo niczego
nie rozstrzyga - bo skoro każdy program jest "czysto funkcyjny", to szkoda literek na
określanie wszystkiego w ten sposób.

Nie. Na przykład unixowe polecenia takie jak mkdir czy rm nie są czysto
funkcyjne, bo ich istotą jest wykonanie pewnego skutku ubocznego -- zmiana
pewnego stanu.

Podobnie wspomniany przeze mnie system do algorytmów genetycznych
(można sobie o nim poczytać w rozdziale drugim książki
https://github.com/panicz/pamphlet/) -- bazuje na operacji niedeterministycznej,
ponieważ losuje pewien obiekt. Zatem nie jest ze swojej istoty czysto
funkcyjny.

Określenie "czysto funkcyjny" jest bardzo praktyczne, ponieważ
wyznacza środki analizy potrzebne do tego, żeby analizować dany
system. Systemy czysto funkcyjne można analizować w terminach
podstawień wartości wyrażeń za wyrażenia.

> > Nie każdy program tak robi. Na przykład system czasu rzeczywistego
> > ma się odpowiednio zachować w określonych okolicznościach.
>
> Te okoliczności to też wejście (bo niby skąd program ma wiedzieć o tych
okolicznościach? informacja o otoczeniu musi jakoś wpłynąć do programu a to jest
właśnie wejście). Podobnie jak interwały upływającego czasu - to też jest wejście.
>
> > > Nie jest w taki sposób implementowany, bo w istocie rzeczy nie jest czysto
funkcyjny (cokolwiek to znaczy).
> >
> > Jeżeli nie wiesz co to znaczy, to skąd wiesz, że w istocie
> > rzeczy nie jest czysto funkcyjny?
>
> Bo określenie "czysto coś" ma zawsze wadę bycia niedookreślonym. I zwykle tak czy
siak nie jest prawdą.

Jest całkowicie dookreślone. W jakimś sensie, w każdym razie.
Bo rzeczywiście, wiele kompilatorów działa tak, że wykonuje pewien
efekt uboczny, np. sprawia, że na dysku pojawiają się jakieś pliki
(i czasem też znikają). Ale to nie należy do jego istoty, tylko
jest szczegółem implementacyjnym (w mojej pracy kompilatory nie robią
takich obrzydliwych rzeczy).

> Poza tym, obowiązuje zasada "nie wiem o co chodzi, ale chętnie się wypowiem".

A, to przepraszam :)

do góry

> Nie. Na przykład unixowe polecenia takie jak mkdir czy rm nie są czysto
> funkcyjne, bo ich istotą jest wykonanie pewnego skutku ubocznego -- zmiana
> pewnego stanu.

Dokładnie to samo można powiedzieć o każdym programie, który cokolwiek produkuje na
swoim wyjściu - bo operacje I/O (czyli również pisanie na stdout) to skutki uboczne.
Nawet dokładnie tak się to nazywa w standardzie np. języka C.

Czyli przeginając argument w drugą stronę, można powiedzieć, że wszystkie
interesujące programy produkują jakieś skutki uboczne (w przeciwnym razie nie ma po
co ich uruchamiać), więc zgodnie z Twoją definicją nie są "czysto funkcyjne". Czy
znowu to pojęcie nie jest użyteczne.

> bazuje na operacji niedeterministycznej,
> ponieważ losuje pewien obiekt.

"Losowanie" generatorem liczb pseudolosowych jest deterministyczne, tak jak każda
inna sekwencja operacji arytmetycznych. A odwoływanie się do zewnętrznych źródeł
szumu jest operacją wejścia, czyli znowu mówimy o deterministycznym programie, który
przetwarza wejście na wyjście - i który dla takiego samego szumu da zawsze te same
wyniki. Czyli który dla takiego samego wejścia da takie same wyjście. Sorry.

> Zatem nie jest ze swojej istoty czysto
> funkcyjny.

I dalej nie wiemy, co to niby miałoby oznaczać.
Podsumujmy co wiemy do tej pory:
- wszystkie programy deterministycznie przetwarzają wejście na wyjście i produkują
przy tej okazji skutki uboczne.

> Określenie "czysto funkcyjny" jest bardzo praktyczne, ponieważ
> wyznacza środki analizy potrzebne do tego, żeby analizować dany
> system.

Łomatko.

> Systemy czysto funkcyjne można analizować w terminach
> podstawień wartości wyrażeń za wyrażenia.

Czyli wszystkie programy można tak analizować. Każdy program jest deterministyczną
funkcją Input -> Output.
Dlatego to pojęcie nie jest użyteczne.

> Bo rzeczywiście, wiele kompilatorów działa tak, że wykonuje pewien
> efekt uboczny, np. sprawia, że na dysku pojawiają się jakieś pliki
> (i czasem też znikają). Ale to nie należy do jego istoty, tylko
> jest szczegółem implementacyjnym

W ten sposób można opisać każdy program - tzn. że owszem, robi efekty uboczne przy
okazji operacji I/O (które są potrzebne, że przeczytać wejście i wyprodukować coś na
wyjściu), ale one nie należą do jego istoty, tylko są szczegółem implementacyjnym,
więc...

Więc znowu albo każdy program jest "czysto cośtam", albo każdy nie jest.

> > Poza tym, obowiązuje zasada "nie wiem o co chodzi, ale chętnie się wypowiem".
>
> A, to przepraszam :)

Proszę. :-)

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu środa, 4 października 2017 00:21:38 UTC+2 użytkownik Maciej Sobczak napisał:
> > Nie. Na przykład unixowe polecenia takie jak mkdir czy rm nie są czysto
> > funkcyjne, bo ich istotą jest wykonanie pewnego skutku ubocznego -- zmiana
> > pewnego stanu.
>
> Dokładnie to samo można powiedzieć o każdym programie, który cokolwiek produkuje na
swoim wyjściu - bo operacje I/O (czyli również pisanie na stdout) to skutki uboczne.
Nawet dokładnie tak się to nazywa w standardzie np. języka C.
>
> Czyli przeginając argument w drugą stronę, można powiedzieć, że wszystkie
interesujące programy produkują jakieś skutki uboczne (w przeciwnym razie nie ma po
co ich uruchamiać), więc zgodnie z Twoją definicją nie są "czysto funkcyjne". Czy
znowu to pojęcie nie jest użyteczne.

Otóż nie. Ale widzę, że po raz kolejny zamiast spróbować zrozumieć
pojęcie, starasz się je strolować i wmówić, że nie jest użyteczne.

Można sobie pomyśleć program, który oblicza wartość jakiegoś programu
czysto funkcyjnego i wyświetla ją na ekran. (Na przykład takie coś
robi interpreter). Interpreter nie jest czysto funkcyjny, a obliczany
przez niego program jest.

> > bazuje na operacji niedeterministycznej,
> > ponieważ losuje pewien obiekt.
>
> "Losowanie" generatorem liczb pseudolosowych jest deterministyczne, tak jak każda
inna sekwencja operacji arytmetycznych. A odwoływanie się do zewnętrznych źródeł
szumu jest operacją wejścia, czyli znowu mówimy o deterministycznym programie, który
przetwarza wejście na wyjście - i który dla takiego samego szumu da zawsze te same
wyniki. Czyli który dla takiego samego wejścia da takie same wyjście. Sorry.

Widzę, że nie rozumiesz.
To, czy liczba jest pseudolosowa, czy nie jest, czy pochodzi z wejścia,
czy z kosmosu, nie ma znaczenia dla *ISTOTY* danego programu. Na tym
właśnie polega abstrakcja niedeterminizmu.

> > Zatem nie jest ze swojej istoty czysto
> > funkcyjny.
>
> I dalej nie wiemy, co to niby miałoby oznaczać.

No, jeżeli usilnie staramy się nie zrozumieć, co to oznacza,
to nie wiemy.

> > Określenie "czysto funkcyjny" jest bardzo praktyczne, ponieważ
> > wyznacza środki analizy potrzebne do tego, żeby analizować dany
> > system.
>
> Łomatko.

Może sobie poczytaj https://mitpress.mit.edu/sicp/full-text/sicp/book/no
de10.html

> > Systemy czysto funkcyjne można analizować w terminach
> > podstawień wartości wyrażeń za wyrażenia.
>
> Czyli wszystkie programy można tak analizować. Każdy program jest deterministyczną
funkcją Input -> Output.
> Dlatego to pojęcie nie jest użyteczne.

Dałem kilka kontrprzykładów. Systemy kolejkowe czasu rzeczywistego
nie są deterministyczną funkcją input->output. Być może mają komponenty,
które można w taki sposób analizować, ale ich istotą jest działanie
w czasie rzeczywistym, i reagowanie na zdarzenia w zależności od
jakiegoś ich wewnętrznego stanu.

Natomiast programy w rodzaju kompilatorów, konwerterów LaTeXa,
sedów, są w istocie czysto funkcyjne w takim sensie, że dla określonego
wejścia dają określone wyjście i kropka. Pojęcie "wewnętrznego
stanu" nie należy do ich opisu.

> > Bo rzeczywiście, wiele kompilatorów działa tak, że wykonuje pewien
> > efekt uboczny, np. sprawia, że na dysku pojawiają się jakieś pliki
> > (i czasem też znikają). Ale to nie należy do jego istoty, tylko
> > jest szczegółem implementacyjnym
>
> W ten sposób można opisać każdy program - tzn. że owszem, robi efekty uboczne przy
okazji operacji I/O (które są potrzebne, że przeczytać wejście i wyprodukować coś na
wyjściu), ale one nie należą do jego istoty, tylko są szczegółem implementacyjnym,
więc...

Nie, nie można.
Podałem podczas tej rozmowy kilka przykładów.
Istnieją programy, których istotą jest interakcja (np. gry komputerowe,
przeglądarki internetowe), takie, których istotą jest wykonanie
skutku ubocznego (np. mkdir albo rm), takie, które są w istocie
niedeterministyczne (jak wspomniany framework do algorytmów genetycznych).
A oprócz nich są programy czysto funkcyjne, które po prostu wyznaczają
przekształcenia jakichs wejść w jakieś wyjścia.
Dla mnie taki podział jest użyteczny. Jeżeli dla Ciebie nie jest,
to Twoja sprawa.

do góry

On Wednesday, October 4, 2017 at 8:15:08 AM UTC+2, g...@g...com wrote:
> W dniu środa, 4 października 2017 00:21:38 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Nie. Na przykład unixowe polecenia takie jak mkdir czy rm nie są czysto
> > > funkcyjne, bo ich istotą jest wykonanie pewnego skutku ubocznego -- zmiana
> > > pewnego stanu.
> >
> > Dokładnie to samo można powiedzieć o każdym programie, który cokolwiek produkuje
na swoim wyjściu - bo operacje I/O (czyli również pisanie na stdout) to skutki
uboczne. Nawet dokładnie tak się to nazywa w standardzie np. języka C.
> >
> > Czyli przeginając argument w drugą stronę, można powiedzieć, że wszystkie
interesujące programy produkują jakieś skutki uboczne (w przeciwnym razie nie ma po
co ich uruchamiać), więc zgodnie z Twoją definicją nie są "czysto funkcyjne". Czy
znowu to pojęcie nie jest użyteczne.
>
> Otóż nie. Ale widzę, że po raz kolejny zamiast spróbować zrozumieć
> pojęcie, starasz się je strolować i wmówić, że nie jest użyteczne.
>
> Można sobie pomyśleć program, który oblicza wartość jakiegoś programu
> czysto funkcyjnego i wyświetla ją na ekran. (Na przykład takie coś
> robi interpreter). Interpreter nie jest czysto funkcyjny, a obliczany
> przez niego program jest.
>
> > > bazuje na operacji niedeterministycznej,
> > > ponieważ losuje pewien obiekt.
> >
> > "Losowanie" generatorem liczb pseudolosowych jest deterministyczne, tak jak każda
inna sekwencja operacji arytmetycznych. A odwoływanie się do zewnętrznych źródeł
szumu jest operacją wejścia, czyli znowu mówimy o deterministycznym programie, który
przetwarza wejście na wyjście - i który dla takiego samego szumu da zawsze te same
wyniki. Czyli który dla takiego samego wejścia da takie same wyjście. Sorry.
>
> Widzę, że nie rozumiesz.
> To, czy liczba jest pseudolosowa, czy nie jest, czy pochodzi z wejścia,
> czy z kosmosu, nie ma znaczenia dla *ISTOTY* danego programu. Na tym
> właśnie polega abstrakcja niedeterminizmu.
>
> > > Zatem nie jest ze swojej istoty czysto
> > > funkcyjny.
> >
> > I dalej nie wiemy, co to niby miałoby oznaczać.
>
> No, jeżeli usilnie staramy się nie zrozumieć, co to oznacza,
> to nie wiemy.
>
> > > Określenie "czysto funkcyjny" jest bardzo praktyczne, ponieważ
> > > wyznacza środki analizy potrzebne do tego, żeby analizować dany
> > > system.
> >
> > Łomatko.
>
> Może sobie poczytaj https://mitpress.mit.edu/sicp/full-text/sicp/book/no
de10.html
>
> > > Systemy czysto funkcyjne można analizować w terminach
> > > podstawień wartości wyrażeń za wyrażenia.
> >
> > Czyli wszystkie programy można tak analizować. Każdy program jest
deterministyczną funkcją Input -> Output.
> > Dlatego to pojęcie nie jest użyteczne.
>
> Dałem kilka kontrprzykładów. Systemy kolejkowe czasu rzeczywistego
> nie są deterministyczną funkcją input->output. Być może mają komponenty,
> które można w taki sposób analizować, ale ich istotą jest działanie
> w czasie rzeczywistym, i reagowanie na zdarzenia w zależności od
> jakiegoś ich wewnętrznego stanu.
>
> Natomiast programy w rodzaju kompilatorów, konwerterów LaTeXa,
> sedów, są w istocie czysto funkcyjne w takim sensie, że dla określonego
> wejścia dają określone wyjście i kropka. Pojęcie "wewnętrznego
> stanu" nie należy do ich opisu.
>
> > > Bo rzeczywiście, wiele kompilatorów działa tak, że wykonuje pewien
> > > efekt uboczny, np. sprawia, że na dysku pojawiają się jakieś pliki
> > > (i czasem też znikają). Ale to nie należy do jego istoty, tylko
> > > jest szczegółem implementacyjnym
> >
> > W ten sposób można opisać każdy program - tzn. że owszem, robi efekty uboczne
przy okazji operacji I/O (które są potrzebne, że przeczytać wejście i wyprodukować
coś na wyjściu), ale one nie należą do jego istoty, tylko są szczegółem
implementacyjnym, więc...
>
> Nie, nie można.
> Podałem podczas tej rozmowy kilka przykładów.
> Istnieją programy, których istotą jest interakcja (np. gry komputerowe,
> przeglądarki internetowe), takie, których istotą jest wykonanie
> skutku ubocznego (np. mkdir albo rm), takie, które są w istocie
> niedeterministyczne (jak wspomniany framework do algorytmów genetycznych).
> A oprócz nich są programy czysto funkcyjne, które po prostu wyznaczają
> przekształcenia jakichs wejść w jakieś wyjścia.
> Dla mnie taki podział jest użyteczny. Jeżeli dla Ciebie nie jest,
> to Twoja sprawa.

Pytanie, czy dla ogółu jest użyteczny? Póki co, ja to nawet nie widzę
wyraźnej granicy podziałów ani korzyści z dzielenia - ale to pewnie
coś ze mną nie tak.

Pozdrawiam

do góry

On Wed, 4 Oct 2017 09:36:14 -0700 (PDT), M.M. wrote:

> On Wednesday, October 4, 2017 at 8:15:08 AM UTC+2, g...@g...com wrote:
>> W dniu środa, 4 października 2017 00:21:38 UTC+2 użytkownik Maciej Sobczak
napisał:
>>> > Nie. Na przykład unixowe polecenia takie jak mkdir czy rm nie są czysto
>>> > funkcyjne, bo ich istotą jest wykonanie pewnego skutku ubocznego -- zmiana
>>> > pewnego stanu.
>>>
>>> Dokładnie to samo można powiedzieć o każdym programie, który cokolwiek produkuje
na swoim wyjściu - bo operacje I/O (czyli również pisanie na stdout) to skutki
uboczne. Nawet dokładnie tak się to nazywa w standardzie np. języka C.
>>>
>>> Czyli przeginając argument w drugą stronę, można powiedzieć, że wszystkie
interesujące programy produkują jakieś skutki uboczne (w przeciwnym razie nie ma po
co ich uruchamiać), więc zgodnie z Twoją definicją nie są "czysto funkcyjne". Czy
znowu to pojęcie nie jest użyteczne.
>>
>> Otóż nie. Ale widzę, że po raz kolejny zamiast spróbować zrozumieć
>> pojęcie, starasz się je strolować i wmówić, że nie jest użyteczne.
>>
>> Można sobie pomyśleć program, który oblicza wartość jakiegoś programu
>> czysto funkcyjnego i wyświetla ją na ekran. (Na przykład takie coś
>> robi interpreter). Interpreter nie jest czysto funkcyjny, a obliczany
>> przez niego program jest.
>>
>>> > bazuje na operacji niedeterministycznej,
>>> > ponieważ losuje pewien obiekt.
>>>
>>> "Losowanie" generatorem liczb pseudolosowych jest deterministyczne, tak jak każda
inna sekwencja operacji arytmetycznych. A odwoływanie się do zewnętrznych źródeł
szumu jest operacją wejścia, czyli znowu mówimy o deterministycznym programie, który
przetwarza wejście na wyjście - i który dla takiego samego szumu da zawsze te same
wyniki. Czyli który dla takiego samego wejścia da takie same wyjście. Sorry.
>>
>> Widzę, że nie rozumiesz.
>> To, czy liczba jest pseudolosowa, czy nie jest, czy pochodzi z wejścia,
>> czy z kosmosu, nie ma znaczenia dla *ISTOTY* danego programu. Na tym
>> właśnie polega abstrakcja niedeterminizmu.
>>
>>> > Zatem nie jest ze swojej istoty czysto
>>> > funkcyjny.
>>>
>>> I dalej nie wiemy, co to niby miałoby oznaczać.
>>
>> No, jeżeli usilnie staramy się nie zrozumieć, co to oznacza,
>> to nie wiemy.
>>
>>> > Określenie "czysto funkcyjny" jest bardzo praktyczne, ponieważ
>>> > wyznacza środki analizy potrzebne do tego, żeby analizować dany
>>> > system.
>>>
>>> Łomatko.
>>
>> Może sobie poczytaj https://mitpress.mit.edu/sicp/full-text/sicp/book/no
de10.html
>>
>>> > Systemy czysto funkcyjne można analizować w terminach
>>> > podstawień wartości wyrażeń za wyrażenia.
>>>
>>> Czyli wszystkie programy można tak analizować. Każdy program jest
deterministyczną funkcją Input -> Output.
>>> Dlatego to pojęcie nie jest użyteczne.
>>
>> Dałem kilka kontrprzykładów. Systemy kolejkowe czasu rzeczywistego
>> nie są deterministyczną funkcją input->output. Być może mają komponenty,
>> które można w taki sposób analizować, ale ich istotą jest działanie
>> w czasie rzeczywistym, i reagowanie na zdarzenia w zależności od
>> jakiegoś ich wewnętrznego stanu.
>>
>> Natomiast programy w rodzaju kompilatorów, konwerterów LaTeXa,
>> sedów, są w istocie czysto funkcyjne w takim sensie, że dla określonego
>> wejścia dają określone wyjście i kropka. Pojęcie "wewnętrznego
>> stanu" nie należy do ich opisu.
>>
>>> > Bo rzeczywiście, wiele kompilatorów działa tak, że wykonuje pewien
>>> > efekt uboczny, np. sprawia, że na dysku pojawiają się jakieś pliki
>>> > (i czasem też znikają). Ale to nie należy do jego istoty, tylko
>>> > jest szczegółem implementacyjnym
>>>
>>> W ten sposób można opisać każdy program - tzn. że owszem, robi efekty uboczne
przy okazji operacji I/O (które są potrzebne, że przeczytać wejście i wyprodukować
coś na wyjściu), ale one nie należą do jego istoty, tylko są szczegółem
implementacyjnym, więc...
>>
>> Nie, nie można.
>> Podałem podczas tej rozmowy kilka przykładów.
>> Istnieją programy, których istotą jest interakcja (np. gry komputerowe,
>> przeglądarki internetowe), takie, których istotą jest wykonanie
>> skutku ubocznego (np. mkdir albo rm), takie, które są w istocie
>> niedeterministyczne (jak wspomniany framework do algorytmów genetycznych).
>> A oprócz nich są programy czysto funkcyjne, które po prostu wyznaczają
>> przekształcenia jakichs wejść w jakieś wyjścia.
>> Dla mnie taki podział jest użyteczny. Jeżeli dla Ciebie nie jest,
>> to Twoja sprawa.
>
> Pytanie, czy dla ogółu jest użyteczny? Póki co, ja to nawet nie widzę
> wyraźnej granicy podziałów ani korzyści z dzielenia - ale to pewnie
> coś ze mną nie tak.

Z tego co zrozumiałem to taki program wykonuje sekwencyjnie* rozkazy wg
zadanego schematu/algorytmu, jedzie od A do Z i się kończy.

Tylko z tego nic nie wynika poza samym tym faktem. Ale może taki podział ma
gdzieś zastosowanie praktyczne.

*sekwencyjnie w sensie kolejnych kroków, które oczywiście może rozdzielać
na np. wątki


--
pozdrawiam
Roman Tyczka

do góry

W dniu środa, 4 października 2017 20:02:27 UTC+2 użytkownik Roman Tyczka napisał:

> > Pytanie, czy dla ogółu jest użyteczny? Póki co, ja to nawet nie widzę
> > wyraźnej granicy podziałów ani korzyści z dzielenia - ale to pewnie
> > coś ze mną nie tak.
>
> Z tego co zrozumiałem to taki program wykonuje sekwencyjnie* rozkazy wg
> zadanego schematu/algorytmu, jedzie od A do Z i się kończy.

Nie. Tutaj w ogóle nie chodzi o sekwencyjność ani o algorytmy.
Chodzi o funkcję w rozumieniu matematycznym, czyli o skojarzenie
wartości z argumentami. Te wartości można obliczyć na różne sposoby
-- w szczególności, wcześniej wyliczone wartości można sobie
cache'ować, żeby nie musieć ich wyliczać ponownie. Oczywiście takie
cache'owanie nie zawsze ma sens -- zwłaszcza w sytuacji, gdy dziedzina
funkcji jest bardzo duża.

> Tylko z tego nic nie wynika poza samym tym faktem. Ale może taki podział ma
> gdzieś zastosowanie praktyczne.

Dla mnie ten podział ma sens ze względu na klasy optymalizacji
oraz różnorakość sposobów interpretacji, jakie można stosować
do wykonywania programów.

do góry

> Można sobie pomyśleć program, który oblicza wartość jakiegoś programu
> czysto funkcyjnego

Ale nie ustaliliśmy jeszcze, co to znaczy, że program jest czysto funkcyjny. Twoje
argumenty to machanie rękami, bo każdy z nich da się rozciągnąć w dowolną stronę, co
pokazałem w obu kierunkach. W tej sytuacji określenie "program, który oblicza wartość
prograamu czysto funkcyjnego" to machanie rękami do kwadratu, jeszcze bardziej
nieużyteczne.

> To, czy liczba jest pseudolosowa, czy nie jest, czy pochodzi z wejścia,
> czy z kosmosu, nie ma znaczenia dla *ISTOTY* danego programu.

I właśnie tej istoty szukamy. Jeżeli istotą jest przetwarzanie wejścia na wyjście, to
wszystkie programy w istocie takie są. Natomiast jeśli jest nią generowanie efektów
ubocznych, to też wszystkie takie są.

> > I dalej nie wiemy, co to niby miałoby oznaczać.
>
> No, jeżeli usilnie staramy się nie zrozumieć, co to oznacza,
> to nie wiemy.

A może staramy się ujawnić dziury w definicji? Bo skoro nie potrafimy przekonująco
wyjaśnić co jakieś pojęcie oznacza, to może problem jest z samym pojęciem albo z
naszym przekonaniem, że je rozumiemy?

> Może sobie poczytaj https://mitpress.mit.edu/sicp/full-text/sicp/book/no
de10.html

Nie zakładaj, że jeszcze nie czytałem. Nie każdy troll jest niekompetentny. :-)

> Dałem kilka kontrprzykładów. Systemy kolejkowe czasu rzeczywistego
> nie są deterministyczną funkcją input->output. Być może mają komponenty,
> które można w taki sposób analizować, ale ich istotą jest działanie
> w czasie rzeczywistym, i reagowanie na zdarzenia w zależności od
> jakiegoś ich wewnętrznego stanu.

No to robimy ćwiczenie na wyobraźnię:

1. *Narysuj* zdarzenia w środowisku i otoczeniu programu, w ich rozciągłości
czasowej. Oś czasu, od lewej do prawej, z zaznaczonymi zdarzeniami, wartościami, itd.
2. Zrób z tego obrazka plik, np. w formacie PNG. Czyli *jedną wartość*.
3. Podobnie narysuj na osi czasu odpowiedź systemu na taką stymulację. Znowu, z
odpowiednią skalą czasu, wartościami (tak, żeby po złożeniu tych dwóch obrazków
powstał opis działania programu w czasie), itd.
4. Z tego drugiego obrazka też zrób plik.

Otóż okazuje się, że Twój "system czasu rzeczywistego" przetwarza pliki graficzne.
Czyli przetwarza pojedyncze wartości. To, czy wczyta od razu cały plik z wejścia i
wypluje cały plik na wyjściu, czy też będzie je przetwarzał po jednym pikselowym
pasku wzdłuż jednego boku obrazka (czyli np. wzdłuż osi czasu, co odpowiada naszej
percepcji działania w kontekście upływającego czasu) nie ma znaczenia dla istoty tego
programu, którą jest transformacja jednego obrazka w drugi.
Co ciekawe, ze względu na kwantyzację wszystkiego (łącznie z zegarem), takich
obrazków jest duża, ale jednak skończona ilość (czyli użyteczne rozmiary i
rozdzielczość obrazków są skończone). Czyli dałoby się nawet zrobić ten program jako
jedną mapę.

To teraz ten program jest "czysto funkcyjny", czy nie jest?

> Natomiast programy w rodzaju kompilatorów, konwerterów LaTeXa,
> sedów, są w istocie czysto funkcyjne w takim sensie, że dla określonego
> wejścia dają określone wyjście i kropka.

O, to program przetwarzający obrazki też się łapie.

> Podałem podczas tej rozmowy kilka przykładów.

A ja każdy z nich wygiąłem tam, gdzie chciałem.
Dlatego twierdzę, że pojęcia, którymi operujesz, są nieużyteczne.

> Istnieją programy, których istotą jest interakcja (np. gry komputerowe,
> przeglądarki internetowe), takie, których istotą jest wykonanie
> skutku ubocznego (np. mkdir albo rm), takie, które są w istocie
> niedeterministyczne (jak wspomniany framework do algorytmów genetycznych).
> A oprócz nich są programy czysto funkcyjne, które po prostu wyznaczają
> przekształcenia jakichs wejść w jakieś wyjścia.

I teraz ten cały podział nie dotyczy istoty działania programu (bo ta istota jest
zawsze taka sama), tylko sposobu, w jaki my, ludzie, danego programu użyjemy. Możemy
odpalić program jednym strzałem albo też delektować się powolnym budowaniem wyniku,
ale to jest ten sam program. Czyli dotyczy naszej percepcji a nie jest fundamentalnym
atrybutem problemu, który dany program rozwiązuje. Bo problem jest zawsze ten sam.
Dlatego rzeczy "czysto cośtam" zwykle nimi nie są.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu czwartek, 5 października 2017 01:37:44 UTC+2 użytkownik Maciej Sobczak
napisał:
> > Można sobie pomyśleć program, który oblicza wartość jakiegoś programu
> > czysto funkcyjnego
>
> Ale nie ustaliliśmy jeszcze, co to znaczy, że program jest czysto funkcyjny.

Z tego co patrzę na historię tej rozmowy, ustaliliśmy to na dość
wczesnym etapie.

> > To, czy liczba jest pseudolosowa, czy nie jest, czy pochodzi z wejścia,
> > czy z kosmosu, nie ma znaczenia dla *ISTOTY* danego programu.
>
> I właśnie tej istoty szukamy. Jeżeli istotą jest przetwarzanie wejścia na wyjście,
to wszystkie programy w istocie takie są. Natomiast jeśli jest nią generowanie
efektów ubocznych, to też wszystkie takie są.

Otóż właśnie nie, na co również dawałem przykłady.

> > Dałem kilka kontrprzykładów. Systemy kolejkowe czasu rzeczywistego
> > nie są deterministyczną funkcją input->output. Być może mają komponenty,
> > które można w taki sposób analizować, ale ich istotą jest działanie
> > w czasie rzeczywistym, i reagowanie na zdarzenia w zależności od
> > jakiegoś ich wewnętrznego stanu.
>
> No to robimy ćwiczenie na wyobraźnię:
>
> 1. *Narysuj* zdarzenia w środowisku i otoczeniu programu, w ich rozciągłości
czasowej. Oś czasu, od lewej do prawej, z zaznaczonymi zdarzeniami, wartościami, itd.
> 2. Zrób z tego obrazka plik, np. w formacie PNG. Czyli *jedną wartość*.
> 3. Podobnie narysuj na osi czasu odpowiedź systemu na taką stymulację. Znowu, z
odpowiednią skalą czasu, wartościami (tak, żeby po złożeniu tych dwóch obrazków
powstał opis działania programu w czasie), itd.
> 4. Z tego drugiego obrazka też zrób plik.
>
> Otóż okazuje się, że Twój "system czasu rzeczywistego" przetwarza pliki graficzne.
Czyli przetwarza pojedyncze wartości. To, czy wczyta od razu cały plik z wejścia i
wypluje cały plik na wyjściu, czy też będzie je przetwarzał po jednym pikselowym
pasku wzdłuż jednego boku obrazka (czyli np. wzdłuż osi czasu, co odpowiada naszej
percepcji działania w kontekście upływającego czasu) nie ma znaczenia dla istoty tego
programu, którą jest transformacja jednego obrazka w drugi.

Problem polega na tym, że mylisz w tej chwili istotę programu ze środkami
analizy. Owszem, każdy program można analizować przy pomocy pojęcia funkcji,
albo przy pomocy pojęcia maszyny stanu, albo czegoś jeszcze innego.
Ale to nie znaczy, że te środki analizy zawsze pokrywają się z istotą programu.
W szczególności, na przykład, częścią opisu maszyny stanu jest funkcja
przejścia w inny stan -- toteż używamy pojęcia funkcji pomocniczo do
opisania maszyny stanów. Ale diagram przejść stanu jest czymś istotnie
różnym od pojęcia funkcji.

> I teraz ten cały podział nie dotyczy istoty działania programu (bo ta istota jest
zawsze taka sama), tylko sposobu, w jaki my, ludzie, danego programu użyjemy. Możemy
odpalić program jednym strzałem albo też delektować się powolnym budowaniem wyniku,
ale to jest ten sam program. Czyli dotyczy naszej percepcji a nie jest fundamentalnym
atrybutem problemu, który dany program rozwiązuje. Bo problem jest zawsze ten sam.

Problem nie jest zawsze ten sam. Projektanci kompilatorów muszą zwracać
uwagę na zupełnie inne rzeczy, niż projektanci gier komputerowych albo
stron internetowych, po w pierwszym przypadku kluczowy jest wynik, a w
pozostałych -- interakcja.
Rzeczywiście, istniał kiedyś np. program do dowodzenia twierdzeń autorstwa
Boyera-Moore'a NQTHM, który dawał użytkownikom możliwość "delektowania się
powolnym budowaniem wyniku", ale to nie należało do jego istoty.

do góry

> > Ale nie ustaliliśmy jeszcze, co to znaczy, że program jest czysto funkcyjny.
>
> Z tego co patrzę na historię tej rozmowy, ustaliliśmy to na dość
> wczesnym etapie.

Bez przesady. Nawet nie podałeś definicji, tylko przykład, z którym ja się nie
zgodziłem. To mi się nie kwalifikuje jako "ustaliliśmy".

> > Jeżeli istotą jest przetwarzanie wejścia na wyjście, to wszystkie programy w
istocie takie są. Natomiast jeśli jest nią generowanie efektów ubocznych, to też
wszystkie takie są.
>
> Otóż właśnie nie, na co również dawałem przykłady.

Bez wejścia program nie ma danych do przetwarzania (albo ma zawsze te same, co jest
nieciekawe), bez wyjścia nie ma wyników (co też jest nieciekawe), a bez efektów
ubocznych nie może się komunikować (co też jest nieciekawe). Nie podałeś żadnego
przykładu, który by się z tych reguł wyłamywał.

Ogólnie, oodwoływanie się do takich pojęć jak "istota czegoś" jest trochę...
nieinżynierskie.

> Problem polega na tym, że mylisz w tej chwili istotę programu

No i znowu ta istota. Z ciekawości wpisałem w wyszukiwarkę i... nic. Ani w wikipedii,
ani nigdzie indziej. Po angielsku to pewnie "the essence of the program" i... znowu
nic.

Skoro to pojęcie nigdzie nie jest zdefiniowane i nikt go w branży nie używa, to chyba
nie świadczy o mnie bardzo źle, że *nadal* nie rozumiem, o co konkretnie chodzi?

> Owszem, każdy program można analizować przy pomocy pojęcia funkcji,
> albo przy pomocy pojęcia maszyny stanu, albo czegoś jeszcze innego.

Tak. Dlatego pojęcie "czysto funkcyjny" nie ma sensu.

> Projektanci kompilatorów muszą zwracać
> uwagę na zupełnie inne rzeczy, niż projektanci gier komputerowych albo
> stron internetowych, po w pierwszym przypadku kluczowy jest wynik, a w
> pozostałych -- interakcja.

Tak, i stosuje się różne metody do optymalizacji tych różnych celów. Ale nic nie jest
"czyste", bo bez interakcji nie da się pobrać danych ani podać wyników a bez wyniku
interakcja jest bezcelowa - a przez proste zmiany w formacie i sposobie uruchomienia
można zmienić jeden rodzaj programu w drugi. I o braku tej "czystości" właśnie tu
piszę.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu czwartek, 5 października 2017 13:48:58 UTC+2 użytkownik Maciej Sobczak
napisał:
> > > Ale nie ustaliliśmy jeszcze, co to znaczy, że program jest czysto funkcyjny.
> >
> > Z tego co patrzę na historię tej rozmowy, ustaliliśmy to na dość
> > wczesnym etapie.
>
> Bez przesady. Nawet nie podałeś definicji, tylko przykład, z którym ja się nie
zgodziłem. To mi się nie kwalifikuje jako "ustaliliśmy".

Pozwolę sobie wkleić:
W dniu poniedziałek, 2 października 2017 14:20:39 UTC+2 użytkownik Maciej Sobczak
napisał:
> > (Warto zwrócić uwagę, że kompilator
> > w istocie rzeczy jest programem czysto funkcyjnym,
>
> Nie, nie jest. I w ogóle co to miałoby znaczyć - "czysto funkcyjnym"?

Miałoby znaczyć tyle, że dla danego wejścia daje zawsze to samo wyjście.

(koniec cytatu)

> Ogólnie, oodwoływanie się do takich pojęć jak "istota czegoś" jest trochę...
nieinżynierskie.

Owszem. Ale dlaczego miałoby to być problemem?

> > Problem polega na tym, że mylisz w tej chwili istotę programu
>
> No i znowu ta istota. Z ciekawości wpisałem w wyszukiwarkę i... nic. Ani w
wikipedii, ani nigdzie indziej. Po angielsku to pewnie "the essence of the program"
i... znowu nic.
>
> Skoro to pojęcie nigdzie nie jest zdefiniowane i nikt go w branży nie używa, to
chyba nie świadczy o mnie bardzo źle, że *nadal* nie rozumiem, o co konkretnie
chodzi?

Stwierdzenie, że kompilator jest w istocie programem czysto funkcyjnym
oznacza tyle, że kompilacja jest rodzajem transformacji (przekształcenia).

> > Owszem, każdy program można analizować przy pomocy pojęcia funkcji,
> > albo przy pomocy pojęcia maszyny stanu, albo czegoś jeszcze innego.
>
> Tak. Dlatego pojęcie "czysto funkcyjny" nie ma sensu.

Ma dokładnie taki sens, jak powiedziałem.

> > Projektanci kompilatorów muszą zwracać
> > uwagę na zupełnie inne rzeczy, niż projektanci gier komputerowych albo
> > stron internetowych, po w pierwszym przypadku kluczowy jest wynik, a w
> > pozostałych -- interakcja.
>
> Tak, i stosuje się różne metody do optymalizacji tych różnych celów. Ale nic nie
jest "czyste", bo bez interakcji nie da się pobrać danych ani podać wyników a bez
wyniku interakcja jest bezcelowa - a przez proste zmiany w formacie i sposobie
uruchomienia można zmienić jeden rodzaj programu w drugi. I o braku tej "czystości"
właśnie tu piszę.

Piszesz błędnie.

Jeżeli mamy np. program

int square(int x) {
return x*x;
}

void main(int argc, char *argv[]) {
assert(argc > 1);
int n = atoi(argv[1]);
printf("kwadrat liczby %d wynosi %d\n", n, square(n));
}

to square jest czystą funkcją.

do góry