eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingOptymalizacja struktur danych dla programów funkcyjnych › Re: Optymalizacja struktur danych dla programów funkcyjnych
  • Data: 2017-10-04 20:02:27
    Temat: Re: Optymalizacja struktur danych dla programów funkcyjnych
    Od: Roman Tyczka <n...@b...no> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: