Dnia 16.10.2012 bartekltg <b...@g...com> napisał/a:
> W dniu 2012-10-16 23:02, Baranosiu pisze:
>
>> ciąg. Natomiast sama możliwość ustawienia elementów zbioru w ciąg
>> (przeliczalność) jest (o ile się nie mylę :D) warunkiem niezbędnym na
>> istnienie algorytmu sortującego (rozumianego jako "sekwencja
>> instrukcji" - niekoniecznie skończona, być może sortująca w sensie
>> granicznym).
>
> Jeśli przez sortowanie rozumiemy znalezienie odwzorowania
> z liczb naturalnych z zbiór, które zachowuje porządek, to ok.
> Ale możesz bez trudu zbudować strukture danych, która
> przechowa potencjalnie nieskończony zbiór z pynktami
> skupienia, np wszytkie liczby postaci 1/n i 0 ;)

Owszem, to może rozwiązać pewną klasę problemów, ale jak mi się
"zachce" zmienić relację porządku i posortować "od nowa" to może być
problem - oczywiście problem teoretyczny, bo w praktyce na komputerach
operujemy zbiorami skończonymi.


> Ujmę to tak: mając dowolnej mocy zbiór*),
> aby posortować algorytmicznie jego dowolny skończony
> podzbiór (ustawić go w ciąg) potrzeba/wystarczy porządek
> liniowy.

Zgoda.


> *) Nie, żeby na komputerze mógł się pojawić kiedykolwiek
> większy niż przeliczalny;)

Nie wiem co przyniesie przyszłość, ale komputery analogowe na potęgę
były wykorzystywane przez Japończyków w latach 90-tych do zadań czasu
rzeczywistego (liczenie równań różniczkowych, teoretycznie przy
symulowaniu zderzeń galaktyk, a w praktyce wiadomo do czego :D).
Tak jak obecnie w układach FPGA programuje się połączenia między
bramkami logicznymi, tak tam program ustanawiał połączenia między
blokami realizującymi operacje w sposób analogowy :D

do góry

W dniu wtorek, 16 października 2012 23:33:06 UTC+2 użytkownik Baranosiu napisał:
> Nie wiem co przyniesie przyszłość, ale komputery analogowe na potęgę
> były wykorzystywane przez Japończyków w latach 90-tych do zadań czasu
> rzeczywistego (liczenie równań różniczkowych, teoretycznie przy
> symulowaniu zderzeń galaktyk, a w praktyce wiadomo do czego :D).
No do czego w praktyce?
Pozdrawiam

do góry

W dniu 2012-10-16 23:30, M.M. pisze:
> W dniu wtorek, 16 października 2012 23:20:34 UTC+2 użytkownik bartekltg napisał:
>> W dniu 2012-10-16 23:07, M.M. pisze:
>>> Jaki jest przyklad zbioru z czesciowym porzadkiem ktorego nie
>>> da sie posortowac?
>> {a,b,c} z porządkiem
>> {a>b, c>b}
> Czyli relacja czesciowego porzadku nic nie mowi o tym, ze porownywanie
> jest zdefiniowane dla kazdej pary elementow ze zbioru? Jesli tak, to
> by wszystko mi wyjasnialo :)

Wiki:
Porządek liniowy to porządek częściowy >= na danym zbiorze X
spełniający warunek spójności

\forall_{a, b \in X}\; a >= b \or b >= a.

Jeśli możesz porównać wszytko, to jest porządek liniowy.

Częściowy mówi tylko, że ma to być spójne,
czyli wyrzuca sytuacje a>b i b>a
czy trójkącik a>b b>c c>a

pzdr
bartekltg

do góry

On 16/10/2012 00:51, M.M. wrote:
> W dniu poniedziałek, 15 października 2012 23:59:13 UTC+2 użytkownik Andrzej
Jarzabek napisał:
>
>> sieczka gdzieniegdzie zrobi, to da się ją posprzątać. Powiesz, że
>> klienta nie interesuje, czy jest sieczka, czy nie. Ale czy nie
>> interesuje go również, czy zaimplementowanie kolejnego wymagania zajmie
>> dwa tygodnie, czy - z powodu sieczki - dziesięć? Czy nie interesuje go
>> ile razy na miesiąć system będzie padał i jaki będzie miał downtime?
> Raczej powiem że w praktyce nie potrafię albo przepchnąć takiej argumentacji,
> pomimo że moim zdaniem też jest oczywista, albo w praktyce zrobienie dobrego
> projektu jest w ogóle trudne do osiągnięcia.

Tru dat. Dlatego w swojej masie projekty programistyczne przekraczają
budżety, terminy i produkują duże ilości bugów. Ale tak w ogóle da się
zrobić dobrze, i nawet nie o to chodzi, że zrobienie dobrze jest trudne
samo w sobie - jest trudne w pewnych organizacjach, z pewnycmi ludźmi,
dla pewnych klientów.

> Chodzi mi o taką praktykę...
> jakby to zgrabnie określić, może... całą praktykę biznesową, nie tylko
programistyczną.
> Nie potrafię przepchnąć takiej argumentacji w najróżniejszych okolicznościach. A to
w
> rozmowie z kolegą z zespołu ciężko, bo zaraz rozmowa przyjmie taki ton, że
> uważam iż on zrobił sieczkę a nie porządny kod. Gdy poczuje zagrożenie z mojej
> strony, to strach się bać co mi za plecami odwinie.

Znaczy ne należy przyjmować takiego tonu z jednej strony, ale z drugiej
też nie należy się bać. Po pierwsze można od razu powiedzieć, że to nie
musi być czyjaś wina, że robi sieczkę, tylko że taka jest naturalna
tendencja w kodzie utrzymywanym na dłuższym odcinku czasu. I może w
ogóle lepiej przedstawić całą sprawę jako "odkryłem zajebisty sposób na
to, żeby nie mieć problemów takich, jakie mamy" niż "robisz kaszanę,
kaszaniarzu".

Z drugiej strony jeśli nie można powiedzieć, że coś dobrze by było
naprawić czy zrobić lepiej, bo od razu ktoś poczuje się urażony, to też
nie jest najzdrowsza sytuacja.

> Z managementem ciężko, bo łatwo górę bierze chciwość i zaoszczędzenie odrobiny
czasu.

Znowu, można próbować przekonać, że jeśli program ma być dalej
rozwijany, to tak będzie szybciej i taniej. Jeśli nie są przekonani, to
można zbierać na nich kwity w postaci "mogę to zrobić trochę szybciej
teraz, ale jeśli dalej będzie ten program trzeba utrzymywać, to będzie
to trwało przez to dłużej i będzie więcej bugów, proszę o decyzję" - jak
masz na piśmie kilka decyzji "zrób szybciej teraz, chrzanić później" -
to potem możesz pokazać, że bugi, zawalone terminy itd. wynikają
bezpośrednio z decyzji managementu. :)

> Z klientem to już w ogóle najtrudniej, bo klient nie dysponuje odpowiednią
> wiedzą, a często chce narzucać pewne rzeczy.

Ale chyba raczej niekoniecznie to, jak ma wyglądać kod.

> Kolejna sprawa to wypada operować konkretami.

Ale właśnie o to chodzi, że zwykle nie ma konkretów, są tylko
niewiadome. O sensowne danej liczbowe też ciężko, najlepiej chyba w
takiej sytuacji wyjść z takiej pozycji, że jako praktyk masz opinię, że
lepiej (taniej, szybciej) będzie właśnie tak i tyle, a jak chcą zrobić
inaczej, to potem mogą mieć tylko pretensje do siebie.

> Trzeba podać jakie rozbudowy, o ile przyspieszą późniejszy czas wykonania,
> itd.

Jak już masz rzucać jakąś liczbą, to ja bym rzucił taką, że sensowne
oszacowanie wysiłku to 20% tego wysiłku - i to się nie wlicza do dalszej
pracy, czyli jak zrobienie czegoś będzie trwało 10 miesięcy, to
oszacowanie tego faktu zajmie miesiące dwa, a oszacowanie i zrobienie 12.

> Nie da się przecież tak zaprojektować programu, żeby zupełnie każda modyfikacja
była w
> przyszłości łatwa.

Da się (relatywnie), tylko nie tak, jak myślisz. Projektowanie programu
od początku tak, żeby był jak najbardziej elastyczny jest niewłaściwą
techniką.

> Z kolei żeby operować konkretami to trzeba dobrze znać dziedzinę, ale
> nawet jak się zna dziedzinę to jest trudno oszacować czas i próg opłacalności.

IMO znajomość dziedziny niewiele ci da. Tego, co zajmie ci najwięcej
czasu i tak i tak nie przewidzisz.

> W mojej praktyce nigdy większego projektu nie robiłem dla dziedziny o której
> na starcie miałem pojęcie. Zawsze musiałem douczyć się na szybko. Właściwie to
> nie wiedziałem nawet co w ogóle może być użyteczne w systemie i jakie rozbudowy
> zaproponować.

Najlepiej w ogóle nic nie proponować. Jedyne, co trzeba ustalić, to czy
klient sam będzie chciał rozbudowy - z mojego doświadczenia wynika, że o
ile używa programu, to będzie.

> W takich warunkach musiałem oszacować czas, cenę i, co tu dużo mówić,
> odgadnąć jaki projekt będzie najlepszy. Nie można bez dobrej znajomości dziedziny
zrobić
> dobrego projektu, można go co najwyżej odgadnąć.

E tam. Zrobienie dobrego projektu nie ma wiele wspólnego z
przewidywaniem przyszłych wymagań. Jeśli program spełnia wyamagania
aktualne, a przy tym ma prostą konstrukcję i czytelny kod, to już
projekt jest dobry.

> Kolejny problem jest taki, że krótko po
> rozpoczęciu chcą zobaczyć jakiś prototyp, tak jakby dla pewności że prace w
> ogóle trwają.

No więc praca w ten sposób, żeby bieżący stan można było krótko po
rozpoczęciu i często potem demonstrowac jest bardzo dobrą praktyką...

> Prototyp wprost z definicji da się wykonać na skróty.

...tylko że do tego nie należy stosować prototypu w takim sensie.

Takie prototypy (zwane niekiedy spike solutions) mają prawo bytu, ale
przy zrozumieniu, że po wykonaniu są wwyrzucane, więc jako takie nie
dają żadnej pewności, że "prace trwają".

Natomiast owszem, jak najszybsze doprowadzenie kodu właściwego do stanu,
w którym można pokazać, że działa, jest bardzo wartościowe. Ale to
wszystko pod warunkiem, że wszystko jest obwarowane solidnymi testami i
porządnie napisane.

> Chociażby
> można go zrobić bez uprzedniego przemyślenia jak będzie testowany, ale jest
> więcej pułapek. Potem przy przechodzeniu z prototypu do pełnej wersji może nagle
> się okazać, że program będzie bardzo trudny w testowaniu.

Najlepiej zatem zacząć od pisania testów.

> We wszystko powyższe czasami wplata się problem wydajnościowy, a kod
> po zoptymalizowaniu to już masakra w utrzymaniu.

Bo ja wiem? Niezrozumiałe identyfikatory wcale nie działają szybciej od
zrozumiałych. Zamiana bloku kodu w funkcji na wywołanie funkcji inline
niczego nie spowalnia. W C++ nawet obiektowe wrappery na proste typu nic
nie kosztują.

> P.S.
> Czy widac polskie znaki?

Bez problemu.

do góry

W dniu wtorek, 16 października 2012 23:57:19 UTC+2 użytkownik bartekltg napisał:
> Wiki:
> Jeśli możesz porównać wszytko, to jest porządek liniowy.
> Częściowy mówi tylko, że ma to być spójne,
> czyli wyrzuca sytuacje a>b i b>a
> czy trójkącik a>b b>c c>a
Tak, tego nie wiedziałem.
Dzięki.

do góry

Dnia 16.10.2012 M.M. <m...@g...com> napisał/a:
> W dniu wtorek, 16 października 2012 23:33:06 UTC+2 użytkownik Baranosiu napisał:
>> Nie wiem co przyniesie przyszłość, ale komputery analogowe na potęgę
>> były wykorzystywane przez Japończyków w latach 90-tych do zadań czasu
>> rzeczywistego (liczenie równań różniczkowych, teoretycznie przy
>> symulowaniu zderzeń galaktyk, a w praktyce wiadomo do czego :D).
> No do czego w praktyce?
> Pozdrawiam

Rząd wykorzystywał ten komputer do kontroli lotów kosmicznych,
sterowania rakiet balistycznych, obrony przeciwpowietrznej
itp. Wprawdzie dokładność "obliczeń" nie była wysoka (wystarczająca w
praktyce) ale taki analogowy układ po odpowiednim zaprogramowaniu mógł
sterować jednocześnie ponad dwustoma obiektami latającymi praktycznie
w czasie rzeczywistym. Nie pamiętam już teraz dobrze szczegółów
(czytałem o tym projekcie jakieś 20 lat temu w Młodym Techniku).

do góry

On 16/10/2012 11:51, Baranosiu wrote:
> Dnia 16.10.2012 Michoo <m...@v...pl> napisał/a:
>>> analogowej może już nie być algorytmem na maszynie dyskretnej.
>>
>> Dlatego napisałem - "na pewnej abstrakcyjnej maszynie".
>
> Na "abstrakcyjnej" czyli na żadnej :D

Dlaczego aż żądnej? Algorytm sam też jest abstrakcją.

> Zwykle w informatyce przyjmuje
> się w domyśle maszyny Turinga, ale samo pojęcie algorytmu nie musi ich
> dotyczyć :D
[...]
> Wszystkie współczesne komputery cyfrowe (łącznie z kwantowymi) to
> maszyny Turinga, więc rozróżnienia się nie robi, w tym sensie można
> pominąć szczegóły maszyny, ale samo pojęcie algorytmu to coś więcej
[...]
> Ok, są, ale to są tylko konkretne modele. Można na przykład
> zdefiniować pojęcie algorytmu w oparciu o maszyny Turinga ale...

Z tymi Maszynami Turinga to raczej nieporozumienie. Maszyna Turinga
wykonuje jeden konkretny algorytm, żadnego innego nie potrafi. To, o
czym się rozważa przy pomocy Maszyn Turinga to nie są algorytmy, tylko
obliczenia. I tak owszem, każdy algorytm obliczający cokolwiek jest
równoważny MT, ale równoważność obliczeniowa to nie jest tożsamość na
poziomie rozmowy o algorytmach. Najprostszy przykład (skoro jesteśmy już
w takim temacie) - wszystkie algorytmy sortujące są równoważne
obliczeniowo, chociaż nie ulega wątpliwości, że quicksort i bubble sort
to dwa różne algorytmy.

do góry

On 2012-10-16, M.M. <m...@g...com> wrote:
> Jaki jest przyklad zbioru z czesciowym porzadkiem ktorego nie
> da sie posortowac?

No a żeby nie było tak nudno, że tylko podzbiory i liczby zespolone,
to jeszcze np.:
- zbiór ludzi z relacją "bycia rodzicem",
- zbiór przedmiotów w polu grawitacyjnym z relacją "leżeć na",
- twierdzenia i definicje matematyczne z "korzystania".

:]

No i tak wyglądają (a przynajmniej powinny wyglądąć) zależności
w programowaniu. Tzn. zbiór programów z "wymagać" (na Linuxie
najłatwiej to zauważyć :)), z czym niestety bywa różnie...
Podobnie jest w kodzie (zależności między obiektami, bibliotekami itp).

Ogólnie rzecz biorąc porządek częściowy jest równoważny grafowi
skierowanemu:
a) o cyklach długości max 1 (porządek słaby - z nieostrą relacją),
b) bez cykli (porządek ostry - z ostrą relacją).

Także o ile (przyznaję) wykrycie takiego porządu w najbliższym
otoczeniu bywa niełatwe, to łatwo sobie jakiś stworzyć :).

pozdrawiam,
PK

do góry

W dniu środa, 17 października 2012 01:38:32 UTC+2 użytkownik PK napisał:
> No a żeby nie było tak nudno, że tylko podzbiory i liczby zespolone,
> to jeszcze np.:
> - zbiór ludzi z relacją "bycia rodzicem",
> - zbiór przedmiotów w polu grawitacyjnym z relacją "leżeć na",
> - twierdzenia i definicje matematyczne z "korzystania".
> No i tak wyglądają (a przynajmniej powinny wyglądąć) zależności
> w programowaniu. Tzn. zbiór programów z "wymagać" (na Linuxie
> najłatwiej to zauważyć :)), z czym niestety bywa różnie...
> Podobnie jest w kodzie (zależności między obiektami, bibliotekami itp).
Nom to wszystko fajne przyklady.

> Ogólnie rzecz biorąc porządek częściowy jest równoważny grafowi
> skierowanemu:
> a) o cyklach długości max 1 (porządek słaby - z nieostrą relacją),
> b) bez cykli (porządek ostry - z ostrą relacją).
> Także o ile (przyznaję) wykrycie takiego porządu w najbliższym
> otoczeniu bywa niełatwe, to łatwo sobie jakiś stworzyć :).
Gdy ktos naprowadzi, to sie robi latwe :)
Pozdrawiam

do góry

W dniu środa, 17 października 2012 01:38:32 UTC+2 użytkownik PK napisał:
> Podobnie jest w kodzie (zależności między obiektami, bibliotekami itp).
Biblioteki to chyba jednak nie. Biblioteka A moze korzystac z B, B z C, a
C z powrotem z A. Chyba ze o jakas inna zaleznosc chodzi.
Pozdrawiam

do góry