Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #30700 > unrolled thread

Optymalizacja struktur danych dla programów funkcyjnych

Back to article view | Back to pl.comp.programming

Contents

  Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-09-21 03:10 -0700
    Re: Optymalizacja struktur danych dla programów funkcyjnych wół, wół roboczy, wół dojno roboczo obronny 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-09-21 19:44 +0200
      Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-09-21 11:49 -0700
        Re: Optymalizacja struktur danych dla programów funkcyjnych Roman Tyczka <noemail@because.no> - 2017-09-21 22:35 +0200
        Re: Optymalizacja struktur danych dla programów funkcyjnych "M.M." <mmarszik@gmail.com> - 2017-09-21 13:41 -0700
        Re: Optymalizacja struktur danych dla programów funkcyjnych wół, wół roboczy, wół dojno roboczo obronny 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-09-28 18:08 +0200
          Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-09-28 10:22 -0700
            Re: Optymalizacja struktur danych dla programów funkcyjnych wół, wół roboczy, wół dojno roboczo obronny 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-09-28 19:54 +0200
            Re: Optymalizacja struktur danych dla programów funkcyjnych fir <profesor.fir@gmail.com> - 2017-09-28 12:14 -0700
    Re: Optymalizacja struktur danych dla programów funkcyjnych fir <profesor.fir@gmail.com> - 2017-09-30 04:57 -0700
      Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-09-30 07:58 -0700
        Re: Optymalizacja struktur danych dla programów funkcyjnych wół, wół roboczy, wół dojno roboczo obronny 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-09-30 17:14 +0200
          Re: Optymalizacja struktur danych dla programów funkcyjnych Szyk Cech <szyk100@o2.pl> - 2017-09-30 20:13 +0200
            Re: Optymalizacja struktur danych dla programów funkcyjnych wół, wół roboczy, wół dojno roboczo obronny 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-09-30 20:18 +0200
        Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-02 05:20 -0700
          Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-02 11:00 -0700
            Re: Optymalizacja struktur danych dla programów funkcyjnych Roman Tyczka <noemail@because.no> - 2017-10-03 11:35 +0200
              Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-03 10:52 -0700
            Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-03 09:56 -0700
              Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-03 11:01 -0700
                Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-03 15:21 -0700
                  Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-03 23:15 -0700
                    Re: Optymalizacja struktur danych dla programów funkcyjnych "M.M." <mmarszik@gmail.com> - 2017-10-04 09:36 -0700
                      Re: Optymalizacja struktur danych dla programów funkcyjnych Roman Tyczka <noemail@because.no> - 2017-10-04 20:02 +0200
                        Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-04 11:58 -0700
                    Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-04 16:37 -0700
                      Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-04 23:28 -0700
                        Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-05 04:48 -0700
                          Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-05 09:58 -0700
                            Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-06 05:01 -0700
                              Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-06 10:59 -0700
                                Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-07 14:22 -0700
                                  Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-08 01:47 -0700
                                    Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-08 14:30 -0700
                                      Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-08 22:58 -0700
                                        Re: Optymalizacja struktur danych dla programów funkcyjnych Maciej Sobczak <see.my.homepage@gmail.com> - 2017-10-09 05:25 -0700
                                          Re: Optymalizacja struktur danych dla programów funkcyjnych fir <profesor.fir@gmail.com> - 2017-10-09 09:12 -0700
                                          Re: Optymalizacja struktur danych dla programów funkcyjnych godek.maciek@gmail.com - 2017-10-09 10:47 -0700
      Re: Optymalizacja struktur danych dla programów funkcyjnych "M.M." <mmarszik@gmail.com> - 2017-09-30 12:54 -0700

Page 2 of 2 — ← Prev page 1 [2]

#30732

> 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

[toc] | [prev] | [next] | [standalone]

#30733

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/node10.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.

[toc] | [prev] | [next] | [standalone]

#30735

On Wednesday, October 4, 2017 at 8:15:08 AM UTC+2, godek....@gmail.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/node10.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

[toc] | [prev] | [next] | [standalone]

#30737

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, godek....@gmail.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/node10.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

[toc] | [prev] | [next] | [standalone]

#30738

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.

[toc] | [prev] | [next] | [standalone]

#30741

> 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/node10.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

[toc] | [prev] | [next] | [standalone]

#30742

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.

[toc] | [prev] | [next] | [standalone]

#30746

> > 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

[toc] | [prev] | [next] | [standalone]

#30747

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ą.

[toc] | [prev] | [next] | [standalone]

#30749

> > 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ć:

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

I bez wklejania, powtórzę: każdy program tak ma.

> > Ogólnie, oodwoływanie się do takich pojęć jak "istota czegoś" jest trochę... nieinżynierskie.
> 
> Owszem. Ale dlaczego miałoby to być problemem?

Bo jest nieprecyzyjne i niedookreślone. A stąd prosta droga do nieporozumień.

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

Każde przetwarzanie czegokolwiek takie jest.

> 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ą.

I w tym przykładzie kontekst jest ciekawszy, bo obszar użycia tego pojęcia jest dobrze określony. Pojęcie czystej funkcji (pure function) jest znane:

https://en.wikipedia.org/wiki/Pure_function

Co ciekawe, jest nawet użyteczne, nie tylko z powodów, o których pisałeś, ale również np. przy analizie poprawności albo optymalizacji programów wielowątkowych.

Natomiast pojęcie *programu* czysto funkcyjnego jest słabe, bo właśnie granica pojęcia programu jest na jego efektach ubocznych, więc nie ma jak tej czystości zdefiniować. A podpieranie się hasłami typu "istota programu" prowadzi do kolejnych niedopowiedzeń, bo "istotą" Twojego ostatniego przykładu może nie być liczenie, tylko dialog z użytkownikiem albo formatowanie tesktu a programista użył square przypadkiem, bo akurat nie umiał napisać pierwiastkowania.

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

[toc] | [prev] | [next] | [standalone]

#30751

W dniu piątek, 6 października 2017 14:01:22 UTC+2 użytkownik Maciej Sobczak napisał:
> > > 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ć:
> 
> > Miałoby znaczyć tyle, że dla danego wejścia daje zawsze to samo wyjście.
> > 
> > (koniec cytatu)
> 
> I bez wklejania, powtórzę: każdy program tak ma.

Widzę, że masz wielką ochotę kręcić się w kółko.
Otóż nie każdy. Jeżeli chcesz jeszcze inną garść przykładów,
to na przykład programy na maszyny niedeterministyczne
tak nie mają.
Tutaj masz przykłady:
https://en.wikipedia.org/wiki/Nondeterministic_finite_automaton
https://en.wikipedia.org/wiki/Non-deterministic_Turing_machine


> > > Ogólnie, oodwoływanie się do takich pojęć jak "istota czegoś" jest trochę... nieinżynierskie.
> > 
> > Owszem. Ale dlaczego miałoby to być problemem?
> 
> Bo jest nieprecyzyjne i niedookreślone. A stąd prosta droga do nieporozumień.

"Nieinżynierskie" nie znaczy ani "nieprecyzyjne" ani "nieokreślone".
Pojęcie istoty też ma swój wpis na wikipedii:

https://en.wikipedia.org/wiki/Essence

> > Stwierdzenie, że kompilator jest w istocie programem czysto funkcyjnym
> > oznacza tyle, że kompilacja jest rodzajem transformacji (przekształcenia).
> 
> Każde przetwarzanie czegokolwiek takie jest.

Nie każde. Istnieją przetwarzania niedeterministyczne, stochastyczne
itd.

> > 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ą.
> 
> I w tym przykładzie kontekst jest ciekawszy, bo obszar użycia tego pojęcia jest dobrze określony. Pojęcie czystej funkcji (pure function) jest znane:
> 
> https://en.wikipedia.org/wiki/Pure_function
> 
> Co ciekawe, jest nawet użyteczne, nie tylko z powodów, o których pisałeś, ale również np. przy analizie poprawności albo optymalizacji programów wielowątkowych.
> 
> Natomiast pojęcie *programu* czysto funkcyjnego jest słabe, bo właśnie granica pojęcia programu jest na jego efektach ubocznych, więc nie ma jak tej czystości zdefiniować. A podpieranie się hasłami typu "istota programu" prowadzi do kolejnych niedopowiedzeń, bo "istotą" Twojego ostatniego przykładu może nie być liczenie, tylko dialog z użytkownikiem albo formatowanie tesktu a programista użył square przypadkiem, bo akurat nie umiał napisać pierwiastkowania.

Akurat w tym przypadku łatwo jest stwierdzić, że istotą tego
programu jest podanie kontrprzykładu dla Twojego wcześniejszego twierdzenia.
Natomiast nie ma nic kontrowersyjnego w tym, że np. istotą programu
do dowodzenia twierdzeń jest dowodzenie twierdzeń, istotą kompilacji
jest przekształcanie programów w języku zrozumiałym dla człowieka
w równoważne programy w języku wykonywalnym przez maszynę, albo że
istotą gry komputerowej jest dostarczanie interaktywnej rozrywki.
Wynika to z samych definicji pojęć i nie potrzeba niczego więcej.

[toc] | [prev] | [next] | [standalone]

#30755

> Widzę, że masz wielką ochotę kręcić się w kółko.

Wręcz przeciwnie. Staram się zmusić Ciebie do wyjścia z tego kołka.

> Otóż nie każdy. Jeżeli chcesz jeszcze inną garść przykładów,
> to na przykład programy na maszyny niedeterministyczne
> tak nie mają.
> Tutaj masz przykłady:
> https://en.wikipedia.org/wiki/Nondeterministic_finite_automaton
> https://en.wikipedia.org/wiki/Non-deterministic_Turing_machine

Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak zaimplementować. W szczególności w pierwszym linku jest sekcja Implementation, która podaje kilka metod *deterministycznych*, polegających w szczególności na tym: "Create multiple copies". Czyli zamiast niedeterministycznegp przejścia do jednego z N stanów, robimy te wszystkie N stanów i udajemy, że możemy być w dowolnym z nich.
Przykład z okolic obliczeń kwantowych byłby bardziej interesujący, ale jednocześnie bardziej odległy od Twojego początkowego wątku z kompilacją jako obliczeniem czysto funkcyjnym. Więc skupmy się: obecne komputery są deterministyczne a wszystkie działające na nich programy spełniają Twoje kryteria bycia "czysto funkcyjnymi" (jak również nie bycia nimi - co już omówiliśmy). Albo zły kontekst albo zła definicja.

> "Nieinżynierskie" nie znaczy ani "nieprecyzyjne" ani "nieokreślone".
> Pojęcie istoty też ma swój wpis na wikipedii:
> 
> https://en.wikipedia.org/wiki/Essence

Słowo "program" nie występuje na tej stronie. Podawanie linków nie na temat jest jeszcze bardziej nieinżynierskie. :-)

> Istnieją przetwarzania niedeterministyczne, stochastyczne
> itd.

No pewnie. Ale nie na naszych komputerach, co oznacza, że usiłując udowodnić swoją rację coraz bardziej oddalasz się od początkowego wątku.

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

[toc] | [prev] | [next] | [standalone]

#30756

W dniu sobota, 7 października 2017 23:22:55 UTC+2 użytkownik Maciej Sobczak napisał:

> > Otóż nie każdy. Jeżeli chcesz jeszcze inną garść przykładów,
> > to na przykład programy na maszyny niedeterministyczne
> > tak nie mają.
> > Tutaj masz przykłady:
> > https://en.wikipedia.org/wiki/Nondeterministic_finite_automaton
> > https://en.wikipedia.org/wiki/Non-deterministic_Turing_machine
> 
> Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak zaimplementować.

Masz jakąś szerszą wiedzę na ten temat?
Podobno owo rozstrzygnięcie jest największym otwartym problemem
w informatyce, więc gdybyś wiedział coś więcej, koniecznie daj znać ;]

Z punktu widzenia dyskusji istotna jest kwestia, czy pojęcie
jest dobrze zdefiniowane. 

W przytaczanym przeze mnie przykładzie frameworku do optymalizacji
genetycznej nie ma znaczenia, czy operator "random" jest zaimplementowany
jako procedura pseudolosowa, czy jako odczyt z urządzenia generującego
prawdziwie losowe liczby, czy też w taki sposób, że osoba, która interpretuje
program, rzuca kością przy podstawieniu. Albo czy może wie skądinąd,
jakie liczby najszybciej doprowadzą do znalezienia optymalnego rozwiązania.

> > Istnieją przetwarzania niedeterministyczne, stochastyczne
> > itd.
> 
> No pewnie. Ale nie na naszych komputerach, co oznacza, że usiłując udowodnić swoją rację coraz bardziej oddalasz się od początkowego wątku.

Czy pisząc "początkowy wątek" masz na myśli Twoją niezgodę
na moje stwierdzenie, że "kompilator jest w istocie programem
czysto funkcyjnym"?
Jeśli tak, to nie oddalam się ani o jotę, bo w owym stwierdzeniu
nie ma ABSOLUTNIE NIC o "naszych komputerach".
Stwierdzenie owo jest równoważne powiedzeniu, że kompilator
jest zasadniczo rodzajem deterministycznego przekształcenia,
i nie wydaje mi się przesadnie kontrowersyjne.
Tobie się ono nie spodobało -- jak zrozumiałem -- z tego wględu,
że według Ciebie każdy program jest rodzajem deterministycznego
przekształcenia, i że stwierdzenie, że "x jest w istocie
programem czysto funkcyjnym" nie dodaje nic do stwierdzenia
"x jest programem", na co ja wypunktowałem, że można też mówić
z jednej strony o programach niedeterministycznych (które nie
są czysto funkcyjne ze względu na swój niedeterminizm), a z drugiej
o systemach interaktywnych, których istota nie wyczerpuje się
w deterministycznym przekształceniu wejścia w wyjście (bo -- jak
pozwolę sobie dopowiedzieć -- ISTOTNĄ rolę przy naszej konceptualizacji
takich systemów odgrywa pojęcie "bieżącego stanu").

[toc] | [prev] | [next] | [standalone]

#30758

> > Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak zaimplementować.
> 
> Masz jakąś szerszą wiedzę na ten temat?

Podałeś linka a tam jest to opisane. Następnym razem podaj takiego linka, z którym będziesz się zgadzał.

> Z punktu widzenia dyskusji istotna jest kwestia, czy pojęcie
> jest dobrze zdefiniowane.

Bingo. Właśnie tego się od początku czepiam. :-)

> Czy pisząc "początkowy wątek" masz na myśli Twoją niezgodę
> na moje stwierdzenie, że "kompilator jest w istocie programem
> czysto funkcyjnym"?

Tak.

> Jeśli tak, to nie oddalam się ani o jotę, bo w owym stwierdzeniu
> nie ma ABSOLUTNIE NIC o "naszych komputerach".

I teraz jesteśmy bliżej, bo mamy dokładniej zdefiniowany kontekst.

> Stwierdzenie owo jest równoważne powiedzeniu, że kompilator
> jest zasadniczo rodzajem deterministycznego przekształcenia,
> i nie wydaje mi się przesadnie kontrowersyjne.

Ale dlaczego ma nie być kontrowersyjne? Przecież może być wiele sposobów na kompilację (sam fakt, że jest wiele kompilatorów popularnych języków już na to wskazuje, nie mówiąc o ich różnych opcjach), więc nie ma powodu twierdzić, że kompilacja musi być deterministyczna.
Problem jest tutaj w kryterium poprawności. O ile funkcja square ma dosyć dobrze określone takie kryterium i w zasadzie to kryterium powoduje, że funkcja square będzie deterministyczna (bo inny wynik dla tego samego argumentu będzie uznany za niepoprawny), to poprawność kompilatora nie jest tak dobrze określona. Stąd też mnogość kompilatorów. Stąd też brak wymagania na to, żeby kompilator był deterministyczny. A skoro nie musi być deterministyczny, to nie ma powodu przypisywać mu cechy bycia "czysto funkcyjnym".

Ot, takie zabawy z definicjami. :-)

> Tobie się ono nie spodobało -- jak zrozumiałem -- z tego wględu,
> że według Ciebie każdy program jest rodzajem deterministycznego
> przekształcenia

Tak. Na domniemanych współczesnych komputerach. Możemy od nich odejść, ale jeśli mamy przy nich pozostać, to trzymam się determinizmu.

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

[toc] | [prev] | [next] | [standalone]

#30761

W dniu niedziela, 8 października 2017 23:30:19 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak zaimplementować.
> > 
> > Masz jakąś szerszą wiedzę na ten temat?
> 
> Podałeś linka a tam jest to opisane. Następnym razem podaj takiego linka, z którym będziesz się zgadzał.

W artykule jest napisane:

"How does the NTM "know" which of these actions it should take? There are two ways of looking at it. One is to say that the machine is the "luckiest possible guesser"; it always picks a transition that eventually leads to an accepting state, if there is such a transition. The other is to imagine that the machine "branches" into many copies, each of which follows one of the possible transitions."

O ile wiem, nikt do tej pory nie udowodnił, że nie można
sensownie zaimplementować wariantu "luckiest possible guesser"

> > Z punktu widzenia dyskusji istotna jest kwestia, czy pojęcie
> > jest dobrze zdefiniowane.
> 
> Bingo. Właśnie tego się od początku czepiam. :-)

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, natomiast
Ty stwierdziłeś, że jest deterministyczne, bo owa losowość
w faktycznej implementacji będzie albo pseudo-losowością,
i wówczas będzie deterministyczna, albo będzie dodatkowym
wejściem do programu, przez co program jako taki również
będzie deterministyczny.
Czyli Twoja argumentacja NIE ODNOSIŁA się do istoty
pojęcia, tylko do (chyba niezbyt dobrze zdefiniowanej?)
koncepcji "implementowalności pojęcia"

> > Czy pisząc "początkowy wątek" masz na myśli Twoją niezgodę
> > na moje stwierdzenie, że "kompilator jest w istocie programem
> > czysto funkcyjnym"?
> 
> Tak.
> 
> > Jeśli tak, to nie oddalam się ani o jotę, bo w owym stwierdzeniu
> > nie ma ABSOLUTNIE NIC o "naszych komputerach".
> 
> I teraz jesteśmy bliżej, bo mamy dokładniej zdefiniowany kontekst.

Wcześniej w tym stwierdzeniu również nie było nic o "naszych komputerach" ;p

> > Stwierdzenie owo jest równoważne powiedzeniu, że kompilator
> > jest zasadniczo rodzajem deterministycznego przekształcenia,
> > i nie wydaje mi się przesadnie kontrowersyjne.
> 
> Ale dlaczego ma nie być kontrowersyjne? Przecież może być wiele sposobów na kompilację (sam fakt, że jest wiele kompilatorów popularnych języków już na to wskazuje, nie mówiąc o ich różnych opcjach), więc nie ma powodu twierdzić, że kompilacja musi być deterministyczna.

My, jako ludzie, chcemy, żeby kompilacja była deterministyczna,
bo chcemy wiedzieć, czego możemy się spodziewać po kompilatorach.

> Problem jest tutaj w kryterium poprawności. O ile funkcja square ma dosyć dobrze określone takie kryterium i w zasadzie to kryterium powoduje, że funkcja square będzie deterministyczna (bo inny wynik dla tego samego argumentu będzie uznany za niepoprawny), to poprawność kompilatora nie jest tak dobrze określona. Stąd też mnogość kompilatorów. Stąd też brak wymagania na to, żeby kompilator był deterministyczny. A skoro nie musi być deterministyczny, to nie ma powodu przypisywać mu cechy bycia "czysto funkcyjnym".

Wydaje mi się, że jednak poprawność kompilatora jest dość dobrze
określona. Zaś o ile być może z perspektywy tego czy innego użytkownika
wymaganie, żeby kompilator był deterministyczny, może nie wydawać się
istotne, to z perspektywy osób, które tworzą kompilatory, takie wymaganie
jest jak najbardziej na miejscu. (Pominę tu kwestię ekwiwokacji, związanej
z tym, że raz słowo "kompilator" jest użyte w istotnym sensie, tzn.
odnosi się do programu realizującego przekształcenie, a innym razem
w sensie metonimicznym -- do pakietu oprogramowania, który daje użytkownikowi
różne "opcje")

> > Tobie się ono nie spodobało -- jak zrozumiałem -- z tego wględu,
> > że według Ciebie każdy program jest rodzajem deterministycznego
> > przekształcenia
> 
> Tak. Na domniemanych współczesnych komputerach. Możemy od nich odejść, ale jeśli mamy przy nich pozostać, to trzymam się determinizmu.

Tzn. na domniemanych przez Ciebie współczesnych komputerach.
Ja ze swojej strony w ogóle nie wypowiadałem się o komputerach,
tylko o programach.

[toc] | [prev] | [next] | [standalone]

#30768

> 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.

> 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.

> Czyli Twoja argumentacja NIE ODNOSIŁA się do istoty
> pojęcia,

Co to jest "istota pojęcia"? Czy "istota programu" już nie wystarcza?

> 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.

> 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.
Kompilator nie musi być deterministyczny, żeby zapewnić użytkownikowi zgodność na poziomie sekwencji udokumentowanych efektów ubocznych.

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

Zwykle jest celowo niedookreślona.

> 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ć.

> 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?

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

[toc] | [prev] | [next] | [standalone]

#30771

nie czytam tego watku ale moge powiedziec pewna uwage ktora mnie naszla (a ktora moze byc troche apropos tematu jezykow funkcyjnych): 

spotkalem dzis na ulicy pewnego znajomego  i mowie mu ze cos niewyraznie sie czuje bo naszla mnie jakas faza wspolczucia dla biednych, bezdomych (naszlo mnie tio poniekad po obejrzemniu wywiadu z ikonowiczem, fajnym gosciem ) - ten mowi "zwykle ludzkie odczucia", ja mo mowie dla mnie ne takie zwykle bo ja na codzien bujam w programistycznych oblokach, ten "no tak, w cyfrowej chmurze" ja na to "dokladnie"

koles urzyl dobrego pojecia bo cyfrowa chmura dosyc dobrze oddaje to co ja lubie w programowaniu - oldschoolowe programowanie jakie ja bym lubil wydaje sie powinno wlasnie opierac sie o ta cyfrowosc - tymczasem gdy wspolczesne kojarzace mi sie bardziewiascie raczej trendy powoduja ze programisci nie siedzą w tych chmurach cyfrowych tylko raczej leksykalnych - juz nawet c jest w sporym procencie leksykalny (mataforycznie powiedzialbym ze o ile javaskrypt moglbym nazwac leksykalnym w 60% to c pewnie tak w 20-30, takie jezyki jak lisp wyobrazaja mi sie ;c (zapewne blednie) jako cos dązacego do 95% lekykalnosci - a dla mnei takie leksykalne programowanie to nie jest fun
(oczywiscie moze sie myle bo patrzac na rzeczy z dystansu mozna sie myli (jest prawie 100^ gwarancja mylnosci tak naprawde)) ale tak to widze i dlatego nie ciagnie mnie do lispa bo nie ciagnie mnie do takich leksykalnych klimatow (raczej uwazam je za zmore, regexpy przykladem)

[toc] | [prev] | [next] | [standalone]

#30772

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.

[toc] | [prev] | [next] | [standalone]

#30720

On Saturday, September 30, 2017 at 1:57:06 PM UTC+2, fir wrote:
> W dniu czwartek, 21 września 2017 12:10:49 UTC+2 użytkownik godek....@gmail.com napisał:
> > Cześć,
> > jakiś czas temu wspominałem o pracy magisterskiej, którą pisałem.
> > Ponieważ właśnie ją obroniłem, niniejszym ją upubliczniam.
> > Praca dostępna jest pod adresem
> > 
> spoko ale mysle ze stety czy nieststy tutaj malo osob jest zainteresowanych jezykami funkcyjnymi, (co nie znaczy ze nie mozna o nich pisac)

Tu w ogóle jest mało osób - moim zdaniem niestety.
Pozdrawiam

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | pl.comp.programming

csiph-web