On Tuesday, August 29, 2017 at 3:26:48 PM UTC+2, g...@g...com wrote:
> W dniu poniedziałek, 28 sierpnia 2017 18:39:17 UTC+2 użytkownik M.M. napisał:
>
> > > No właśnie, i moim zdaniem to programy komputerowe powinny
> > > z automatu testować wszystko -- formułować różne "hipotezy"
> > > i dokonywać pomiarów.
> >
> > Czyli programować w języku myślenia oznacza coś w rodzaju, żeby
> > programować komputery, może z wykształceniem matematycznym, ale na
> > pewno bez informatycznego. Hmmm idea fajna, a jak z tym jest w
> > praktyce? Podajesz linki do swoich sukcesów, może w praktyce to
> > jest bardziej możliwe niż mi się wydaje?
>
> Nie wiem, czy to, co zrobiłem, można nazwać "sukcesami".

Podałeś programy które były zwarte, przejrzyste i umiały
rozwiązać jakieś problemy. Jest to argument za tym, że
można w jakimś stopniu osiągnąć, do czego miałem wątpliwości.
Oczywiście jest to sukces w jakimś stopniu, następnym
stopniem byłby język jeszcze bardziej wysokopoziomowy.

> Raczej określiłbym to mianem szkiców, ale owszem takie podejście
> jest możliwe. Pewnie tak naprawdę największym problemem nie
> jest nawet brak narzędzi, tylko sztywność ludzkiego myślenia
> (którą moim zdaniem takie języki jak C++ tylko cementują).
Próbuję rozluźnić swoje myślenie, ale to chyba nie o to chodzi :)
Raczej chodzi o odwalenie bardzo ciężkiej roboty. Robota ta
sprowadzałaby się do zaprojektowania nowego, bardzo wysokopoziomowego
języka programowania i narzędzi, przynajmniej efektywnego kompilatora.


> > > Jeżeli idzie o mnie, to kiedy zacząłem się uczyć Scheme'u,
> > > studiując "Strukturę i Interpretację Programów Komputerowych",
> > > kilka lat zajęło mi oduczenie się wszystkich nawyków, które
> > > przyniosłem z C i C++.
> > Czy możesz powiedzieć uczciwie, co zyskałeś na tym, a co straciłeś?
>
> Nie wydaje mi się, żebyśmy -- ucząc się nowych rzeczy -- coś tracili.
I oczywiście nie pytałem o to co straciłeś przez naukę, chociaż też
się traci, zawsze jest chociażby koszt alternatywny. Dzięki temu
że pozbyłeś się nawyków z C++, a nabraleś nowych, możesz zapewne jedne
zadania rozwiązywać (w jakimś sensie) lepiej, a inne gorzej. Pytałem o
jakiś przegląd takich zadań.


> Jeżeli idzie o to, co zyskałem, to przede wszystkim właśnie zdolność
> do patrzenia na programowanie jako na "esencję myśli", choć
> pewnie nie brzmi to zbyt zrozumiale w oderwaniu od konkretnych
> przykładów.
Już wyjaśniliśmy co to znaczy, chodzi po prostu o opis algorytmów w
bardziej naturalnym a mniej formalnym języku, chodzi o język
programowania bardzo wysokiego poziomu.

> > > Zależy, co rozumiesz przez "sztuczną inteligencję",
> > > ale historycznie rzecz biorąc jakieś bardziej dojrzałe
> > > systemy sztucznej inteligencji mamy co najmniej od
> > > lat 80.
> > Miałem na myśli system, który z dużym prawdopodobieństwem
> > odgadnie cel jaki programista chce zrealizować.
>
> Ale dlaczego system miałby cokolwiek odgadywać? Dlaczego
> programista nie miałby wprost wyrażać tego, co chce osiągnąć?

Nie chodziło mi o takie odgadywanie, jak pokerzysta odgaduje
karty przeciwnika. Raczej chodziło mi o to co opisałem jak
rozumiem sztuczną inteligencję na potrzeby naszej rozmowy.
Chodziło o to, aby kompilator ustalił jaki algorytm realizuje
wpisany kod przez programistę, następnie aby kompilator odszukał
zbioru równoważnych algorytmów i zaproponował kilka najlepszych
algorytmów z tego zbioru. Programista mógłby wprost podawać
zakresy danych, wartości, rozmiary danych w trakcie profilowania.

Słowa "odgadywać" użyłem tylko dlatego, że nie znam algorytmu
który dany kod klasyfikuje do zbioru algorytmów.

> Tym zresztą wydaje mi się programowanie w swojej istocie:
> praktyką mającą rozjaśnić zdolność formułowania myśli.
Dla inżyniera "zaprogramować" znaczy "zrozumieć". Języki
programowania są bardzo jednoznaczne. Jeśli potrafimy
napisać program który rozwiązuje jakiś problem, to jednoznacznie
możemy stwierdzić, że rozumiem ten problem. Więc jest
dużo prawdy w tym co mówisz, bez względu na użyty
język programowania.

Co jednak, gdy do danego problemu używamy sieci neuronowej
mającej 60mln wag? Tego żaden geniusz nie zrozumie :)



> > Przy odgadywaniu
> > jedynie może opierać się na analizie meta-kodu i jakiś dodatkowych
> > skąpych wskazówek, np. może zadać pytania tylko do sytuacji
> > dwuznacznych. Następnie wygeneruje sub-optymalny kod w C, z
> > wariantami dostosowanymi do różnych rozmiarów/rozkładów
> > danych wejściowych.
>
> Ciekawostka -- William Byrd pracuje nad edytorem "Barliman",
> który jest zdolny do czegoś w tym rodzaju. W zeszłym roku
> miał na ten temat interesującą prezentację (tyle że pokazywał
> na raczej prostych przykładach):
>
> https://www.youtube.com/watch?v=er_lLvkklsk
Będę musiał spojrzeć.



> > > A one miały jakieś tytuły?
> > Tak, nie wszystkie mam do dziś w biblioteczce, niektóre wydałem,
> > zgubiłem, miałem pożyczone. Miałem ze 20 sztuk tego, począwszy
> > od C++ do idiotów, skończywszy na Lippmanie i Stroustrupie.
> > Dlaczego dopytujesz o konkretne tytuły? Teraz mam, licząc z
> > daleka i patrząc słabym wzrokiem, 13 tytułów na półce.
>
> Pytam z ciekawości. Czasem zdarza mi się oglądać prezentacje
> Suttera i Meyersa (który -- jak wspominałem -- odwrócił się
> ostatnio od C++ w stronę D)
Z ciekawszych to Lippman "model obiektu w C++" i Stroustrap "projektowanie i
rozwój języka C++". Bieleckiego tytułu nie pamiętam, a już nie mam jej
na swojej półce.


> > > Jedyny sposób, żeby się przekonać, to sprawdzić.
> > Trochę sprawdzałem w Javie.
>
> Wydaje mi się, że warto spróbować np. Haskella, bo on jednak
> produkuje natywny kod, a leniwa ewaluacja potrafi niekiedy
> drastycznie ograniczyć zużycie ramu (a innym razem wręcz przeciwnie,
> ale to inna historia)
Ok.


> > > Sztucznej inteligencji jest dość sporo. I nie mam na myśli
> > > jakichś systemów deep-learningowych, które naśladują działanie
> > > ludzkiego mózgu (i czasem robią naprawdę imponujące rzeczy),
> > > ale raczej pomysły w rodzaju superkompilatora Valentina Turchina,
> > > albo systemu Burstalla-Darlingtona do transformacji programów,
> > > albo systemu Boyera-Moore'a do dowodzenia twierdzeń o własnościach
> > > programów. To są rzeczy z lat 80. XX wieku.
> >
> > Ok, ale jeśli podwaliny teoretyczne są takie dobre to dlaczego
> > programy napisane w Pythonie działają nadal wolno? Nikomu nie
> > chce się napisać porządnego kompilatora do Pythona?
>
> Nie wiem. Mi się nie chce, na przykład.
> Swego czasu Peter Norvig zrobił porównanie Pythona do Common Lispa,
> o tutaj; http://norvig.com/python-lisp.html
W tej chwili nie załadowała mi się strona.

>
> > > Czy są jakieś fundamentalne powody, dla których miałoby nie być
> > > możliwe?
> > Nie wiem. To ja pytam. Dlaczego programy napisane w Pythonie są
> > wolne?
>
> Podejrzewam, że to raczej kwestie społeczne, niż technologiczne.
> Ale nie wiem, bo nie siedziałem w Pythonie na tyle głęboko, żeby
> sięgać po narzędzia w rodzaju PyPy -- dla moich potrzeb CPython
> z reguły wystarczył, a większej aplikacji w tym języku raczej
> nie chciałbym pisać, choćby ze względu na brak statycznej kontroli
> typów.
Hmmm czyli jaki język jest najlepszy do pisana dużych aplikacji,
rzędu 30 koderów (plus reszta zespolu) i dwa lata czasu?


> > > Nie jestem pewien. Herbert Simon i Allen Newell robili w IPL naprawdę
> > > imponujące rzeczy, ale raczej nie dałoby się zakochać w tym języku.
> > > Z Javą mam podobne odczucie -- z niektórych prostych rzeczy czyni
> > > rzeczy wymagające sporego wysiłku (pewnie sporo zmieniło wprowadzenie
> > > lambdy w Javie 8 pod tym względem, ale nie powiedziałbym, żeby lambdy
> > > stanowiły kanoniczną część Javy)
> > Mogę jakiś minimalny przykład poprosić, co jest w Javie
> > pracochłonne, a w Scali, Rybym, Pythonie, itd, łatwe?
>
> Na przykład chcesz wygenerować listę trójek pitagorejskich o współczynnikach
mniejszych od 100, i przekazać ją do jakiejś funkcji f.
> W takim np. Haskellu byś napisał
>
> f [(x,y,z) | x <- [1..100], y <- [x..100], z <- [y..100], x^2+y^2==z^2]
>
> w Pythonie byłoby podobnie, choć nieco bardziej rozwlekle (i bez kontroli typów)
>
> f([(x,y,z) for x in range(1,100) for y in range(x,100) for z in range(y,100)
> if x**2 + y**2 == z**2])
>
> A jak by takie coś wyglądało w Javie albo C++?
> Ja sobie wyobrażam mniej więcej coś takiego:
>
> #include <bardzo dużo nagłówków>
>
> List<Tuple<int, int, int> > triples;
> for(int x = 1; x < 100; ++x)
> {
> for(int y = x; y < 100; ++y)
> {
> for(int z = y; z < 100; ++z)
> {
> if(pow(x, 2) + pow(y, 2) == pow(z, 2))
> {
> triples.add(new Tuple<int, int, int>(x, y, z));
> }
> }
> }
> }
> f(triples);

C++ przegrywa na starcie, bo ilość kodu jest większa o konieczność
zdefiniowania funkcji, zmiennych, nazw typu. Zobacz ten kod:
gen( max_d , max , prev, depth, vals[], f_mkVector, f_test ) {
vector v;
if( depth == max_d ) {
if( f_test(vals) )
v = f_mkVector( vals , depth );
} else for( i=prev ; i<max ; i++ ) {
vals[depth] = i;
v += gen( max_d , max , i , depth+1 , vals , f_test );
}
return v;
}

Ma tylko 6 linijek kodu obliczeniowego, reszta to definicje i
deklaracje. Jest mocno sparametryzowany. Może pracować na
dowolnym zakresie zmiennych, na dowolnej głębokości. Można
podać dowolny uchwyt do funkcji testującej i budującej dane
wyjściowe. Hmmm w C++ jest dużo kodu pełniącego rolę informacyjną
dla kompilatora, kodu algorytmicznego nie ma aż tak dużo, a
parametryzowanie wskaźnikami do funkcji, lub obiektami wirtualnym
powoduje, że kod jest bardzo uniwersalny.


Przy tym zadaniu mój "język myślenia" wyglądał tak:
buduj( max_depth, depth, reszta_parametrów ) {
if( max_depth == depth ) {
if( testuj(...) )
return wynik;
}
for( i=0 ; i<max ; i++ )
wynik += buduj( max_depth, depth+1 , ... );
return wynik;
}
Hmmm podobny do kodu algorytmicznego w C++.



> Oczywiście, nawiasów klamrowych można by było nie używać,
> ale wtedy przyszedłby manager i powiedział (słusznie) że takie
> są standardy kodowania w firmie.
Można bylo jeszcze posłużyć się rekurencją. Kodu jest więcej
niż w Pythonie, ale procedura jest uniwersalna, dla różnych
funkcji testujących i budujących wynik.

> Co do Javy to nie wiem, bo nie używałem, ale wyobrażam sobie,
> że podobnie (zresztą to Ty mi powiedz, bo może się mylę)
Bardzo podobnie bym napisał w Javie.

Chyba że dopuszczasz poslużenie się bibliotekami, to jest
http://www.cplusplus.com/reference/algorithm/next_pe
rmutation/
Ale to już nie jest porównanie języków, tylko dostępnych bibliotek.




> > > Jeżeli korzystasz w swoim programie z gotowych kolekcji, które mają
> > > kompatybilne interfejsy, ale różnią się charakterystyką wydajnościową,
> > > to użycie algorytmów genetycznych do optymalizacji rodzajów kolekcji,
> > > z których chcesz korzystać, jest trywialne.
> > Może się nie zrozumieliśmy dlatego, że ja miałem na myśli skompilowany
> > program, a Ty myślisz o skompilowaniu przed testowaniem. Tak, na
> > poziomie kodu źródłowego (koncepcyjnie, niekoniecznie w realizacji)
> > takie zadanie jest trywialne.
>
> No, robienie tego rodzaju rzeczy na skompilowanym kodzie to chyba
> robienie sobie mocno pod górkę?

Zależy jak to jest użyte. Sieczkę templatów przeplatanych ifdefami
można zawsze zrobić ;-)


> > > Ale nie zgadzamy się w kwestii rozumienia pojęcia "sztuczna inteligencja".
> > > Pewnie Ty rozumiesz to pojęcie dosłownie, a ja -- historycznie, [...]
> > Rozumiem dosłownie, ale niekoniecznie w dowolnym obszarze zastosowania.
> > Chodziło mi o AI zdolne do generowania sub-optymalnego kodu na podstawie
> > meta-kodu, albo na podstawie języka bardzo wysokiego poziomu.
>
> Ale do generowania kodu i do opisywania języków mamy bardzo dobre narzędzia.
> Wystarczy spojrzeć sobie np. na taki Inform 7.

Rozmawialiśmy o języku myślenia z kompilatorem generującym
sub-optymalny kod asemblerowym. Nie znam Informu, dałby radę? Jeśli tak, to
czemu python nie ma szybkiego kompilatora?



> > > Pokazywałem ten przykład w swojej magisterce, opisując, w jaki sposób
> > > można stworzyć system reguł, pozwalający przekształcać mniej więcej
> > > tak zapisanego quicksorta w implementację porównywalną wydajnościowo
> > > z C.
> > Czyli zrobiłeś taki początek sztucznej inteligencji jaką miałem
> > na myśli. Mi to imponuje, ale mam też pytanie: jak z przekształcaniem
> > innych algorytmów?
>
> Raczej bym powiedział, że udało mi się przerzucić sznurek przez Wielki Kanion
> (a może nawet przez Nie Taki Wielki Kanion), niż wybudować most.
> Ale też raczej nie nazywałbym tego "sztuczna inteligencją", tylko próbą
> wypracowania metodologii tworzenia wydajnych programów które są też
> łatwe do zrozumienia dla ludzi,

CHyba wiem dlaczego trudno się nam dogadać. Nie zdefiniowaliśmy, co to
oznacza łatwe do zrozumienia dla ludzi. Mnie się C++ na początku wyawał
bardzo robaczywy (czytaj: miał nadmiar operatorów), a potem stał się
przejrzysty. Pojęcie "trudny" już po krótkim treningu może zmienić się
na "łatwy".

Zastanawiam się co się pojawiło w moim umyśle, gdy wymyśliłem nowy
rodzaj sztucznych sieci neuronowych. Hmmmm to nawet nie był metakod.
Chyba pojawił się wykres z przebiegiem funkcji i zarys dowodu, że
to się wyuczy dowolnych danych uczących. A co się pojawialo gdy
wymyśliłem algorytmy do uczenia tych sieci? Zazwyczaj pojawiała się
tylko jedna pętla. Dla mnie taki język programowania jest językiem
myślenia i jest łatwy. Jednak dla innych on będzie nie tylko
trudny, ale nigdy nie będzie zrozumiał, ponieważ mam za sobą
setki godzin przemyśleń i ta jedna pętla w trakcie kodowania skojarzy
mi się z drugą pętlą, a ta druga z setką ifów, o których myślałem
nawet lata temu. Może nie ma czegoś takiego jak łatwy język
programowania w języku myślenia, bo język myślenia jest tylko pozornie
łatwy? W języku myślenia nie musimy ŚWIADOMIE myśleć o każdym
szczególe, ponieważ te szczegóły podpowie nam podświadomość
gdy będą potrzebne. A to że nie myślimy o zawiłych szczegółach w
danej chwili ŚWIADOMIE, nie oznacza że w ogóle nie są one elementem
języka myślenia.

Myślę że ulegamy złudzeniu chcąc zrobić język programowania tak
bardzo przyjazny dla ludzi, aby miał on coś wspólnego z językiem
myślenia. Ulegamy złudzeniu dlatego, że nie jesteśmy świadomi
potężnego mechanizmu kojarzenia jaki zachodzi w naszym umyśle.
Taki język nigdy nie powstanie, chyba że komputer pozna nasze
myśli i skojarzenia.

> a jednocześnie skalowalne i przenośne
> (w przeciwieństwie do C++, który pozwala tworzyć wydajne programy,
> które są potem trudne do zrozumienia i albo nieskalowalne, albo
> nieprzenośne)
Kompilatory C++ są na wiele platform, biblioteki też. A zrównoleglanie w
ogóle bywa trudne, napisz np. optymalnie zrównoleglany algorytm
cięć alpha-beta w dowolnym języku. Zrównoleglanie prostych algorytmów to
jedna linijka dzięki OpenMP. A podobno robią wersję OpenMP na środowisko
rozproszone... Na starym forku też nie tak ciężko się zrównoleglało.



> > > W swojej pracy mam:
> > > - opis składni BNF języka Scheme, składający się z dwóch reguł i kilku
> > > nieformalnych dopowiedzeń
> > > - implementację maszyny wirtualnej, modelującej z grubsza działanie
> > > i zestaw instrukcji typowych procesorów, zaimplementowaną w 200 linijkach
> > > języka Scheme (śmiem twierdzić, że tak czytelnego, jak tylko się da)
> > > - asembler przekształcający kod z etykietami do kodu z ustalonymi
> > > adresami, w 30 linikach
> > > - interpreter języka Scheme w nim samym, w ok. 60 linijkach
> > > - kompilator używanego przeze mnie podzbioru Scheme'u do zestawu rozkazów
> > > powyższej maszyny wirtualnej, zajmujący ok. 300 linijek
> >
> > Wszystko bardzo zwięzłe. 30 linijek, 60, nawet 300 to bardzo mało. Może
> > będę musiał poczytać o Scheme :)
>
> Ciekawostka, o której dowiedziałem się niedawno, to że Alexander Stepanov
> swoją koncepcję iteratorów, przeniesioną potem do STLa, najpierw
> rozwijał właśnie w Scheme:
> http://stepanovpapers.com/schemenotes/notes.pdf
Jestem zaciekawiony tym językiem.


>
> > > co do C++ i Javy, to oczywiście mógłym go używać jako metajęzyka do
> > > opisywania przekształceń, ale nie spodziewałbym się, żebym coś w ten
> > > sposób zyskał, a poza tym nie mógłbym liczyć na to, że wynik mojej
> > > pracy mógłby mieć szansę stosować się sam do siebie (pewnie też dużo
> > > bym stracił na czytelności)
> > Brzmi to bardzo ciekawie.
>
> Jeżeli idzie o "autoaplikatywność", to najciekawszy wynik, jaki znam,
> nosi nazwę "Projekcji Futamury". Zgrabnie opowiedział o tym Tom Stuart:
>
> https://www.youtube.com/watch?v=n_k6O50Nd-4
Ok, dzięki za linka.


Pozdrawiam