🚀 go-pugleaf

On Tue, 24 Apr 2007 07:25:08 +0000 (UTC), "Aleksander Galicki"
<tretete.SKASUJ@gazeta.pl> wrote:

>A co nowego slychac w parallel computing? Przez ostatnie pare lat slychac o 
>nadchodzacej rewolucji, ale na razie nie za bardzo wiadomo z ktorej strony. 

Jak na razie nic, o ile mi wiadomo. W dalszym ciagu najbardziej
popularny jest Fotran oraz MPI czy PVM.

Ja osobiscie uzywam Gigaspaces 

http://gigaspaces.com/pr_overview.html

z dobrym skutkiem oraz w innej aplikacji JCSP

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Wedle mocih najlepszych informacji nei widac zadnej rewolucji. Od czsu
do czasu pojawiaja sie rozne produkty komercyjne do "programowania
roznoleglego nie pzrerywajac snu", ale po dokladniejszym poskrobanoiu
okazuja sie jakims tam opakowaniem Java threads.

"Nie przerywajac snu" okaze sie chyba niemozliwe, albowiem glowna
trudnosc przy programowaniu rownoleglym to "zrownoleglenie" algorytmu
tak aby z rownoleglosci byl jakis zysk. Bardzo latwo "zrownoleglic"
algorytm tak ze na 50 komputerach bedzie dzialal wolniej nie na
jednym.

Ciemno to widze, przynajmniej w USA biorac pod uwage poziom
wyksztalcenia matematyczno/algorytmicznego na przecietnym amerykanskim
uniwersytecie

A.L.

On Tue, 24 Apr 2007 07:25:08 +0000 (UTC), "Aleksander Galicki"
<tretete.SKASUJ@gazeta.pl> wrote:

>A co nowego slychac w parallel computing? Przez ostatnie pare lat slychac o 
>nadchodzacej rewolucji, ale na razie nie za bardzo wiadomo z ktorej strony. 
 

Tak na marginesie, "multicore computers" przynosza nowa jakosc:
programy wielowatkowe dzialajace dobrze na pojedynczym procesorze
pzrestaja dzialac na multicore. Albowiem watki "symulowane" staja sie
watkami rzeczywiscie rownoleglymi, i bledy w synchronizacj staja sie
mniej wybaczalne... Przecietny "ekspert" wyglada wowczas tak jak
spiewano w Kabarecie: "jak piesek co wypadl z san"...

O przeciatnym stanie umyslu "elity" mozna sie przekonac zapuszczajac
google na parallel computing blog. Konkluzje malo optymistycznee, za
wyjatkiem tego ze wiele osob rozpaczliwie proboje sie promowac do
pozycji "guru". Jest to bowiem dziedzina w "hype" dziewicza i jest
wielki szmal do wziecia. Nie mowiac o slawie.


A.L..

Uzytkownik "A.L." <fela@2005.com> napisal:

> Tak na marginesie, "multicore computers" przynosza nowa jakosc:
> programy wielowatkowe dzialajace dobrze na pojedynczym procesorze
> pzrestaja dzialac na multicore.

Skads to znam.
Grozil mi nawet kilka lat temu przez chwile wylot z pracy z w/w
powodu choc bylem jedynie niewinnym "greckim poslancem".

Na tyle greckim ze to w moim (my pechowcy..) tescie nastapil wylot.
Wylot objawiajacy sie tylko na jednej maszynio dwuprocesorowej
i tylko oczywscie czasami chyba gdzies w 345823-1340079 iteracji
i tylk wtedy gdy wiatr wial z azymutu 276stopni a cisnienie nie bylo
wyzsze niz 745hg

A ze byl to ostatni "dokumentujacy" bezblednosc test przed release
to.. sam Pan wie. Zadyma lekka ale jednak :)

PS: firma byla hamerykancka jakby co

AK

On Tue, 24 Apr 2007 14:49:55 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

 
>
>PS: firma byla hamerykancka jakby co
>
>AK
>

Nei dziwie sie ze byla amerykanska. Ja zostalem z amerykanskiej firmy
wylany za uzycie semaforow. Do dzis mam pismo w ramkach na scianie:
"he sugegsted using so-called 'semaphores'. This is well known
academic aberration used mainly for writing conference papers, but
there is no room for such things in serious business environment".

Jak im sie wszystko zawieszalo, to mowili ze maja "bad luck" i
probowali snaczala.

Z tej samej firmy mam papier na temat zakupu dysku SCSI: "SCSI is not
on the list of our preferred vendors"

A.L.

Uzytkownik "A.L." <fela@2005.com> napisal:

> Nei dziwie sie ze byla amerykanska. Ja zostalem z amerykanskiej firmy
> wylany za uzycie semaforow. Do dzis mam pismo w ramkach na scianie:
> "he sugegsted using so-called 'semaphores'. This is well known
> academic aberration used mainly for writing conference papers, but
> there is no room for such things in serious business environment".

Ja p.. ! Nie ! To NIEMOZLIWE :)
Dilbert sie chowa :)

> Z tej samej firmy mam papier na temat zakupu
> dysku SCSI: "SCSI is not on the list of our preferred vendors"

Hihi
Nie no.. dosc.. :)

AK

Witam

A.L. wrote:

> Nei dziwie sie ze byla amerykanska. Ja zostalem z amerykanskiej firmy
> wylany za uzycie semaforow. Do dzis mam pismo w ramkach na scianie:
> "he sugegsted using so-called 'semaphores'. This is well known
> academic aberration used mainly for writing conference papers, but
> there is no room for such things in serious business environment".

A dokładnie teraz Pan ma taką samą postawę. Jeśli ktoś myśli inaczej niż Pan
i ma inną funkcję celu, to Pan takich samych sloganów używa. 

Jak widać, dobrych rzeczy tam Pana nauczyli w USA. Naszczęście nie wszyscy
tak postępują.

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

On Tue, 24 Apr 2007 15:19:49 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

>Uzytkownik "A.L." <fela@2005.com> napisal:
>
>> Nei dziwie sie ze byla amerykanska. Ja zostalem z amerykanskiej firmy
>> wylany za uzycie semaforow. Do dzis mam pismo w ramkach na scianie:
>> "he sugegsted using so-called 'semaphores'. This is well known
>> academic aberration used mainly for writing conference papers, but
>> there is no room for such things in serious business environment".
>
>Ja p.. ! Nie ! To NIEMOZLIWE :)
>Dilbert sie chowa :)
>
>> Z tej samej firmy mam papier na temat zakupu
>> dysku SCSI: "SCSI is not on the list of our preferred vendors"
>
>Hihi
>Nie no.. dosc.. :)
>
>AK
>

Wkrotce potem owa firma padla zreszta, co obserwowalem z satysfakcja.
Glownie przejechali sie zreszta na probie uzycia CORBY, i to wlasnie
przez CORBE sie przejechali. CORBA bowiem nie byla "thread safe"

A.L.

"A.L." <fela@2005.com> wrote:

> O przeciatnym stanie umyslu "elity" mozna sie przekonac zapuszczajac
> google na parallel computing blog. Konkluzje malo optymistycznee, za
> wyjatkiem tego ze wiele osob rozpaczliwie proboje sie promowac do
> pozycji "guru". Jest to bowiem dziedzina w "hype" dziewicza i jest
> wielki szmal do wziecia. Nie mowiac o slawie.

Generalnie prawda. Przy czym sama dziedzina jest wyjatkowo trudna.

http://web.comlab.ox.ac.uk/oucl/work/samson.abramsky/pubsthematic.html

I opowiastka:

" What are the fundamental structures of concurrency? We still don't know!"

Samson Abramsky to jeden z wielkich informatyki teoretycznej.


mp

On Tue, 24 Apr 2007 15:27:10 +0200, Seweryn Habdank-Wojewódzki
<shw_mail@wp.pl> wrote:

>Witam
>
>A.L. wrote:
>
>> Nei dziwie sie ze byla amerykanska. Ja zostalem z amerykanskiej firmy
>> wylany za uzycie semaforow. Do dzis mam pismo w ramkach na scianie:
>> "he sugegsted using so-called 'semaphores'. This is well known
>> academic aberration used mainly for writing conference papers, but
>> there is no room for such things in serious business environment".
>
>A dokładnie teraz Pan ma taką samą postawę. Jeśli ktoś myśli inaczej niż Pan
>i ma inną funkcję celu, to Pan takich samych sloganów używa. 
>
>Jak widać, dobrych rzeczy tam Pana nauczyli w USA. Naszczęście nie wszyscy
>tak postępują.
>
>Pozdrawiam. 

Wie Pan, ja jednak wsadze Pana do KF, bo merytoryczna dyskusja z Panem
jest niemozliwa. A przytyki osobisye mnie nie inteersuja. Nie mowiac o
tym ze mnie nudza.

A.L.

A.L. wrote:

> Ja osobiscie uzywam Gigaspaces 
> 
> http://gigaspaces.com/pr_overview.html

Tego nie znałem, przyjrzę się...

> z dobrym skutkiem oraz w innej aplikacji JCSP
> 
> http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Ta biblioteka (od kiedy ją Pan po raz pierwszy polecał), to wciąż jakoś 
mnie nie przekonuje.  Przetestować jej za bardzo nie miałem gdzie, 
wierzę, że się sprawdza, jednak patrząc w bebechy zdziwiłem się mocno 
widząc w użyciu tylko stare mechanizmy synchronizacji Javy -- oparte na 
monitorach.  Wygląda to tak, jakby o atomowej synchronizacji autorzy nie 
słyszeli?!


Teksty w stylu:

Fair servicing of writers to this channel depends on the fair servicing 
of requests to enter a synchronized block (or method) by the underlying 
Java Virtual Machine (JVM). Java does not specify how threads waiting to 
synchronize should be handled. Currently, Sun's standard JDKs queue 
these requests - which is fair. However, there is at least one JVM that 
puts such competing requests on a stack - which is legal but unfair  and 
can lead to infinite starvation. This is a problem for any Java system 
relying on good behaviour from synchronized, not just for these any-1 
channels.

są już dziś nieco śmieszne, zważywszy obecność, od dwóch lat, wbudowanej 
w Javę biblioteki Douga Lea, która zresztą wcześniej także już była 
dostępna...

A może autorzy uznali, że to tylko nieistotny szczegół implementacyjny? 
  I stosowanie JCSP w obrębie jednej JVMy nie ma większego sensu?

Jest tam też przecież cały ten moduł sieciowy (nie przyglądałem się 
zbytnio), który, jak Pan też niedawno informował, sporo kosztował, a 
teraz można go używać za free.  Więc może i drobiazgi takie jak powyżej 
nie są już istotne wtedy?  Nie wiem...


Szczerze mówiąc, to nie całkiem widzę, co tak naprawdę cennego daje JSCP 
w porównaniu z tym co dziś w java.util.concurrency.** jest?  (Skupiając 
się na równoległości w obrębie jednej maszyny oczywiście.)


> Wedle mocih najlepszych informacji nei widac zadnej rewolucji. Od czsu
> do czasu pojawiaja sie rozne produkty komercyjne do "programowania
> roznoleglego nie pzrerywajac snu", ale po dokladniejszym poskrobanoiu
> okazuja sie jakims tam opakowaniem Java threads.
> 
> "Nie przerywajac snu" okaze sie chyba niemozliwe, albowiem glowna
> trudnosc przy programowaniu rownoleglym to "zrownoleglenie" algorytmu
> tak aby z rownoleglosci byl jakis zysk. Bardzo latwo "zrownoleglic"
> algorytm tak ze na 50 komputerach bedzie dzialal wolniej nie na
> jednym.

To oznaczyłoby raczej, że problem jest w komunikowaniu się procesów, a 
nie samym "zrównoleglaniu".  Samo współdzielenie danych na tych 
wszystkich maszynach może być kolosalnym problemem, jak sądzę, choć może 
jednak w świecie superkomputerów uznaje się to za nieistotny szczegół?...

Z mich skromnych doświadczeń, opartych głównie na zrównoleglaniu wątków, 
to największe straty tkwią w przestojach wątków, a dokładniej w 
momentach przejścia w stan działania, po oczekiwaniu na sygnał "już" od 
pozostałych.  W skrócie, narzuty synchronizacji.

Zapewne znacznie trudniejsze zadanie, to znalezienie miejsc, w których 
"praca" może być wykonywana równolegle, czyli po części zbudowanie 
algorytmu na nowo, niemiej nawet jeśli się uda, nie gwarantuje to 
jeszcze żadnego zysku, i jak rozumiem, to właśnie ma Pan na myśli mówiąc 
o "nie przerywaniu snu", czy tak?


Pytanie, czy JCSP może jakoś w tym pomóc?  Coś więcej mógłby Pan na 
temat tej biblioteki powiedzieć?  Zachęcić bardziej do bliższego 
poznania wskazując dobre i złe strony?


> Ciemno to widze, przynajmniej w USA biorac pod uwage poziom
> wyksztalcenia matematyczno/algorytmicznego na przecietnym amerykanskim
> uniwersytecie

Czyżby nadzieja już tylko w Chińczykach?... ;)


piotr

On Tue, 24 Apr 2007 17:32:42 +0200, Piotr Kobzda <pikob@gazeta.pl>
wrote:

>A.L. wrote:
>
>> Ja osobiscie uzywam Gigaspaces 
>> 
>> http://gigaspaces.com/pr_overview.html
>
>Tego nie znałem, przyjrzę się...
>
>> z dobrym skutkiem oraz w innej aplikacji JCSP
>> 
>> http://www.cs.kent.ac.uk/projects/ofa/jcsp/
>
>Ta biblioteka (od kiedy ją Pan po raz pierwszy polecał), to wciąż jakoś 
>mnie nie przekonuje.  Przetestować jej za bardzo nie miałem gdzie, 
>wierzę, że się sprawdza, jednak patrząc w bebechy zdziwiłem się mocno 
>widząc w użyciu tylko stare mechanizmy synchronizacji Javy -- oparte na 
>monitorach.  Wygląda to tak, jakby o atomowej synchronizacji autorzy nie 
>słyszeli?!
>
>
>Teksty w stylu:
>
>Fair servicing of writers to this channel depends on the fair servicing 
>of requests to enter a synchronized block (or method) by the underlying 
>Java Virtual Machine (JVM). Java does not specify how threads waiting to 
>synchronize should be handled. Currently, Sun's standard JDKs queue 
>these requests - which is fair. However, there is at least one JVM that 
>puts such competing requests on a stack - which is legal but unfair  and 
>can lead to infinite starvation. This is a problem for any Java system 
>relying on good behaviour from synchronized, not just for these any-1 
>channels.
>
>są już dziś nieco śmieszne, zważywszy obecność, od dwóch lat, wbudowanej 
>w Javę biblioteki Douga Lea, która zresztą wcześniej także już była 
>dostępna...
>
>A może autorzy uznali, że to tylko nieistotny szczegół implementacyjny? 
   
[...]

Wie Pan, nei chce mi sie i  nie mam czasu... Bez obrazy, ale Pan w
teje tematyce wyglada na zupelnie swiezego (porownywanie frameworku
Lea z CSP) wiec musialbym napidac dlugi wyklad na ten temat. Proponuje
postudiowac i zaczac od przeczytania ksaizki Hoare na temat CSP
(dostepna w seici za darmo) i zastanowienie czym sie CSP rozni od
monitorow. Jaks inna literature tez moge polecic (ale nei Lea, krorego
zreszta bardzo cenie).

A na temat przydatnisci JCSP: ja mam taka aplikacje co ma 400 procesow
i 600 kanalow. Niech Pan to zrobi w "golej" Javie.

Ksiazka Hoare jest tutaj

http://www.usingcsp.com/

>> Ciemno to widze, przynajmniej w USA biorac pod uwage poziom
>> wyksztalcenia matematyczno/algorytmicznego na przecietnym amerykanskim
>> uniwersytecie
>
>Czyżby nadzieja już tylko w Chińczykach?... ;)

Hindusi tez sa dobrzy.

A.L.
 

On Tue, 24 Apr 2007 16:02:49 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <fela@2005.com> wrote:
>
>> O przeciatnym stanie umyslu "elity" mozna sie przekonac zapuszczajac
>> google na parallel computing blog. Konkluzje malo optymistycznee, za
>> wyjatkiem tego ze wiele osob rozpaczliwie proboje sie promowac do
>> pozycji "guru". Jest to bowiem dziedzina w "hype" dziewicza i jest
>> wielki szmal do wziecia. Nie mowiac o slawie.
>
>Generalnie prawda. Przy czym sama dziedzina jest wyjatkowo trudna.
>
>http://web.comlab.ox.ac.uk/oucl/work/samson.abramsky/pubsthematic.html
>
>I opowiastka:
>
>" What are the fundamental structures of concurrency? We still don't know!"
>
>Samson Abramsky to jeden z wielkich informatyki teoretycznej.
>

Owszem, byc moze, zalezy jak mierzyc. Ale jego prace na temat
concurrency bynajmniej nie powalily mnei na kolana...

A.L.

A.L. wrote:

> Wie Pan, nei chce mi sie i  nie mam czasu... Bez obrazy, ale Pan w
> teje tematyce wyglada na zupelnie swiezego (porownywanie frameworku
> Lea z CSP) wiec musialbym napidac dlugi wyklad na ten temat.

Nie obrażam się, skądże.  Doświadczeń w tej dziedzinie (CSP) mam mało, 
żeby nie powiedzieć, że wcale.  Po prostu ciekawi mnie ta tematyka i 
dobrze czuję się w "światach równoległych". :)  Dlatego pytam.

> Proponuje
> postudiowac i zaczac od przeczytania ksaizki Hoare na temat CSP
> (dostepna w seici za darmo) i zastanowienie czym sie CSP rozni od
> monitorow. Jaks inna literature tez moge polecic (ale nei Lea, krorego
> zreszta bardzo cenie).

Lea to akurat polecać Pan nie musi, a tą Hoare'a to nawet zacząłem 
kiedyś, ale, wstyd się przyznać, nie zaciekawiła.  Odpadłem na 
przyswajaniu symboliki.  Trzeba widzę będzie zmusić się raz jeszcze...

Oczywiście za wskazanie innych interesujących pozycji także wdzięczny będę.

> 
> A na temat przydatnisci JCSP: ja mam taka aplikacje co ma 400 procesow
> i 600 kanalow. Niech Pan to zrobi w "golej" Javie.

Hmmm, w gołej rząd K-wątków, to dziś nie problem.  Z ciekawości aż 
sprawdzę jak się to zachowywać będzie...


piotr

"A.L." <fela@2005.com> wrote:

> Ale jego prace na temat
> concurrency bynajmniej nie powalily mnei na kolana...

No..., on sie akurat zasluzyl pracami nad game semantics i w pelni
abstrakcyjnym modelem dla PCF.


mp

On Tue, 24 Apr 2007 18:33:44 +0200, Piotr Kobzda <pikob@gazeta.pl>
wrote:

>A.L. wrote:
>
>> Wie Pan, nei chce mi sie i  nie mam czasu... Bez obrazy, ale Pan w
>> teje tematyce wyglada na zupelnie swiezego (porownywanie frameworku
>> Lea z CSP) wiec musialbym napidac dlugi wyklad na ten temat.
>
>Nie obrażam się, skądże.  Doświadczeń w tej dziedzinie (CSP) mam mało, 
>żeby nie powiedzieć, że wcale.  Po prostu ciekawi mnie ta tematyka i 
>dobrze czuję się w "światach równoległych". :)  Dlatego pytam.

Na stronie JCSP (tej z Kent University) jest mnostwo materialw
wprowadzajacych do CSP. Proponuje zaczac od tego

Na temat innych paradygmantow ktore sie sprawdzaja: model Linda
Gellertnera. Ksaizka tez ejst dostepna on-line:

http://www.lindaspaces.com/book/index.html

ten paradygmat zostal zaimplementowany jako JavaSpaces (siedzace na
Jini) oraz GigaSpaces.

Wicej proponuje tutaj

http://www.lindaspaces.com/about/index.html

w szczegolnosci dla zwolennikow Pythona :)
 
>> A na temat przydatnisci JCSP: ja mam taka aplikacje co ma 400 procesow
>> i 600 kanalow. Niech Pan to zrobi w "golej" Javie.
>
>Hmmm, w gołej rząd K-wątków, to dziś nie problem.  Z ciekawości aż 
>sprawdzę jak się to zachowywać będzie...
>

Owszem, "duzao watkow" to nie problem natomiast zeby te wszystkei
watki zsynchronizowac, to problem. A jeszcze wiekszy problem jak one
siedza ba roznych procesorack, a jeszcze i zupelnie wiekszy jak to nie
watki a procesy. A programowanie roznolegle to czesciej programowanie
na poziomie procesow niz watkow.

A.L.

Witam

A.L. wrote:

> Wie Pan, ja jednak wsadze Pana do KF

Nareszcie. To Pan zaczyna zawsze awantury. Niech Pan krytycznie popatrzy na
swój post na grupie ai, to zrozumie Pan o czym mówię.

> , bo merytoryczna dyskusja z Panem jest niemozliwa.

Jest możliwa, z takim wyjątkiem kiedy, co post uderza się (w typowy dla Pana
sposób) w we wszystko co robię, czego używam, jak myślę etc.

Powiem otwarcie, kiedyś raz mieliśmy wspólną konstruktywną dyskusję.
Rozmawialiśmy co można zrobić. Pan nie nadawał, że to co robię jest
badziewne, a ja nie musiałem bronić każdego swojego zdania, po prostu
dyskusja toczyła się w atmosferze kreatywności, a nie nihilistycznego
mówienia czego się nie da zrobić, czy że się nie opłaca tego robić.

Podobnie kiedy Pan powiedział nt. AOP. Też się zgadzaliśmy. 

I nie chodzi o to czy poglądy mamy takie same. Chodzi o poziom dyskusji, w
której ważniejsze jest postawienie problemu i jego merytoryczne
rozwiązanie/omówienie, a nie to czy ktoś używa młotka, czy czy innego
narzędzia.

Mówił Pan o MDD, a nie potrafi się Pan wynieś poza pisanie kodu w takim czy
innym języku. A właśnie MDD wskazuje na to, że istnieje pewien poziom
abstrachowania w programowaniu, kiedy język nie ma znaczenia i Pan może
preferować Javę, ja C++ i nie powinno to wnosić negatywnej atmosfery. 
A może nawet powinno to dawać polot, coś jak brainstorm.

> A przytyki osobisye mnie nie inteersuja. Nie mowiac o tym ze mnie nudza.

Posiedzę trochę w KF, potem mnie Pan znowu wypuści jak się Pan stęskni. 
A na razie sugeruje Pan odpoczynek, może i dobrze :-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

A.L. <fela@2005.com> napisał(a): 

> On Tue, 24 Apr 2007 07:25:08 +0000 (UTC), "Aleksander Galicki"
> <tretete.SKASUJ@gazeta.pl> wrote:
> 
> >A co nowego slychac w parallel computing? Przez ostatnie pare lat slychac o 
> >nadchodzacej rewolucji, ale na razie nie za bardzo wiadomo z ktorej strony. 
> 
> Jak na razie nic, o ile mi wiadomo. W dalszym ciagu najbardziej
> popularny jest Fotran oraz MPI czy PVM.

Ostatnim razem na uczelni tego uzywalem (MPI i PVM, nie Fortran). Dobrze nawet
to wspominam - obie biblioteki mialy przemyslany design (ale nie
powiedzialbym, zeby latwo bylo w tym programowac).

> Ja osobiscie uzywam Gigaspaces 
> 
> http://gigaspaces.com/pr_overview.html
> 
> z dobrym skutkiem oraz w innej aplikacji JCSP
> 
> http://www.cs.kent.ac.uk/projects/ofa/jcsp/
> 
> Wedle mocih najlepszych informacji nei widac zadnej rewolucji. 

Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna z
natury (a programisci sa niedoksztalceni - co prawda), to rowniez kwestia
tego, ze rownoleglosc (ta trudna) wciaz jest potrzebna w stosunkowo
niewielkiej nisze. Znaczaca czesc przemyslu dalej nie potrzebuje jakiejs
zlozonej rownoleglosci. Wszystkie przepowiedzi 'rewolucji' bazuja na
przekonaniu, ze poniewaz 'CPU juz sie nie przyspiszaja tak szybko', 'poniewaz
multi-core' itd, to przemysl bedzie za jakis czas _zmuszony_ zajac sie  
szerzej rownolegloscia - znaczy, ze rownoleglosc nagle zostanie bolem glowy
szerszej rzeszy programistow. A nie widac tego jakos. 
A jak juz przemysl bedzie zmuszony (chyba jednak daje wiare tym co mowia, ze
to kwestia tylko czasu) to co? Zmienia Jave/C#? Bedzie nowy jezyk? Wszyscy
beda grzebac w watkach i monitorach (nie bede chcial zagladac do typowego kodu)?
Co do amerykanskich programistow.. A czy gdzies jest lepiej? Kolega mi
opowiadal o Niemczech jeszcze przed padem dotcomow. Zatrudnili drogiego
konsultanta do napisania wzglednie niewielkiego ale wazgego komponentu.
Konsultant ubieral sie w garnitury od Armaniego i jezdzil czerwonym Viperem -
tyle wtedy konsultanci zarabiali. Napisal to cos w 3 tygodnie. Oddal. Ale to
nie chcialo dzialac przy dwoch rownoleglych uzytkownikach. Kolejne 2 dwa
tygodnie 'czerwony Viper' spedzil na badaniu tego zjawiska. Wreszcie firma sie
wkurwila na tyle, ze poprosila kolege zbadac, coz za trudny problem spotkal
konsultanta. Sprawa byla naprawde banalna - ow konsultant nie wiedzial jak sie
maja servlety do watkow. Specyfikacji nie doczytal. Nie chcial dac sie
przekonac ze to o watki chodzi : "Jakie watki?! Watki sa niebezpieczne, ja
watkow nie uzywam!". Kolega mi to opowiedzial dlatego, ze 7 lat pozniej nie w
Niemczech, a na innym koncu swiata poproszono go o zewnetrzny audyt kodu
jednej aplikacji pod katem "a dlaczego to ma takie problemy z performance"? Po
godzinie ogladania kodu kolega sie rozesmial bo znalazl, ze najbardziej
pracochlonny komponent uzywany w tej aplikacji mial 'interface' z samymi
"public static synchronized" funkcjami co niejako niwelowalo fakt umieszczenia
tej aplikacji na wieloprocesorowej maszynie z IBM. 


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Wed, 25 Apr 2007 01:38:07 +0000 (UTC), "Aleksander Galicki"
<tretete.WYTNIJ@gazeta.pl> wrote:

>A.L. <fela@2005.com> napisał(a): 
>
>> On Tue, 24 Apr 2007 07:25:08 +0000 (UTC), "Aleksander Galicki"
>> <tretete.SKASUJ@gazeta.pl> wrote:
>> 
>> >A co nowego slychac w parallel computing? Przez ostatnie pare lat slychac o 
>> >nadchodzacej rewolucji, ale na razie nie za bardzo wiadomo z ktorej strony. 
>> 
>> Jak na razie nic, o ile mi wiadomo. W dalszym ciagu najbardziej
>> popularny jest Fotran oraz MPI czy PVM.
>
>Ostatnim razem na uczelni tego uzywalem (MPI i PVM, nie Fortran). Dobrze nawet
>to wspominam - obie biblioteki mialy przemyslany design (ale nie
>powiedzialbym, zeby latwo bylo w tym programowac).
>

Niestety, MPI i PVM to docyc niski poziom programowania...
  
>
>Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
>Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna z
[...]
>watkow nie uzywam!". Kolega mi to opowiedzial dlatego, ze 7 lat pozniej nie w
>Niemczech, a na innym koncu swiata poproszono go o zewnetrzny audyt kodu
>jednej aplikacji pod katem "a dlaczego to ma takie problemy z performance"? Po
>godzinie ogladania kodu kolega sie rozesmial bo znalazl, ze najbardziej
>pracochlonny komponent uzywany w tej aplikacji mial 'interface' z samymi
>"public static synchronized" funkcjami co niejako niwelowalo fakt umieszczenia
>tej aplikacji na wieloprocesorowej maszynie z IBM. 

Ja pewnie moglbym ksiazke napisac... Pewien facio mial zwyczaj
WSZYSTKIE metody opatrywac slowem "synchronize", "no bo przeciez ktos
moze tego uzyc w srodowisku wielowatkowym". Tak go nauczyli na jakims
super-duper kursie prowadzonym przez naprawde bardzo powazna firme...

Co wiecej, 90% facetow jest przekonanych ze "synchronize" rozwiazuje
WSZYTKIE problemy zwiazane z synchronizacja watkow. Zreszta, na
licznych interviews (ponad 30 ostatnio) tylko 2 czy 3 facetow
wiedzialo ze jest "synchronize" ale tylko jeden wiedzial po co, a
ZADEN nie znal innych konstrukcji Javy do programowania
wielowatkowego. W ZADNYM uniwersytecie w promieniu 100 mil nie ucza o
programowaniu watkow, nie mowiac o programowaniu rownoleglym. 

Wiec nie dziwota.

A.L.

On Wed, 25 Apr 2007 01:38:07 +0000 (UTC), "Aleksander Galicki"
<tretete.WYTNIJ@gazeta.pl> wrote:

 
>Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
>Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna z
>natury (a programisci sa niedoksztalceni - co prawda), to rowniez kwestia
>tego, ze rownoleglosc (ta trudna) wciaz jest potrzebna w stosunkowo
>niewielkiej nisze. Znaczaca czesc przemyslu dalej nie potrzebuje jakiejs
>zlozonej rownoleglosci. Wszystkie przepowiedzi 'rewolucji' bazuja na

La juz pisalem w jakims innym watku wczoraj chyba, ze kiedys wylano
mnie z pracy za uzywanie semaforow...

A.L.

Zupelnie z innej beczki:

"Wezmy dowolne efektywne kodowanie zdan logiki pierwszego rzedu. Niech l(n) -
dlugosc najkrotszego dowodu (w dowolnym efektywnym formalizmie) formuly \phi
o numerze n. Okreslmy funkcje f : N -> N nastepujaco:

f(n) = \sum{i = 0..n} l(n)

Ta funkcja rosnie niewyobrazalnie szybciej od ss i prawdopodobnie szybciej
niz dowolna funkcja, ktora jestes w stanie zdefiniowac (nie uzywajac f ani
l). "

To jest raczej oczywista nieprawda. Zakladajac ze mowimy o prefix-free
maszynach/jezykach itepe, a takze zakladajac, ze dlugoscia dowodu jest dlugosc
maszyny (a nie np. wykonania) to mozna latwo znalezc szybciej (a napewno nie
wolniej) rosnace funkcje. Np uzywajac "dlugosc _najszybszego_ dowodu" zamiast
l(n).

Jednak w kontekscie oryginalnego watku (generowaniu liczb) to troche bez
sensu, bo te funkcje sa enumerable ale nie computable.

A tak by the way: http://www.mcs.vuw.ac.nz/~downey/

"Denis Hirschfeldt and I are writing a book entitled Algorithmic Randomness
and Complexity The current latest draft can be downloaded by clicking on the
attachment above. It is also available as a .pdf file : Algorithmic Randomness
and Complexity (pdf) Denis and I would appreciate any feedback. "

Na razie mozna sciagnac za darmo : http://www.mcs.vuw.ac.nz/~downey/randomness.pdf

Jest to zaledwie trzecia ksiazka, ktora traktuje obszernie o tej tematyce. Za
dwie inne trzeba placic po jakies 50 euro.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

A.L. <fela@2005.com> napisał(a): 

> On Wed, 25 Apr 2007 01:38:07 +0000 (UTC), "Aleksander Galicki"
> <tretete.WYTNIJ@gazeta.pl> wrote:
> 
>  
> >Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
> >Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna z
> >natury (a programisci sa niedoksztalceni - co prawda), to rowniez kwestia
> >tego, ze rownoleglosc (ta trudna) wciaz jest potrzebna w stosunkowo
> >niewielkiej nisze. Znaczaca czesc przemyslu dalej nie potrzebuje jakiejs
> >zlozonej rownoleglosci. Wszystkie przepowiedzi 'rewolucji' bazuja na
> 
> La juz pisalem w jakims innym watku wczoraj chyba, ze kiedys wylano
> mnie z pracy za uzywanie semaforow...
> 

A co to byla za aplikacja/branza?


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

A.L. <fela@2005.com> napisał(a): 

> On Wed, 25 Apr 2007 01:38:07 +0000 (UTC), "Aleksander Galicki"
> <tretete.WYTNIJ@gazeta.pl> wrote:
> 
> >A.L. <fela@2005.com> napisał(a): 
> >
> >> On Tue, 24 Apr 2007 07:25:08 +0000 (UTC), "Aleksander Galicki"
> >> <tretete.SKASUJ@gazeta.pl> wrote:
> >> 
> >> >A co nowego slychac w parallel computing? Przez ostatnie pare lat 
slychac o
>  
> >> >nadchodzacej rewolucji, ale na razie nie za bardzo wiadomo z ktorej 
strony.
>  
> >> 
> >> Jak na razie nic, o ile mi wiadomo. W dalszym ciagu najbardziej
> >> popularny jest Fotran oraz MPI czy PVM.
> >
> >Ostatnim razem na uczelni tego uzywalem (MPI i PVM, nie Fortran). Dobrze 
nawet
> >to wspominam - obie biblioteki mialy przemyslany design (ale nie
> >powiedzialbym, zeby latwo bylo w tym programowac).
> >
> 
> Niestety, MPI i PVM to docyc niski poziom programowania...
>   
> >
> >Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
> >Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna z
> [...]
> >watkow nie uzywam!". Kolega mi to opowiedzial dlatego, ze 7 lat pozniej 
nie w
> >Niemczech, a na innym koncu swiata poproszono go o zewnetrzny audyt kodu
> >jednej aplikacji pod katem "a dlaczego to ma takie problemy z 
performance"? Po
> >godzinie ogladania kodu kolega sie rozesmial bo znalazl, ze najbardziej
> >pracochlonny komponent uzywany w tej aplikacji mial 'interface' z samymi
> >"public static synchronized" funkcjami co niejako niwelowalo fakt 
umieszczenia
> >tej aplikacji na wieloprocesorowej maszynie z IBM. 
> 
> Ja pewnie moglbym ksiazke napisac... Pewien facio mial zwyczaj
> WSZYSTKIE metody opatrywac slowem "synchronize", "no bo przeciez ktos
> moze tego uzyc w srodowisku wielowatkowym". Tak go nauczyli na jakims
> super-duper kursie prowadzonym przez naprawde bardzo powazna firme...
> 
> Co wiecej, 90% facetow jest przekonanych ze "synchronize" rozwiazuje
> WSZYTKIE problemy zwiazane z synchronizacja watkow. Zreszta, na
> licznych interviews (ponad 30 ostatnio) tylko 2 czy 3 facetow
> wiedzialo ze jest "synchronize" ale tylko jeden wiedzial po co, a
> ZADEN nie znal innych konstrukcji Javy do programowania
> wielowatkowego. W ZADNYM uniwersytecie w promieniu 100 mil nie ucza o
> programowaniu watkow, nie mowiac o programowaniu rownoleglym. 
> 
> Wiec nie dziwota.

U mnie w okolicy odpadaja po prostszych pytaniach. Pytania z wielowatkowosci 
to dla zaawansowanych. Ale glownie po indyjskich Kij-Wie-Gdzie-To-Jest 
uniwersytetach. Po europejskich jeszcze moze byc.

[To chyba nie ja pierwszy zauwazylem, ze poziom idiotyzmu branzy jest 
proporcjonalny do popytu na IT ... ?]

A.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Aleksander Galicki <tretete@NOSPAM.gazeta.pl> napisał(a): 

> Jednak w kontekscie oryginalnego watku (generowaniu liczb) to troche bez
> sensu, bo te funkcje sa enumerable ale nie computable.


to oczywiscie dotyczylo l(n), nie f()


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Aleksander Galicki" <tretete@NOSPAM.gazeta.pl> wrote:

> "Wezmy dowolne efektywne kodowanie zdan logiki pierwszego rzedu. Niech
l(n) -
> dlugosc najkrotszego dowodu (w dowolnym efektywnym formalizmie) formuly
\phi
> o numerze n. Okreslmy funkcje f : N -> N nastepujaco:
>
> f(n) = \sum{i = 0..n} l(i)
>
> Ta funkcja rosnie niewyobrazalnie szybciej od ss i prawdopodobnie szybciej
> niz dowolna funkcja, ktora jestes w stanie zdefiniowac (nie uzywajac f ani
> l). "
>
> To jest raczej oczywista nieprawda. Zakladajac ze mowimy o prefix-free
> maszynach/jezykach itepe, a takze zakladajac, ze dlugoscia dowodu jest
dlugosc
> maszyny (a nie np. wykonania) to mozna latwo znalezc szybciej (a napewno
nie
> wolniej) rosnace funkcje. Np uzywajac "dlugosc _najszybszego_ dowodu"
> zamiast l(n).

ROTFL :-)

Zauwaz, ze w moim stwierdzeniu wyraz "jestes" nie odnosil sie do Ciebie :-)


mp

ps. Twoje zalozenia tak naprawde nie sa istotne.

"Aleksander Galicki" <tretete@NOSPAM.gazeta.pl> wrote:

> Jednak w kontekscie oryginalnego watku (generowaniu liczb)
> to troche bez sensu, bo te funkcje sa enumerable ale nie computable.

Dlaczego bez sensu ? Przeciez ktokolwiek nie twierdzil, ze chce generowac
liczby za pomoca, _uwaga_, maszyn turinga. Juz dla klasycznych komputerow
stwierdzenie, ze funkcja nie jest obliczalna, a nawet, ze nie lezy w
dowolnie wysokiej klasie hierarchi zlozonosciowej, jest zbyt slabe, aby
mowic, ze nie da sie za jej pomoca generowac liczb. To jest zadanie dla
Ciebie - dlaczego ? (wskazowka - ten sam fakt bierze sie czesto pod uwage
przy analizie bezpieczenstwa w kryptografii)

> A tak by the way: http://www.mcs.vuw.ac.nz/~downey/

Dzieki, obacze sobie.


ps. Termin "enumerable" dotyczy zbiorow, o funkcjach mowi sie, ze sa
"partial recursive".

mp

"Michal Przybylek" <mrp@neostrada.pl> wrote:

> > A tak by the way: http://www.mcs.vuw.ac.nz/~downey/
> 
> Dzieki, obacze sobie.

Moge sie odwdzieczyc innym draftem:

http://www.cs.princeton.edu/theory/complexity/

Ksiazki wielkiego Sanjeev Arora, jednego z tworcow PCP.


mp

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> "Aleksander Galicki" <tretete@NOSPAM.gazeta.pl> wrote:
> 
> > "Wezmy dowolne efektywne kodowanie zdan logiki pierwszego rzedu. Niech
> l(n) -
> > dlugosc najkrotszego dowodu (w dowolnym efektywnym formalizmie) formuly
> \phi
> > o numerze n. Okreslmy funkcje f : N -> N nastepujaco:
> >
> > f(n) = \sum{i = 0..n} l(i)
> >
> > Ta funkcja rosnie niewyobrazalnie szybciej od ss i prawdopodobnie szybciej
> > niz dowolna funkcja, ktora jestes w stanie zdefiniowac (nie uzywajac f ani
> > l). "
> >
> > To jest raczej oczywista nieprawda. Zakladajac ze mowimy o prefix-free
> > maszynach/jezykach itepe, a takze zakladajac, ze dlugoscia dowodu jest
> dlugosc
> > maszyny (a nie np. wykonania) to mozna latwo znalezc szybciej (a napewno
> nie
> > wolniej) rosnace funkcje. Np uzywajac "dlugosc _najszybszego_ dowodu"
> > zamiast l(n).
> 
> ROTFL :-)
> 
> Zauwaz, ze w moim stwierdzeniu wyraz "jestes" nie odnosil sie do Ciebie :-)
> 
> 
> mp
> 
> ps. Twoje zalozenia tak naprawde nie sa istotne.
> 

Dla mojego przykladu jak najbardziej sa - oba. (A co w tym takiego zabawnego?)


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> "Aleksander Galicki" <tretete@NOSPAM.gazeta.pl> wrote:
> 
> > Jednak w kontekscie oryginalnego watku (generowaniu liczb)
> > to troche bez sensu, bo te funkcje sa enumerable ale nie computable.
> 
> Dlaczego bez sensu ? Przeciez ktokolwiek nie twierdzil, ze chce generowac
> liczby za pomoca, _uwaga_, maszyn turinga. Juz dla klasycznych komputerow
> stwierdzenie, ze funkcja nie jest obliczalna, a nawet, ze nie lezy w
> dowolnie wysokiej klasie hierarchi zlozonosciowej, jest zbyt slabe, aby
> mowic, ze nie da sie za jej pomoca generowac liczb. To jest zadanie dla
> Ciebie - dlaczego ? (wskazowka - ten sam fakt bierze sie czesto pod uwage
> przy analizie bezpieczenstwa w kryptografii)
> 

No jak ktos chce generowac duze liczby za pomoca problemu stopu.... 
Odpowiednio dluga petla for jest jakby bardziej praktycznym podejsciem :-)

A enumerable - jak zwal tak zwal. W mojej "An Introduction to Colmogorov 
Complexity and Its Applications" (a to najlepsza ksiazka ntt i padla mi na 
mozg) enumerable functions sa zdefiniowane na 35-tej stronie. Zreszta, co za 
roznica: funkcja czy zbior?


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Aleksander Galicki <tretete.SKASUJ@gazeta.pl> napisał(a): 

> Michal Przybylek <mrp@neostrada.pl> napisał(a): 
> 
> > "Aleksander Galicki" <tretete@NOSPAM.gazeta.pl> wrote:
> > 
> > > Jednak w kontekscie oryginalnego watku (generowaniu liczb)
> > > to troche bez sensu, bo te funkcje sa enumerable ale nie computable.
> > 
> > Dlaczego bez sensu ? Przeciez ktokolwiek nie twierdzil, ze chce generowac
> > liczby za pomoca, _uwaga_, maszyn turinga. Juz dla klasycznych komputerow
> > stwierdzenie, ze funkcja nie jest obliczalna, a nawet, ze nie lezy w
> > dowolnie wysokiej klasie hierarchi zlozonosciowej, jest zbyt slabe, aby
> > mowic, ze nie da sie za jej pomoca generowac liczb. To jest zadanie dla
> > Ciebie - dlaczego ? (wskazowka - ten sam fakt bierze sie czesto pod uwage
> > przy analizie bezpieczenstwa w kryptografii)
> > 
> 
> No jak ktos chce generowac duze liczby za pomoca problemu stopu.... 
> Odpowiednio dluga petla for jest jakby bardziej praktycznym podejsciem :-)
> 
> A enumerable - jak zwal tak zwal. W mojej "An Introduction to Colmogorov 

Kolmogorov complexity, oczywiscie. Ide spac...


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:

> Dla mojego przykladu jak najbardziej sa - oba.

No wiec, ja nie rozumiem dlaczego.

Dla mnie te zalozenia sa o tyle arbitralne, ze wszystkie te konstrukcje
tlumacza sie na siebie w sposob rekurencyjny (czyli pomijalny z punktu
widzenia tych klas zlozonosci).

> (A co w tym takiego zabawnego?)

Napisalem "rosnie prawdopodobnie szybciej niz dowolna funkcja, ktora jestes
w stanie zdefiniowac (nie uzywajac f ani l)." w kontekscie "rosnie szybciej
niz dowolna funkcja rekurencyjna", co tez dalej wyjasnilem.

Jasne jest, ze nie moglem miec na mysli "ktorej _w ogole_ nie da sie
zdefiniowac", bo mozna by bylo np. sobie powtorzyc konstrukcje f przepisujac
moje slowa.

A druga rzecz zabawna, to to, ze zwracasz uwage, ze f nie jest rekurencyjna,
kiedy ja wlasnie napisalem, ze f rosnie szybciej niz dowolna funkcja
rekurencyjna.


mp

"Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:

 > A enumerable - jak zwal tak zwal. W mojej "An Introduction to Colmogorov
> Complexity and Its Applications" (a to najlepsza ksiazka ntt i padla mi na
> mozg) enumerable functions sa zdefiniowane na 35-tej stronie.

Definicja ze strony 35 jest z zupelnie innej beczki i dla funkcji
rzeczywistych. Definicja funkcji czesciowo rekurencyjnych jest na 27 :-)

Pozatym, ta ksiazka zawiera cale mnostwo bledow (choc nie przecze, ze
generalnie jest niezla).

> Zreszta, co za roznica: funkcja czy zbior?

Troszke inaczej sie o tym mowi...


mp

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> "Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:
> 
> > Dla mojego przykladu jak najbardziej sa - oba.
> 
> No wiec, ja nie rozumiem dlaczego.
> 
> Dla mnie te zalozenia sa o tyle arbitralne, ze wszystkie te konstrukcje
> tlumacza sie na siebie w sposob rekurencyjny (czyli pomijalny z punktu
> widzenia tych klas zlozonosci).

To nie ma nic wspolnego z klasami zlozonosci. Bez tych zalozen dosc trudno 
byloby udowodnic ze "nakrotszy program" jest zawsze krotszy od "najszybszego 
programu". W kazdym razie ja bym sie tego po paru piwach (czyli teraz) nie 
podjal.

> > (A co w tym takiego zabawnego?)
> 
> Napisalem "rosnie prawdopodobnie szybciej niz dowolna funkcja, ktora jestes
> w stanie zdefiniowac (nie uzywajac f ani l)." w kontekscie "rosnie szybciej
> niz dowolna funkcja rekurencyjna", co tez dalej wyjasnilem.

> A druga rzecz zabawna, to to, ze zwracasz uwage, ze f nie jest rekurencyjna,
> kiedy ja wlasnie napisalem, ze f rosnie szybciej niz dowolna funkcja
> rekurencyjna.

?! Moj czytnik niusow niczego takiego ("rosnie szybciej niz dowolna funkcja 
rekurencyjna") nie zauwazyl. Z takim disclaimerem byloby to dosc banalnym 
stwierdzeniem i bym sobie glowy nie zawracal.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:

> > Dla mnie te zalozenia sa o tyle arbitralne, ze wszystkie te konstrukcje
> > tlumacza sie na siebie w sposob rekurencyjny (czyli pomijalny z punktu
> > widzenia tych klas zlozonosci).
>
> To nie ma nic wspolnego z klasami zlozonosci. Bez tych zalozen dosc
> trudno byloby udowodnic ze "nakrotszy program" jest zawsze
> krotszy od "najszybszego programu".

Jak mi udowodnisz powyzsze przy swoich zalozeniach, to ja podam dowod, ze ta
wlasnosc zachodzi z dokladnoscia do funkcji rekurencyjnej (czyli z
dokladnoscia do pomijalnego skladnika z punktu widzenia klas zlozonosci
funkcji nieobliczalnych) przy _dowolnym_ efektywnym kodowaniu.


mp

Aleksander Galicki <tretete.SKASUJ@gazeta.pl> napisał(a): 

> > Dla mnie te zalozenia sa o tyle arbitralne, ze wszystkie te konstrukcje
> > tlumacza sie na siebie w sposob rekurencyjny (czyli pomijalny z punktu
> > widzenia tych klas zlozonosci).
> 
> To nie ma nic wspolnego z klasami zlozonosci. Bez tych zalozen dosc trudno 
> byloby udowodnic ze "nakrotszy program" jest zawsze krotszy od 
"najszybszego 
> programu". W kazdym razie ja bym sie tego po paru piwach (czyli teraz) nie 
> podjal.
> 

Po namysle: zalozenie o prefix-free w tym tez nie pomoze. Zdecydowanie ide 
spac.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Wed, 25 Apr 2007 03:32:11 +0000 (UTC), "Aleksander Galicki"
<tretete.WYTNIJ@gazeta.pl> wrote:

>A.L. <fela@2005.com> napisał(a): 
>
>> On Wed, 25 Apr 2007 01:38:07 +0000 (UTC), "Aleksander Galicki"
>> <tretete.WYTNIJ@gazeta.pl> wrote:
>> 
>>  
>> >Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
>> >Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna z
>> >natury (a programisci sa niedoksztalceni - co prawda), to rowniez kwestia
>> >tego, ze rownoleglosc (ta trudna) wciaz jest potrzebna w stosunkowo
>> >niewielkiej nisze. Znaczaca czesc przemyslu dalej nie potrzebuje jakiejs
>> >zlozonej rownoleglosci. Wszystkie przepowiedzi 'rewolucji' bazuja na
>> 
>> La juz pisalem w jakims innym watku wczoraj chyba, ze kiedys wylano
>> mnie z pracy za uzywanie semaforow...
>> 
>
>A co to byla za aplikacja/branza?
>

Telco. Poczatkowe proby "broadband".

A.L.

"Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:

> Po namysle: zalozenie o prefix-free w tym tez nie pomoze.

Tak czy inaczej musisz najpierw doprecyzowac co miales na mysli, zanim
zaczniesz sie zastanawiac czy jest to prawda. Ja odczytalem Twoje slowa
"asymptotycznie wieksza o skladnik nierekurencyjny" (inaczej jest to
trywialne, ale nieciekawe).


mp

On Wed, 25 Apr 2007 13:11:17 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:
>
> > A enumerable - jak zwal tak zwal. W mojej "An Introduction to Colmogorov
>> Complexity and Its Applications" (a to najlepsza ksiazka ntt i padla mi na
>> mozg) enumerable functions sa zdefiniowane na 35-tej stronie.
>
>Definicja ze strony 35 jest z zupelnie innej beczki i dla funkcji
>rzeczywistych. Definicja funkcji czesciowo rekurencyjnych jest na 27 :-)
>
>Pozatym, ta ksiazka zawiera cale mnostwo bledow (choc nie przecze, ze
>generalnie jest niezla).

Panska ksiazka lepsza? Mozna tytulik?...

A.L.

"A.L." <fela@2005.com> wrote:

> >Pozatym, ta ksiazka zawiera cale mnostwo bledow
> >(choc nie przecze, ze generalnie jest niezla).
>
> Panska ksiazka lepsza? Mozna tytulik?...

Nie rozumiem o co Ci chodzi. To, ze ksiazka ma bledy nie jest opinia, ale
faktem.

Moze jednak troszke wiecej pomyslisz, zamiast uporczywie bawic sie w
zlosliwosci w stosunku do mojej osoby, hm... ?


mp

"A.L." <fela@2005.com> wrote:

> Panska ksiazka lepsza? Mozna tytulik?...

BTW, nie zauwazylem slowa "dziekuje" na grupie matematycznej, za spelnienie
Twojej prosby o pomoc w rozwiazaniu pewnego prostego zadania (i za
doedukowanie Ciebie z podstawowych faktow dotyczacych informatyki
teoretycznej). Jezeli wolisz mozesz te podziekowania wyrazic tutaj. W
zasadzie jezeli wolisz, to nie musisz mi dziekowac w ogole, ale to poczytam
sobie jako niegrzecznosc z Twojej strony.


mp

On Wed, 25 Apr 2007 14:31:25 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <fela@2005.com> wrote:
>
>> Panska ksiazka lepsza? Mozna tytulik?...
>
>BTW, nie zauwazylem slowa "dziekuje" na grupie matematycznej, za spelnienie
>Twojej prosby o pomoc w rozwiazaniu pewnego prostego zadania (i za
>doedukowanie Ciebie z podstawowych faktow dotyczacych informatyki
>teoretycznej). Jezeli wolisz mozesz te podziekowania wyrazic tutaj. W
>zasadzie jezeli wolisz, to nie musisz mi dziekowac w ogole, ale to poczytam
>sobie jako niegrzecznosc z Twojej strony.
>
>
>mp

Wsadzam Pana do KF. Mam dwa KF: temporary i permamnent. Pan idzie do
permanent

A.L.

A.L. napisał(a):
>>> Panska ksiazka lepsza? Mozna tytulik?...
>> BTW, nie zauwazylem slowa "dziekuje" na grupie matematycznej, za spelnienie
>> Twojej prosby o pomoc w rozwiazaniu pewnego prostego zadania (i za
>> doedukowanie Ciebie z podstawowych faktow dotyczacych informatyki
>> teoretycznej). Jezeli wolisz mozesz te podziekowania wyrazic tutaj. W
>> zasadzie jezeli wolisz, to nie musisz mi dziekowac w ogole, ale to poczytam
>> sobie jako niegrzecznosc z Twojej strony.
>>
> Wsadzam Pana do KF. Mam dwa KF: temporary i permamnent. Pan idzie do
> permanent

Jakbym zgadł :-)

Tak nawiasem mówiąc, gdybyś przebrnął choć przez pierwszy rozdział tej 
książki, to nie miał byś problemów z rozwiązaniem tego (elementarnego) 
zadania z matematyki. Zabawne jest, że to, że kompletnie nie masz 
pojęcia na dane tematy, nie przeszkadza Ci w tak ostrym wypowiadaniu sie 
o nich i (sic!) polecaniu literatury. Założę się, że nie tylko z teorii 
złożoności/obliczalności, ale także z logiki, rachunku lambda, rachunku 
sigma i kilku jeszcze innych dziedzin, przy których odsyłałeś ludzi do 
książek, mógłbym dać Ci proste zadania (na poziomie łatwych zadań 
egzaminacyjnych) i nie rozwiązał byś żadnego. Ja nie przeczę, ze Ty 
naprawdę posiadasz te książki. Ale, myślę, poza obmacaniem okładki i 
stwierdzeniem, ze w środku znajdują sie literki, niewiele więcej zgłębiłeś.

Jesteś zwyczajnie tępy jak but, a jednocześnie we własnych oczach 
uważasz siebie za człowieka inteligentnego i o sporej wiedzy (a 
utwierdza Cię w tym przekonaniu mocniej, Twoja zabawna skłonność do 
otaczania się idiotami większymi od siebie i prowadzenia z nimi 
namiętnych dyskusji - wtedy bowiem okazujesz się lepszy). Co jest, 
oczywiście, charakterystyczne dla ludzi o Twojej tępocie. Jest też 
charakterystyczne to, że tacy ludzie wyjątkowo mocno związują swoją 
pozycję z opinią jaką mają o nich inni, nawet w tak wirtualnych i 
sztucznych społecznościach jak społeczność grup dyskusyjnych. 
Powiedziałeś, że wsadzasz mnie do KF, bo po prostu panicznie boisz się 
tego, że ktoś mógłby pomyśleć, że jesteś zwyczajnie niekompetentny i 
pomimo generowania hektowersów szumu, tak zwyczajnie niewiele potrafisz 
- co szczególnie widać podczas dyskusji na matematycznie formalnym 
poziomie, gdzie nie możesz skwitować rozmowy opowiastkami o tym "gdzie 
to ja nie zasiadałem i czego to ja nie robiłem, więc mam rację" (rany! - 
znowu cos co zarzucałeś innym).

Koniec darmowej diagnozy.


No więc jak, zgodzisz się na parę prostych zadanek... ?


mp

Monika Wolrat napisał(a):

> No więc jak, zgodzisz się na parę prostych zadanek... ?

Damn... Można by myśleć, że to trochę nie ładnie, że nie uszanowałem 
Twojego KF. Ale przecież oboje wiemy, że Ty mnie nie wsadziłeś do KF, 
tylko chciałeś przybrać wygodną pozycję do nieodpowiedzenia na 
niewygodny temat.

Czyli, to co robię, tylko jest po to, aby oprócz nas także inni 
wiedzieli, że to przeczytałeś :-)


mp

"Monika Wolrat" <monia@hamete.pl> wrote:

> No wiec jak, zgodzisz sie na pare prostych zadanek... ?

Ja sie zgodze.

Panie Przybylek nie jestem matematykiem
ale zwyklym programista
z wykszatalcenia technikiem mechanikiem
ale od roku tu i na innych grupach
(np. pl.comp.lang.python)
nie moge Pana naklonic do praktycznego
zmierzenia sie z tak prostym matematycznie
problemem jak pierwiaski (wszystkie czyli zespolone)
wielomianu zespolonego n-tego stopnia.

Ale konkternie - czyli dzialajacy algorytm
a nie jakies teotetyczne bajania - dobrze ?

Zwyciezy ten kto napisze po prostu szybszy
algorytm dla niebanalnych wielomianow
dobrze ?

Juz malo pamietam (bo numeryka i to
wylacznie praktyczna) zajmowalem sie
wieki temu ale mysle ze warto sprobowac
A co tam , najwyzej przegram.
Na moja pensje (czyli zadowolenie Zony:)
to nie wplynie.

Wtedy publicznei napisze:

Tak ! Pan Przybylek to cham ale madry cham !
Bo na razie moge stwierdzic ze jestes Pan tylko cham.

Ok ?

Zeby nie bylo roznic jezykowo sprzetowych
proponuje C++
Sektor sie ucieszy :)

PS: A moze ktos sie jeszcze przylaczy ?

AK

"Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> wrote:

> > No wiec jak, zgodzisz sie na pare prostych zadanek... ?
>
> Ja sie zgodze.
>
> Panie Przybylek nie jestem matematykiem
> ale zwyklym programista
> z wykszatalcenia technikiem mechanikiem
> ale od roku tu i na innych grupach
> (np. pl.comp.lang.python)
> nie moge Pana naklonic do praktycznego
> zmierzenia sie z tak prostym matematycznie
> problemem jak pierwiaski (wszystkie czyli zespolone)
> wielomianu zespolonego n-tego stopnia.

Klamiesz. Kiedykolwiek nie zadawales mi takiego zadania. Pozatym ja na
pl.comp.lang.python na pewno w ciagu ostatniego roku nie napisalem mail'a.

> Ale konkternie - czyli dzialajacy algorytm
> a nie jakies teotetyczne bajania - dobrze ?

Nie, nie dobrze.


mp

"Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> wrote:

> Zwyciezy ten kto napisze po prostu szybszy
> algorytm dla niebanalnych wielomianow
> dobrze ?

Pozatym, kryterium "szybszy algorytm" w kontekscie szukania pierwiastków
wielomianowych, jest kompletnie bezsensowne.

Takich rzeczy uczy sie studentow gdzies w okolicach 2 roku studiów
informatycznych :-)


mp

ps. Uczy sie takze, tego, ze kiedy sie ma konkretny problem, to najpierw
trzeba sprawdzic, czy przypadkiem ktos juz nie napisal odpowiednich
bibliotek, ktore nadaja sie do rozwiazania owego problemu.

"Michal Przybylek" <mrp@neostrada.pl> wrote:
>
>> Zwyciezy ten kto napisze po prostu szybszy
>> algorytm dla niebanalnych wielomianow
>> dobrze ?
>
> Pozatym, kryterium "szybszy algorytm" w kontekscie
> szukania pierwiastków wielomianowych, jest kompletnie bezsensowne.

Dla mnie nie .
Mamy znalezc wszystkie pierwiaski
Temu komu w momencie znalezienia wszystkich
pierwiastkowzespolonuych stoper wykazew mniej
 - ten wygrywa.
Proste jak drut.

Wyniki jakos usrednimy dla dosc duzego 'setu' wielomianow.
I 'syfiastych' iu normalncy duzychg malych n , losowych itp.
Zreszta odpowiednie test-przypadki to nam chyba Koledzy podesla :)

> Takich rzeczy uczy sie studentow gdzies w okolicach 2 roku studiów
> informatycznych :-)

No wiec tym bardziej Pan tak doswiadczony naukowiec
nie powinien z tym miec najmniejszego problemu :)

Po prostu bedzie to taki troche smieszny pojedynek:
nauka - przemysl ale _na boisku nauki_ (bo na boisku
"przemysl"do by Pan legl juz w trakcie rozgrzewki z
wiadomych wzgledow).

> ps. Uczy sie takze, tego, ze kiedy sie ma konkretny problem, to najpierw
> trzeba sprawdzic, czy przypadkiem ktos juz nie napisal odpowiednich
> bibliotek, ktore nadaja sie do rozwiazania owego problemu.

No a do czego ja zachecam ?  ! :)
Perwno ze nikt nie bedzie odkrywal kola od poczatku !
Wszystko sie robi "na bazie"
Mowi Pan oczywistosci jakies zupelne.

AK

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> "Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:
> 
> > Po namysle: zalozenie o prefix-free w tym tez nie pomoze.
> 
> Tak czy inaczej musisz najpierw doprecyzowac co miales na mysli, zanim
> zaczniesz sie zastanawiac czy jest to prawda. Ja odczytalem Twoje slowa
> "asymptotycznie wieksza o skladnik nierekurencyjny" (inaczej jest to
> trywialne, ale nieciekawe).
> 

To bylo zludzenie optycznie-wieczorowe - myslalem, ze ta l(n) to moze byc
jedna z postaci K(n) - czyli zlozonoscia opisowa, ale nie - te rzeczy sa
niezalezne. (zalozenie o prefix-free jest czasem potrzebne, bo bez tego
zalozenia maszyna moze przeczytac tylko kawalek programu i sie zatrzymac nie
czytajac reszty). Dlatego tez podalem link do ksiazki o zlozonosci opisowej -
ale sie mylilem - dlugosc najkrotszego dowodu nie ma za wiele wspolnego ze
zlozonoscia opisowa (przynajmniej nie wprost).
Ale i tak moj przyklad (banalny bo banalny) spelnial swoja role - pokazanie,
ze rownie wolnych funkcji - nierekurencyjnych - mozna sobie na peczki
znajdowac. Duzo trudniejszym zadaniem byloby znalezienie _programow_, ktore
generuja duuze liczby (moze byc jedna). Byl nawet kiedys-gdzies konkurs na ten
temat (ale juz nie moge znalezc info w Internecie).

A wspominanie o bledach w ksiazce - to czepialstwo. Te bledy sa przewaznie
glupie literowki i przeoczenia (w dowodach - jak sie znany dowod tlumaczy na
wlasna nomenklature). 


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

A.L. <fela@2005.com> napisał(a): 

> On Wed, 25 Apr 2007 03:32:11 +0000 (UTC), "Aleksander Galicki"
> <tretete.WYTNIJ@gazeta.pl> wrote:
> 
> >A.L. <fela@2005.com> napisał(a): 
> >
> >> On Wed, 25 Apr 2007 01:38:07 +0000 (UTC), "Aleksander Galicki"
> >> <tretete.WYTNIJ@gazeta.pl> wrote:
> >> 
> >>  
> >> >Czyli ani darmowego lunchu, ani rewolucji chyba nie bedzie. 
> >> >Z innej strony - to nie tylko kwestia tego, ze rownoleglosc jest trudna 
z
> >> >natury (a programisci sa niedoksztalceni - co prawda), to rowniez 
kwestia
> >> >tego, ze rownoleglosc (ta trudna) wciaz jest potrzebna w stosunkowo
> >> >niewielkiej nisze. Znaczaca czesc przemyslu dalej nie potrzebuje jakiejs
> >> >zlozonej rownoleglosci. Wszystkie przepowiedzi 'rewolucji' bazuja na
> >> 
> >> La juz pisalem w jakims innym watku wczoraj chyba, ze kiedys wylano
> >> mnie z pracy za uzywanie semaforow...
> >> 
> >
> >A co to byla za aplikacja/branza?
> >
> 
> Telco. Poczatkowe proby "broadband".
> 

Aah, to wiele wyjasnia. Mam pare znajomych w firmie po semi-traumatycznych 
przezyciach w telco. Ponoc telco jest na trzecim miejscu pod wzgledem 
kretynizmu - po duzych firmach consultingowych i po branzy bankowo-
finansowej. 


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:

> A wspominanie o bledach w ksiazce - to czepialstwo. Te bledy
> sa przewaznie glupie literowki i przeoczenia (w dowodach - jak
> sie znany dowod tlumaczy na wlasna nomenklature).

Slyszalem opinie, ze niektore twierdzenia w zadaniach do udowodnienia sa
nieprawdziwe - i wyglada to tak, ze autor zamiast usiasc i rozwiazac
zadanie, mial tylko jakas idee w glowie, ktora po dobrecyzowaniu okazywala
sie byc bledna (tzn. bardzo latwo sie na tym zlapac). Podobnie nawet z
niektorymi szkicami dowodow, ktorych nie mozna bylo doprecyzowac po mysli
autora.

Ja juz nie pamietam szczegolow, ale spojrz np. na przypis na str. 187, gdzie
autor twierdzi, ze majac stala Chaitina z dokladnoscia do n bitow, mozna
rozwiazywac problemy o dlugosci mniejszej niz n, ale wymaga to
"nierekurencyjnego czasu". Tymczasem jasne jest, ze mozna to zrobic w
"nierekurencyjnym czasie", ale to, czy przypadkiem nie mozna tego zrobic
szybciej (dla stalej chaitina, badz powiedzmy jakiegos innego lancucha
bitow) jest chyba w ogole problemem otwartym.


mp

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> "Aleksander Galicki" <tretete.SKASUJ@gazeta.pl> wrote:
> 
> > A wspominanie o bledach w ksiazce - to czepialstwo. Te bledy
> > sa przewaznie glupie literowki i przeoczenia (w dowodach - jak
> > sie znany dowod tlumaczy na wlasna nomenklature).
> 
> Slyszalem opinie, ze niektore twierdzenia w zadaniach do udowodnienia sa
> nieprawdziwe - i wyglada to tak, ze autor zamiast usiasc i rozwiazac
> zadanie, mial tylko jakas idee w glowie, ktora po dobrecyzowaniu okazywala
> sie byc bledna (tzn. bardzo latwo sie na tym zlapac). Podobnie nawet z
> niektorymi szkicami dowodow, ktorych nie mozna bylo doprecyzowac po mysli
> autora.
> 
> Ja juz nie pamietam szczegolow, ale spojrz np. na przypis na str. 187, gdzie
> autor twierdzi, ze majac stala Chaitina z dokladnoscia do n bitow, mozna
> rozwiazywac problemy o dlugosci mniejszej niz n, ale wymaga to
> "nierekurencyjnego czasu". Tymczasem jasne jest, ze mozna to zrobic w
> "nierekurencyjnym czasie", ale to, czy przypadkiem nie mozna tego zrobic
> szybciej (dla stalej chaitina, badz powiedzmy jakiegos innego lancucha
> bitow) jest chyba w ogole problemem otwartym.
> 

Mamy chyba rozne wydania (mam 2nd edition) - ja niczego takiego nie mam na 
stronie 187. Znalazlem cos podobnego na stronie 218 i rzeczywiscie nie ma 
podanego dowodu (sam tez nie potrafie wymyslic).

Za to przypomnialem sobie jak sie nazywaly te maszyny od 'najwiekszych' 
liczb: http://en.wikipedia.org/wiki/Busy_beaver 


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/