Informacja w ujęciu obliczeniowym. Dyskusja wokół tekstu Giuseppe Primiero.

Chciałbym wywołać luźną dyskusję nad tekstem Giuseppe Primiero, który w ramach swojej wizyty badawczej na PW (listopad 2019) omawiał między innymi zagadnienie wskazane w tytule obecnego wpisu.

Podstawą dyskusji chciałbym uczynić: a) artykuł naukowy prof. Primiero, oraz b) slajdy do jego wykładu, wygłoszonego na wydziale WEiTI PW.
Być może przydatne okażą się także moje slajdy, w których prezentuję podobne zagadnienia, choć z nieco innej perspektywy.

Dobrym streszczeniem koncepcji omawianej w źródłach a i b (czyli podstawowych) jest następujący obrazek:

Obrazek informacyjnej piramidy

Widzimy na nim 5 warstw abstrakcji (ang. layers of abstractions), które dotyczą informacji w ujęciu obliczeniowym. Na warstwie najniższej (u góry rysunku) informację utożsamia się z układem fizycznych (elektrycznych) stanów maszyny, które są kontrolowane za pomocą struktur określonych na wyższych warstwach. Na warstwie najwyższej (u dołu) informację rozumie się jako – właściwie jest to kwestia do dyskusji – konfigurację mentalnych stanów projektanta systemu obliczeniowego, który to projektant „ma w swojej głowie” reprezentację pewnego problemu do rozwiązania, żywi intencję jego rozwiązania oraz, co najważniejsze, zna ogólny sposób rozwiązania. Ów sposób jest rozpisywany/implementowany na kolejnych warstwach… jako algorytm, program, a następnie maszynowy kod.
W moim odczuciu, w obrębie wszystkich warstw, informacja jest rozumiana jako relacja pomiędzy wejściem i wyjściem, czy też między danymi wejściowymi i danymi wyjściowymi – choć w tekście Giuseppe Primiero nie znajdziemy wprost takiego określenia. Z tego względu informacja jest tutaj czymś dynamicznym, algorytmicznym, obliczeniowym… jest wprawdzie pewną strukturą, ujmowaną na różnych poziomach w różny sposób, ale strukturą relacyjną, warunkującą działanie (action, operation, problem solving itp).

W powyższym skrótowym opisie, podzieliłem się z Państwem własną interpretacją koncepcji prof. Primiero, którą to interpretację poddaję, rzecz jasna, pod dyskusję.
Poddaję pod dyskusję również kilka innych zagadnień, które nasunęły mi się podczas lektury zalinkowanych wyżej źródeł.
Oto one:

1) Która z warstw wskazanych na rysunku wydaje się Państwu, z punktu widzenia informatyki, najważniejsza?

2) Czy wszystkie warstwy są równie istotne dla ujęcia istoty informacji/danych? Na przykład: czy trzech warstw wewnętrznych (kod maszynowy, program, algorytm) nie należałoby „zwinąć” do postaci jednej, algorytmiczno-programistycznej, warstwy?

3) Czy przedstawione ujęcie nie zamazuje różnicy między danymi (również strukturami danych) i algorytmami? Czy ujęcie to, poprzez utożsamienie informacji z czymś algorytmicznym (relacyjnym, regułowym, dynamicznym), nie postuluje jednak, że najważniejszym pojęciem informatyki jest algorytm, a nie informacja?

4) Czy do przedstawionego zestawu warstw nie należy czegoś dodać, np. warstwy modelu obliczeń, na której moglibyśmy rozróżnić (w ujęciu matematycznym) różne elementarne sposoby kodowania/zapisywania danych (np. w przypadku układów analogowych mamy kod ciągły, a w przypadku cyfrowych – dyskretny)?

Oczywiście, jak zwykle, można stawiać inne jeszcze pytania i próbować na nie odpowiadać.
Najlepiej w interakcji z innymi, :).

Z niecierpliwością czekam na pierwsze głosy – Paweł Stacewicz.

Ten wpis został opublikowany w kategorii Dydaktyka logiki i filozofii, Filozofia informatyki, Filozofia nauki, Światopogląd informatyczny. Dodaj zakładkę do bezpośredniego odnośnika.

25 odpowiedzi na „Informacja w ujęciu obliczeniowym. Dyskusja wokół tekstu Giuseppe Primiero.

  1. ms pisze:

    Odpowiadając po kolei na zadane pytania, moim zdaniem:

    1) Z punktu widzenia informatyki, o ile wszystkie warstwy są potrzebne, to wydaje mi się, że warstwa związana z algorytmami jest najistotniejsza. Niższe warstwy stanowią w jakimś sensie maszynerię potrzebną do implementacji algorytmu, natomiast warstwa intencji moim zdaniem częściowo wychodzi wręcz z informatyki.

    2) Nie można połączyć warstw wewnętrznych. Wynika to głównie z tego, że operując na każdej z nich informatyk musi myśleć w radykalnie inny sposób. Zupełnie czym innym jest pisanie algorytmu oraz jego implementacji. W związku z tym, każda z tych warstw musi się cechować czymś innym, a więc istnieje sens oddzielania ich.

    3) Fakt uwzględniania poziomu ładunków elektrycznych i intencji w moim odczuciu kłóci się ze stwierdzeniem, że algorytm wyłania się z tej koncepcji jako najważniejsze pojęcie informatyki.

    4) Warto by podzielić warstwę języka programowania, a przynajmniej zauważyć, że jest stopniowalna. Programowanie w językach stosunkowo niskiego poziomu (np. C) radykalnie różni się od programowania w językach deklaratywnych (Prolog, SQL, QML). W tych pierwszych wymagane jest explicite “tłumaczenie” krok po kroku komputerowi co ma zrobić, w tych drugich istotny jest dla nas wyłącznie wynik operacji. Ta różnica powoduje, że trudno mi uznać poziom języka programowania z jedną warstwę.

    • Paweł Stacewicz pisze:

      — Nie można połączyć warstw wewnętrznych…

      O ich połączeniu myślałem właśnie dlatego, żeby w proponowanym schemacie oddzielić część sticte informatyczną, a może lepiej softwarową (bo wszystkie trzy warstwy wewnętrzne dotyczą jakichś form kodowania softwaru) od warstw pozostałych — które uwypuklają inne aspekty projektowania i działania systemów komputerowych: aspekt fizykalny/hardwarowy oraz czysto konceptualny (który może być rozpatrywany zupełnie niezależnie od jakiejkolwiek technologii, po prostu wymyślamy takie czy inne metody rozwiązywania problemów).

      — Warto by podzielić warstwę języka programowania, a przynajmniej zauważyć, że jest stopniowalna…

      W ramach referowanej koncepcji podział nie byłby chyba celowy, bo chybna nie jest tak, że wewnątrz komputera/systemu zachodzą stopniowe translacje procedur napisanych w językach wysokiego poziomu na zapisy w językach coraz niższego poziomu. W pewnym sensie zatem wszystkie języki wyższego poziomu (C, SQL…) są sobie równoważne. Ich kod jest bowiem przekładany od razu na język maszynowy. Chyba, że się mylę…

  2. Jarek pisze:

    — chybna nie jest tak, że wewnątrz komputera/systemu zachodzą stopniowe translacje procedur napisanych w językach wysokiego poziomu na zapisy w językach coraz niższego poziomu.

    Jest. Bardzo charakterystycznym przypadkiem jest bardzo dzisiaj rozpowszechniony język Java. Kod źródłowy napisany przez programistę tłumaczony jest przez kompilator do pewnego sztucznego języka, realizowanego potem przez środowisko wykonawcze (Java Runtime Evironment, JRE), a nie bezpośrednio przez komputer. Sam komputer ze współczesnym systemem operacyjnym też nie realizuje wprost w procesorze kody wykonywalnego programu, a jest to w dużej mierze ciąg wywołań funkcji jądra (kernela) systemu. Jeszcze głębiej, w procesorze, realizacja pojedynczej instrukcji może być wywołaniem algorytmu zaimplementowanego w tym procesorze. Przy kompilacji kodu napisanego w języku C właściwe tłumaczenie poprzedzone jest działaniem preprocesora. Dzięki preprocesorom, kompilator, który w zasadzie powinien tłumaczyć z języka C, potrafi również “zrozumieć” inne języki, na przykład Fortran.
    Tłumaczenie wprost z języka wysokiego poziomu do kodu procesora to rzadkość, w zasadzie niespotykana. Natomiast warstw językowych może być bardzo wiele.

    • Paweł Stacewicz pisze:

      Bardzo dziękuję. Nie byłem tego świadom. Zaczynam nabierać podejrzeń, że z punktu widzenia praktyków, analiza przedstawiona w dyskutowanym tekście jest mocno uproszczona.
      Jeśli jednak jest tak, że w większości przypadków taka czy inna forma kodu maszynowego jest niezbędna i jest ostatnim ogniwem przekształcania/translacji instrukcji różnych języków wysokiego poziomu, to uwzględnienie warstwy kodu maszynowego jest konieczne; zaś skumulowanie wszystkich pośrednich języków wyższego poziomu na jednej (reprezentującej je wszystkie, choć możliwej do jakiegoś dalszego rozwarstwienia) warstwie analizy wydaje się zasadne.
      Czy idę dobrym tropem…?

      • Paweł Polak pisze:

        Podzielam opinię, że analiza wydaje się mocno uproszczona. Chciałbym zwrócić tutaj natomiast dodatkowo uwagę na szczególnie intrygujące uproszczenie. Kryje się ono niewinnie pod pierwszą strzałką skierowaną w dół po lewej stronie rysunku. Stwierdzenie należy czytać zapewne tak: “Electrical charge is controlled by the machine code”.

        W zasadzie, z bardzo, bardzo ogólnego punktu widzenia jest to prawdą, ale jeśli przyjrzeć się bliżej to jest tu ukryte wiele interesujących problemów, które z łatwością dostrzeże każdy kto zajmował się budową mikroprocesora. Patrząc na warstwę fizyczną (rozkład ładunków domieszkowanym półprzewodniku) każdy fizyk słusznie oczekiwałby, że zmiany tegoż rozkładu będą wynikiem oddziaływań fizycznych (np. zmiana pola). W takim opisie nie ma miejsca na pojęcie ‘kod maszynowy’. Innymi słowy ‘kod maszynowy’, czyli pewna struktura językowa, nie pasuje na typową przyczynę oddziaływań fizycznych.

        To sugeruje według mnie dwie rzeczy: albo mamy tu ukryty duży przeskok ontologiczny (np. kilka warstw), albo autor zakłada że cała rzeczywistość jest czymś w rodzaju struktury językowej (a to już przedsionek pankomputacjonizmu). Tak, czy inaczej, interesujący problem został sprytnie ukryty.

        W kwestii zaś, czy można wszystkie warstwy językowe redukować do poziomu maszynowego odpowiedź zwolenników języków obiektowych jest jednak negatywna. Owszem, możemy dokonywać tłumaczenia, ale to, co opisują języki obiektowe jest bogatsze od środków wyrazu języka maszynowego. Warto zapytać o to Roberta Janusza (obecnie w obserwatorium w Castelgandolfo).

      • Jarek pisze:

        – Czy idę dobrym tropem…?

        Nie jestem tego pewien. Dla praktyków (praktykujących codzienne pisanie programów) wiedza o warstwowości procesu tłumaczenia kodu może być nieistotna. Większość z nich w ogóle nie zaprząta sobie tym tematem głowy – specjalizacja w dziedzinie IT jest daleko posunięta, więc nie muszą. Natomiast z punktu widzenia teorii, rzecz ta może być bardzo ważna. Mam na myśli teorię obliczalności.

        Twierdzenie, że każdy proces algorytmiczny można realizować za pomocą Uniwersalnej Maszyny Turinga (UMT) znane jest od dziesięcioleci. Mówi się też, że Realny Komputer Cyfrowy jest równoważny UMT. Wyobraźmy sobie, że zamiast realnych krzemowych procesorów z ich językiem maszynowym, mamy fizyczną realizację UMT, działającą tak, jak to opisał Turing. Maszynę nieskończonej wielkości i niebywale szybką. Tak szybką, jak choćby procesy kwantowe – a to już nie znaczy „nieskończenie szybka”. Gdyby w oparciu o taką maszynę realizowała swoje usługi firma Google, to na pytanie zadane wyszukiwarce nie czekałoby się ułamka sekundy, tylko… trudno powiedzieć ile, ale dużo dłużej. Może nawet dłużej, niż istnieje ta firma. A teraz mamy do dyspozycji jedynie procesory taktowane częstotliwością zaledwie kilku GHz.

        W teorii obliczalności posługujemy się często pojęciem „skończony czas”. Ale nie bez znaczenia jest też pokrewna definicja „rozsądnego czasu” (RC). Ogólnie RC można zdefiniować jako „krótszy od wieku Wszechświata”. Dla pewnych zagadnień (np. obliczenia fizyczne) może to być „krótszy niż życie człowieka”, a dla jeszcze innych (np. praktyczna kryptografia) może to być godzina, minuta lub sekunda. Są problemy, których nie da się rozwiązać w RC przy użyciu współczesnych procesorów działających na podobieństwo UMT. Ale stają się one rozwiązywalne, gdy używamy (dodatkowo) układów elektronicznych działających inaczej niż przez sekwencyjne wykonywanie rozkazów.

        Wniosek z tego płynie taki: od sprzętu zależy więcej, niż się u zarania informatyki teoretycznej wydawało (chyba nie popełniam błędu zakładając, że „informatyka teoretyczna” nie jest nauką całkowicie oderwaną od rzeczywistości, a ma dostarczać wsparcia rozwojowi informatyki stosowanej, czyli po prostu konstrukcji komputerów i ich oprogramowania).

        Drugi wniosek dotyczy języka opisu problemów, o czym wspomniał już Paweł Polak. Istnienie wysokopoziomowych języków warunkuje możliwość przystąpienia do ich rozwiązywania. Kod maszynowy to za mało, nie wystarczają również takie języki jak Fortran. Notacje matematyczne (czy logiczne) powstałe w ubiegłych wiekach, to też za mało.

        • Paweł Stacewicz pisze:

          Zgadzam się, że zagadnienie obliczalności praktycznej (jak szybko/wydajnie coś możemy obliczyć) wiąże się bardzo silnie z typem sprzętu, w tym jego architekturą (np. sekwencyjna vs równoległa), na którym działamy.
          Rozumiem, że sugestia jest taka, że dla każdego typu sprzętu (choć tu wynika pytanie o odpowiednią typologię), należy zaproponować inny schemat warstw pośrednich i przejść między nimi — warstw połączonych ostatecznie z warstwą najniższą czyli fizykalną.

          Takie rozwiązanie umacnia mnie jeszcze silniej w przekonaniu,że dla wyostrzenia pewnych kwestii filozoficznych (a nie czysto technologicznyh) – np. tej, o której wspominał P. Polak – wszystkie możliwe warstwy pośrednie warto scalić do postaci jednej programistyczno-algorytmicznej warstwy; pozostawiając oprócz niej w. fizykalną i w. intencji.

          Druga kwestia, która zasługuje chyba na osobny wpis (aby nie rozpraszać dyskusji, proponuję jej tu nie rozwijać), to większa siła wyrazu, w sensie klasy rozwiązywanych problemów, pewnych języków wysokiego poziomu (np. obiektowych) niż kodu maszynowego. Intuicyjnie, wydaje mi się to podejrzane; to znaczy owa większa siła wyrazu. Tym bardziej zachęcam do przygotowania osobnego wpisu na ten temat. Chętnie swoją intuicję skoryguję…

          • Jarek pisze:

            — Rozumiem, że sugestia jest taka, że dla każdego typu sprzętu (choć tu wynika pytanie o odpowiednią typologię), należy zaproponować inny schemat warstw pośrednich i przejść między nimi – warstw połączonych ostatecznie z warstwą najniższą czyli fizykalną.

            Przeciwnie. Stosowany powszechnie schemat warstw oprogramowania służy również uniezależnieniu się od zmian sprzętowych. W systemie operacyjnym jako osobny byt wyróżnia się jego jądro (kernel), służące komunikacji ze sprzętem. Wewnątrz kodu kernela też da się wydzielić warstwy. Kod źródłowy systemu Linux to prawie 1GB (gdyby ktoś chciał to wydrukować, zużyłby kilka tysięcy ryz papieru). Kod napisany jest bez określenia właściwości procesora. Dostosowanie do jednego z typów procesora (na przykład Intel x86, a więc komputera PC) to około 1% całości. Pozostałe 99% służy współpracy z resztą sprzętu (niektórzy być może będą zaskoczeni, jak mało uwagi system poświęca samej krzemowej maszynie Turinga). Reszta oprogramowania, poza kernelem, w ogóle nie ma kontaktu z “warstwą fizykalną”. A ta reszta ma objętość tysiące razy większą od kodu jądra.

            • Paweł Stacewicz pisze:

              Jaka jest zatem ostateczna sugestia informatyka-praktyka co do uzupełnienia, rozszerzenia, zmodyfikowania etc… dyskutowanego schematu autorstwa G.P. Troszkę się w tym pogubiłem, a takie zwięzłe podsumowanie zgłoszonych zastrzeżeń byłoby dla czytelników bloga ciekawe. Najlepiej zrobić to na głównym poziomie — bo tutaj, w ciągu kolejnych odpowiedzi, kończy się już miejsce…

              • Jarek pisze:

                Przestrzeń na na kolejne odpowiedzi powiększyłem, choć ze sprawami ostatecznymi udałem się we wskazane mi miejsce.

  3. km pisze:

    Nie wiem czy stwierdzenie ‘ładunek elektryczny jest kontrolowany przez kod maszynowy’ kryje wiele większe uproszczenie (jest mniej typowe dla Informatycznego ujęcia) niż (typowe dla Fizyków twierdzenie) że ‘rozkład ładunku jest wynikiem oddziaływań fizycznych (np. zmian pola)’?
    Prawa” fizyki odpowiadające o oddziaływaniach stojących za manifestacjami rzeczywistych fenomenów także stanowią zdaje się struktury językowe – mające regularnie korespondować z w/w manifestacjami/ ich pomiatami- pewnie w podobnie trans-ontologiczny sposób jak określone “zapisy” kodu maszynowego korespondują z ładunkiem w ujęciu Informatyka?
    Chyba że dodatkowe warstwy mają wynikać z granicy dyscyplin opisujących realne fenomen w swych strukturach językowych (Fizyka vs Informatyka).

    Nie wiem też czy to interesujące z Informatycznego punktu widzenia, ale dla mnie szczególnie ciekawe byłoby to jak wyglądałby podobny schemat “po drugiej stronie intencji”. A w szczególności jak wyglądało by “przejście” i co łączyłoby się z intencją – ile wzajemnie nieprzetłumaczalnych procesów by się na nią składało? Czy wszystkie dałoby się opisać jasno odpowiednikiem języków programowania czy cześć w rozproszonym uwikłaniu wątków pozostałaby nieredukowalna do innego opisu niż:
    -z jednej strony znaczące i (świadomie odczuwane) ‘przeświadczenie’, ‘intuicja’, ’emocja’
    -z drugiej równolegle i w rozproszeniu przetwarzające systemy i struktury neuronalne (każde sterowane własnym “kodem maszynowym”)

    • Paweł Stacewicz pisze:

      Wydaje mi się, że takie schematy jak analizowany wyżej mają właśnie wyjaśnić, jak to się dzieje, że pewne cząstkowe (ukierunkowane zadaniowo, czyli na rozwiązanie konkretnego problemu) intencje mogą być automatycznie, w sposób wielokrotnie powtarzalny, realizowane na zewnątrz ludzkiego umysłu, przez fizyczne automaty (fizyczne choć niekoniecznie biologiczne).

      Wydaje mi się też, że przedstawiony schemat — jako wysoce abstrakcyjny (zob. też komentarz G. Primiero) — nie eliminuje sprzętowych architektur równoległych i rozproszonych, własciwych sztucznym sieciom neuronowym.

      Rozumiem jednak, że w powyższym komentarzu chodzi o coś więcej… A mianowicie o to, jak w ogóle taka a taka intencja dochodzi do głosu, a potem do skutku…?
      Jak w umyśle pojawia się (interesujący dla KOGOŚ) problem, a potem ogólny zarys jego rozwiązania…?
      Mówiąc językiem filozofii nauki, chodziłoby zatem bardziej o kontekst odkrywania, niż kontekst wyjaśniania (wyjaśniania tego jak już sformułowane przez umysł zadanie można powierzyć maszynie do realizacji).
      I tutaj chyba k-m wątpi w możliwość wytworzenia efektywnego, a przede wszystkim intersubiektywnie dostępnego (z grubsza: nieprywatnego), kodu który sprawiałby, że maszyna żywi autentyczną intencję…

      Czy dobrze zinterpretowałem intencję powyższego komentarza?

      Przy okazji chciałbym zapowiedzieć dłuższy wpis k-ma, w którym podejmiemy podobną tematykę.
      Zamieszczę go w blogu już niebawem…

      • km pisze:

        Chodziło mi (w drugiej części komentarza) o to jak wyglądałby podobny schemat przedstawiający sposób w jaki „fizyczne automaty” (w tym przypadku biologiczne komórki) działając w określonych okolicznościach automatycznie i z koniecznością, generują „w rezultacie” ową „Intencję” (jakie „warstwy” pośrednie można by wydzielić).
        – To osobny „wielki” problem, ale i z analizy tego tematu i tej dyskusji wyłaniają się pewne kwestie dla niego znaczące:
        W komentarzu Jarka (który równolegle do mojego pojawił się na blogu) przedstawiona została – zgodna z częścią intencji mego komentarza – analiza związana z „rozsądnym czasem” zależnym od różnych technologi wykonywania rozkazów, kończąca się stwierdzeniem:
        „od sprzętu zależy więcej, niż się u zarania informatyki teoretycznej wydawało”.
        Z „rozsądnym czasem” wiąże się możliwość pojęcia/zrozumienia (tego dlaczego przetwarzanie określonych danych przez poszczególne technologie daje takie a nie inne rezultaty) i możliwości ich „praktycznego” tłumaczenia pomiędzy systemami opartymi o różne technologie.
        Kod sterujący zachowaniem poszczególnych elementów tworzących strukturę przetwarzającą dane może być jasno określony – a jednak przedstawienie zawikłanych uwarunkowań układów działających „inaczej niż przez sekwencyjne wykonywanie rozkazów” może nie być możliwe w „rozsądnym czasie” i w dający się „ogarnąć”/zrozumieć sposób.

        ‘Intencja’ może się w maszynie pojawić (tak jak w biologicznej maszynie ludzkiego Umysłu) ale jej przedstawienie nie będzie się zawsze dało przedstawić ( w „rozsądnym czasie” i w dający się „ogarnąć”/zrozumieć sposób) w szeregu logicznych inferencji.
        „Znaczenie” dla maszyny określonych danych – w rozumieniu tego co ma wobec nich zrobić – nie będzie możliwe do jasnego wyłożenia w szeregu (instrukcji „w wypadku A wykonaj B”) „do ogarnięcia w rozsądnym czasie”, stając się „nietransparentna poznawczo”. To już się dzieje gdy nie wiemy dlaczego systemy oparte na technologii deep learning potrafią robić to co robią, czy czemu z analizy danych z Wielkiego Zderzacza Hadronów komputery wskazują określone „okoliczności” do poszukiwania nowych cząstek.
        Jeśli to ma miejsce w wypadku sztucznych sieci neuronowych, to tym bardziej można się tego spodziewać w odniesieniu do (o wiele bardziej skomplikowanych) systemów neuronalnych ludzkich mózgów:
        „od sprzętu zależy więcej”, niż się teoretykom starającym się redukować rozumienie znaczeń pojęć do definicji znaczeniowych i relacji logicznych formuł wydawało.
        Nad Intencją ( i rozumieniem znaczeń danych) w maszynie możemy mieć kontrolę coraz częściej i wyraźniej „iteracyjną” – bo poprzez metodę prób i błędów.

        Może się także zdarzyć, że „wydobywać informację” o badanych zjawiskach Rzeczywistości będziemy mogli (w „rozsądnym czasie”) jedynie poprzez informatyczne modele tych fenomenów o stosownej/odpowiedniej architekturze:
        Leonard Susskind (ten od teorii strun) spytany o to jakie widzi (jako starający się zrozumieć Rzeczywistość Fizyk) zastosowania dla komputerów kwantowych odpowiedział, że „modelowanie samych zjawisk kwantowych” bo teoretycznie „zwykły komputer jest w stanie zasymulować ich działanie (policzyć wartość funkcji falowej) ale w 400 spinach (qbit’ach) może być więcej informacji niż da się zmieścić – przy upakowaniu tak gęstym jak tylko potrafimy – w całym (obserwowalnym) Wszechświecie”.
        – zgodnie z Intencją „zrozumienia” będziemy mogli otrzymać „z modelu” informację co mamy zrobić aby otrzymać w Rzeczywistości określony rezultat, ale jednocześnie zjawisko (i jego cyfrowy model) pozostanie dla nas „kompletnie” niezrozumiałe.

        • Jarek pisze:

          Przedstawienie zawikłanych uwarunkowań układów działających „inaczej niż przez sekwencyjne wykonywanie rozkazów” może nie być możliwe w „rozsądnym czasie” i w dający się „ogarnąć”/zrozumieć sposób.

          Może, ale bywa też, że jest odwrotnie. Warto przypomnieć takie kamienie milowe w historii rozwoju sprzętu:

          1. W programie budowy pierwszego brytyjskiego komputera (Colossus) uczestniczy Alan Turing. Trudno się zatem dziwić, że architektura realnej maszyny była bardzo zbliżona do znanego nam wszystkim modelu teoretycznego. W szczególności nie było tam adresowanej pamięci RAM, a jedynie sekwencyjny zapis danych na taśmie. Opis maszyny Turinga ładnie i klarownie wygląda na papierze, ale gdy przychodzi do napisnia realnego programu, okazuje się, że kod jest
          nieczytelny i trudny do ogarnięcia przez człowieka. Późniejsze komputery, z pamięcią umożliwiającą wykonywanie skoków, pozwoliły na użycie kodu, który da się w zrozumiały sposób opisać w rozsądnym czasie. Ale te komputery muszą potrafić trochę więcej, niż sekwencyjne wykonywanie rozkazów z taśmy.

          2. Dla komputera zbudowanego z bramek logicznych liczby są abstrakcją (było o tym rok temu). O ile dodawanie (arytmetyczne) jest tożsame z operacją logiczną i względnie łatwo da się je prowadzić na rejestrach maszyny, to już na przykład z mnożeniem tak nie jest. Pomnożenie czy podzielenie liczb reprezentowanych przez ciąg bitów wymaga więc wykonania sekwencji rozkazów zajmujących wiele cykli procesora. Powstały więc koprocesory arytmetyczne, które nie dość, że tak złożoną czynność wykonują w jednym cyklu maszyny, to jeszcze sprawiają, że kod programu staje się bardziej zrozumiały.

          3. Kryptografia posiłkuje się złożonymi algorytmami (cząstkowymi), takimi jak liczenie funkcji skrótu SHA1, SHA256 i innych. Procesorowi zaprojektowanemu do zastosowań ogólnych zajmuje to sporo czasu i angażuje dużo jego zasobów. Ponieważ kryptografia jest dzisiaj niezbędna niemal wszędzie (np. urządzenia mobilne, smartfony), to procesory mają sprzętowe wsparcie tych funkcji. Wewnętrzne układy działają inaczej niż tylko sekwencyjnie, robią to o wiele szybciej niż sam procesor. Funkcje te są dobrze zdefiniowane i tak często wykorzystywane, że warto było włożyć enegrię w zaprojektowanie hardware.

          4. Przyszłość komputerów kwantowych jest niejasna, nie do końca wiadomo, czego się po nich można spodziewać. Jedną z tych rzeczy być może jest faktoryzacja dużych liczb szybko realizowana w sposób “elementarny”, jak operacje logiczne w bramkach. Może więc kiedyś powstanie “koprocesor kwantowy”, który realizuje to i tylko to? Użycie takiego koprocesora nie wpłynęłoby na czytelność istniejących programów. Ale to jest przyszłość. Być może jest.

          • km pisze:

            Ogólnie bywa odwrotnie- tj z analizy zawiłości zjawiska/problemu człowiek (programista) wyłoniwszy w abstrakcji regularności/prawidła, może (np. w językach programowania) zrozumieć i zaprojektować rozwiązanie (interpretacja danych pozwala intencjonalnie wybrać co należy zrobić).
            Ostatnio jednak coraz częściej słychać właśnie o zjawisku wyłaniania się swoistych abstrakcji/ czy odnalezieniu regularności w danych poza rozumem programisty – właśnie w równolegle i w rozproszeniu (nawet jeśli wirtualnym/symulowanym) interpretujących (na niezrozumiałe dla ludzi sposoby) dane układach. Rozum ze swym logicznym aparatem i zrozumieniem nie może wymyślić lepszego (w danej specjalności) systemu niż alphaGo – to systemy symulowanych sieci neuronowych na nowy/swój sposób “rozumieją” dane. Co więcej takie systemy jak Transformer-XL wprowadzają dodatkową “automatyzację” oddzielającą ludzkie pojęcie i intencje od dokonujących się w wytworzonych modelach abstrakcji. Być może to jest swoista granica- i możliwy nowy podział poziomów abstrakcji: to co w sposób zrozumiały prowadzi do realizacji intencji i to co “się” realizuje w abstrakcji od ludzkiego rozumienia?

      • Jarek pisze:

        “Sprzętowe architektury równoległe i rozproszone, właściwe sztucznym sieciom neuronowym”.

        Trudno mi się powstrzymać od kolejnego komentarza. “Sztuczne sieci neuronowe” mają teorię niemal tak starą, jak maszyna Turinga. Można powiedzieć, że to teoria konkurencyjna, a przynajmniej równoległa. Próbowano ją realizować w praktyce jeszcze przed rozwojem technik komputerowych, ale dopiero maszyna cyfrowa umożliwiła sensowne symulacje. Nie ma to jednak wiele wspólnego z “architekturami równoległymi i rozproszonymi”. Bardzo długo jedynym dostępnym sprzętem był pojedynczy komputer z jednowątkowym CPU, co nie przeszkadzało w implementacji sieci neuronowych (pisząc te słowa patrzę na sąsiednie biurko, gdzie leżą urządzenia z malutkim mikroprocesorem, przez długie miesiące zasilanym z akumulatora, realizujące analizę sygnałów w oparciu o sieci neuronowe).

        Wniosek z tego płynie taki, że jeśli ktoś docenia wagę teorii sztucznych sieci neuronowych, powinien również docenić moc tkwiącą w językach opisu (językach programowania). To one, a nie specyficzna architektura sprzętowa umożliwia zastosowanie tej teorii w praktyce.

        • km pisze:

          Symulowanie sieci neuronowych ma tyle wspólnego z architekturą równoległą i rozproszoną, że stanowi jej “wirtualny” cyfrowy model. To prawda, że to języki programowania umożliwiając zastosowanie w/w teorii w praktyce. Pozwoliły unaocznić, że czasem sposób realizacji intencji najbardziej korzystny z punktu widzenia “rozsądnego czasu realizacji” (lub jedyny na jaki w ogóle stać było Programistów) dokonuje się w wielowątkowej “formalizacji” wirtualnego modelu. A to, że dają się uruchomić na malutkim mikroprocesorze nie sprawia, że Programiści są w stanie zrozumieć (Przedstawić inaczej niż poprzez symulację w/w technik) to jak się realizują i na czym polegają abstrakcje pozwalające takim technologiom czynić to co czynią.

  4. FPGA pisze:

    Według mnie najważniejszym poziomem abstrakcji zawsze pozostaje najwyższy, czyli poziom intencji rozwiązania problemu, nawet w kontekście informatyki.

    Choć problem jest oderwany od realizacji, a więc od niższych poziomów, to jednak jest najważniejszym (właściwie jedynym) kryterium oceniającym produktów rozumowania na niższym poziomie, ponieważ nawet najlepszy algorytm nie zda się na nic jeśli jego wynikiem są poprawne dane wyjściowe tylko dla jakiegoś (niepełnego) podzbioru możliwych danych wejściowych.

    Ponadto to właśnie problem definiuje dobór aspektów jego rozwiązania – algorytm, język programowania w którym zostanie zaimplementowany, procesor na którym ten program zostanie wykonany, te wszystkie rzeczy mogą się zmienić, ale ostatecznym wynikiem zawsze musi być rozwiązanie danego problemu.

    Sama użyteczność wydzielenia różnych poziomów abstrakcji jest niezaprzeczalna, ale podział ten może okazać się niebezpieczny. Jak napisał ms, “Zupełnie czym innym jest pisanie algorytmu oraz jego implementacji”. Takie stwierdzenie może być prawdziwe, ale według mnie zdecydowanie nie powinno być, to znaczy projektowanie algorytmów jako abstrakcyjnych tworów rozwiązujących równie abstrakcyjne problemy często prowadzi do rozwiązań działających dobrze również tylko w teorii. Algorytm powinien być tworzony przy uwzględnieniu dostępnych środków i narzędzi, czyli z uwzględnieniem implementacji.

    Podpierając poprzedni akapit przykładem oraz znowu odnosząc się do omawianego pięciopoziomowego podziału chciałbym zwrócić uwagę na układy logiki programowalnej (np. FPGA) oraz w ogólności na rozwiązania sprzętowe, które jak najbardziej pozostając w obrębie przetwarzania cyfrowego wymagają innego myślenia (już na poziomie algorytmu) niż zwykłe systemy procesorowe. Co ciekawe, mogą one zastąpić warstwę kodu maszynowego właściwie bez zbytniej ingerencji w inne warstwy, chyba, że chcielibyśmy silnie odróżnić języki opisu sprzętu od języków programowania. Oczywiście tego typu układy są dobre do rozwiązywania innego typu problemów niż zwykłe programy, jak wspomniał Jarek: “Ale stają się one rozwiązywalne, gdy używamy (dodatkowo) układów elektronicznych działających inaczej niż przez sekwencyjne wykonywanie rozkazów.”. Odmienność ale i popularność tego innego typu problemów równolegle ze zwykłymi, dobrze rozwiązalnymi programowo potwiedza to, że w sprzedaży występują układy scalone łączące na jednym krzemie FPGA i zwykłe rdzenie procesorowe (np. Seria Zynq od Xilinxa lub Agilex od Altery/Intela). Warto też wspomnieć o istnieniu procesorów sygnałowych (DSP), które mimo, że oparte są o “sekwencyjne wykonywanie rozkazów” są dostosowane do konkretnej klasy problemów przez zawarcie bloków sprzętowych rozwiązujących podproblemy typowo w nich spotykane.

    Reasumując, uważam, że nie ważne w jakiej warstwie abstrakcji operujemy ważne jest, żeby mieć na uwadze problem do którego rozwiązania dążymy oraz, niestety, trzeba mieć z tyłu głowy co dzieje się w innych warstwach abstrakcji.

    • Paweł Stacewicz pisze:

      — Jak napisał ms, „Zupełnie czym innym jest pisanie algorytmu oraz jego implementacji”. Takie stwierdzenie może być prawdziwe, ale według mnie zdecydowanie nie powinno być…

      Zaciekawiło mnie to.
      FPGA sugeruje, moim zdaniem słusznie, że tworzenie algorytmu nie powinno być zawieszone w implementacyjnej próżni, lecz silnie powiązane z możliwościami środowiska programistycznego i sprzętowego.
      Chciałbym zwrócić uwagę również na odwrotny kierunek tej zależności…

      Choć nie jestem programistą-praktykiem, to przemawia do mnie silnie zasada – wpajana nam niegdyś na studiach – że zanim przystąpi się do pisania konkretnego programu (implementacji) należy stworzyć przejrzysty algorytm, albo zrozumieć dobrze sens algorytmu, który już istnieje. A zatem: pisanie implementacji powinno być silnie sprzężone z napisaniem/zrozumieniem implementowanego algorytmu.
      A wracając do tematu informacyjnych/programistycznych warstw, to znowu byłby pewien argument za scaleniem warstw pośrednich (k. maszynowy, program, algorytm) w jedną programistyczną warstwę.

      I druga ciekawa kwestia z komentarza FPGA: czy powinniśmy tworzyć “abstrakcyjne” algorytmy, które działają dobrze tylko w teorii?
      Ja uważam, że jak najbardziej.
      Za x lat bowiem technologia może “dociągnąć” do naszej teorii. Nawet takiej teorii, która zakłada istnienie obliczeń innego typu niż turingowskie (czyli opisane za pomocą modelu uniw. maszyny Turinga).

  5. Michał Ryszka pisze:

    1) Moim zdaniem obecnie najistotniejsza jest warstwa algorytmiczna i intencyjna, ponieważ zakładając że realizacja pozostałych warstw jest prawidłowa to ich zadaniem jest realizowanie pomysłów projektanta, jest to rola komputera. Warstwy algorytmiczna i intencyjna pozwalają na tworzenie nowych rozwiązań, funkcjonalności są miejscem „pracy kreatywnej” a pozostałe są „prostymi narzędziami”.
    2) Myślę że nie powinniśmy łączyć mimo wszystko warstw, ponieważ każda ma inna budowę, do obsługi, ulepszania każdej wymagana jest inna wiedza stąd nie łączyłbym ich.
    3) Algorytm obecnie jest najistotniejszą częścią ponieważ pozwala na przetwarzanie informacji, filtrowanie informacji na przydatne i nieprzydatne. Stąd uważam że algorytm jest ważniejszy, ponieważ żeby informacja była cenna musi mieć dla nas wartość, posiadanie informacji nie przydatnych nas nie wzbogaci itp.
    4) Wydaję mi się że większy podział nie jest konieczny. Model matematyczny i tak będzie stworzony w jakimś języku programowania stąd może się znaleźć w tej warstwie np.

  6. Giuseppe Primiero pisze:

    Hi everyone,
    Thanks for taking the time to discuss my work. I have read your comments through the rough Google translation, which at least gave me the opportunity to see what you are focusing on.
    I am indebted to you all for the serious comments and for the criticisms, which are always useful. I just want to take the opportunity to make few very brief comments:

    1. The schema of Levels of Abstraction is, obviously, an abstraction itself, and as such leaves away many details of the practice of the work of computer scientists and IT engineers. Note, however, that I consider all the layers essential parts of the ontology of computational systems.

    2. The reason for my claim in 1. and why I believe that all LoAs need to be seen in connection is the overarching problem of correctness: If one is interested in knowing when a computational artifact satisfies its intended specification, then one needs to consider all such levels.

    3. The LoAs scheme abstracts away from specifics of which design method, programming language or architecture is used, but it is still applicable for any such different choice.

    4. While I agree that the intention level is strictly speaking outside the realm of computer science, I agree that it is as essential as the algorithmic level.

    • Paweł Stacewicz pisze:

      Thank you very much Giuseppe for your explanations.

      I will explain on my side that, as the initiator and moderator of the discussion, I have specially focused it on general issues (information in computational aspect), because I think that regardless of the issue of correctness (of computational artifacts) your text gives a very general insight into the concept of computation and information (data).

      During yesterday’s live discussion with the students, an interesting issue arose — concerning the physical layer of computations (on your scheme it is more specifically expressed: electric charge).
      Well, although we can treat this layer very abstractly, its concretisation is strongly connected with the choice of mathematical model of computation. For example the model of analog computation requires the use of other physical processes than the model of digital (Turing’s) computation; similarly it is in case of the model of quantum computation…

      Taking such a connection into account would be some way to include into presented scheme a model of computation (now it is out of the scheme).
      Of course the matter requires further thoughts…

    • Conceptualist pisze:

      Dear Giuseppe,

      You are completely right saying that your “Model of Abstraction” is – using my own abbreviations – sufficiently abstract and necessary as it concerns the realm of situations (actions) similar to programming. As a matter of fact and more generally, it also concerns every process of human interaction (1. perception/action and 2. communication using all kinds of codes and languages). Indeed, the reason why, personally, I highly appreciate this model of programming is that it is revelatory with respect to the overall capacity of interactive information processing by humans. My recent views on the conceptual model of human interaction bring closer than ever before (though avoiding confusion) Semiosis to Cognition (Noesis). However, programming languages – unlike the natural ones – have no semiotic nature mostly because there is no room left for partiality (ambiguity) within coding practices.

      By the way, as everyone knows, interacting with computers implies 2 moods: the programmer’s mood and the one of the user. The Programmer’s task consists of simulating both the computer’s party and the user’s party in their mutual interaction. But for our purposes, this distinction, although important in all other cases, can be omitted here owing to the fact that the programmer also uses programming languages in his interaction with the core of the machine.
      Let me focus now on the layered nature of your model. If you allow me to operate two changes, you will get a three-layer system which renders well the idea of the DIK (data-information-knowledge) hierarchy. (Indeed, the „electric charge” level can be seen as a 0-level.)

      level 1: language —> data
      level 2: algorithm —> information
      level 3: intention —> knowledge

      The DIK Pyramid is comparable to what is known in brain science as “association areas” of perception/action and in my theoretical effort as “three-layered structure of knowledge” acquisition/utilisation. (Please note however that the “three-tier structure of information” sits in the middle of DIK). Let me mention also the proposal I made at Dresden a few years ago to the FCA Community to treat their research domain as the middle of DIK together with RST (and Decision Logic) as data, and with Information Flow Logic (and Distributed Nets) as Knowledge.

      André

      Image

  7. Iga Pawlak pisze:

    1) Uważam, że nie jest możliwe wyodrębnienie jednej najważniejszej warstwy, jednak za najbardziej istotne, czy wręcz niezbędne dla informatyki uważam najniższą oraz dwie najwyższe. Prąd elektryczny jest podstawą funkcjonowania każdej maszyny i niezbędny do wykonania jakiejś akcji (jak zaznaczone na diagramie), a oczywistym jest, że bez wykonywania żadnych czynności nie możemy mówić o rozwiązywaniu problemów, czy przetwarzaniu informacji. Najwyższe warstwy określają natomiast cel naszych działań, oraz sposób jego osiągnięcia.
    2) Najbardziej istotne są warstwy wspomniane w pytaniu 1. Pewne zadania jesteśmy w stanie zrealizować czysto „sprzętowo”, dlatego ani język programowania, ani kod maszynowy nie są niezbędne do przetwarzania informacji. Te dwie warstwy faktycznie można połączyć w jedną, języki programowania są w końcu jedynie innym sposobem zapisu, bardziej przystępnym dla ludzi, ale ostatecznie przetwarzanym na kod maszynowy. Nie łączyłabym ich jednak z warstwą algorytmu, gdyż pojęcie to nie jest nierozłączne programowaniem w takim rozumieniu.
    3) Przedstawiony punkt widzenia zbliża do siebie pojęcie informacji i algorytmu. Jednak w moim odczuciu, można to zbliżenie dwojako interpretować – utożsamiając informację z czymś algorytmicznym, bądź też uznając algorytm za pewnego rodzaju zbiór informacji. Jeśli zapisujemy algorytm w formie instrukcji, w pewien sposób przekazujemy maszynie informację, jaką czynność i na jakich danych ma w tym momencie wykonać. Polecenie również możemy uznać za pewnego rodzaju informację.

  8. Jarek pisze:

    Informatycy-praktycy od czterdziestu lat zżyci są z modelem ISO OSI (Open Systems Interconnection). Było to moje pierwsze skojarzenie po obejrzeniu rysunku w blogonotce. Podobny do niego schemat można obejrzeć na przykład tu: https://pl.wikipedia.org/wiki/Model_OSI

    Jeżeli ktoś nie tylko obejrzy rysunek, ale również przeczyta tekst (zachęcam!), to dowie się, że model OSI opisuje „systemy sieciowe”. Tymczasem notka jest o „informacji w ujęciu obliczeniowym”. Ktoś może w tej chwili zrywa się z krzesła, by wytknąć mi pisanie nie na temat, proszę jednak o chwilę cierpliwości. Informatycy-praktycy dawno porzucili myśl, że „w ujęciu obliczeniowym” da się cokolwiek sensownego zrobić z informacją, mając do dyspozycji pojedynczy komputer.

    Tego mi w proponowanym modelu brakuje — interakcji między autonomicznymi jednostkami. Neurony naszych mózgów od lat intrygują badaczy różnych dyscyplin naukowych. Niewiele wiemy o ich działaniu, ale pewne jest to, że w ciągu życia wciąż ich w mózgu ubywa, nie powstaje żaden nowy. Za to cały czas wytwarzają się połączenia między nimi — to zjawisko kojarzymy z procesem nabywania wiedzy i umiejętności przez człowieka.

    W świecie cyfrowym jest podobnie. Rozwój samych komputerów mocno zwolnił, za to coraz więcej zależy od połączeń między nimi i od wzajemnych powiązań odbywających się w nich niezależnych procesów. Czy to tylko powierzchowne podobieństwo sieci komputerowej do mózgu, czy jest w tym głębsza analogia? To temat dobry do filozoficznych rozważań.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *