eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingsortowanie
Ilość wypowiedzi w tym wątku: 567

  • 251. Data: 2012-10-16 23:32:59
    Temat: Re: sortowanie
    Od: Baranosiu <r...@w...pl>

    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


  • 252. Data: 2012-10-16 23:50:53
    Temat: Re: sortowanie
    Od: "M.M." <m...@g...com>

    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


  • 253. Data: 2012-10-16 23:57:10
    Temat: Re: sortowanie
    Od: bartekltg <b...@g...com>

    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


  • 254. Data: 2012-10-17 00:04:07
    Temat: Problemy inzynieryjne, bylo: sortowanie
    Od: Andrzej Jarzabek <a...@g...com>

    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.


  • 255. Data: 2012-10-17 00:05:35
    Temat: Re: sortowanie
    Od: "M.M." <m...@g...com>

    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.


  • 256. Data: 2012-10-17 00:15:30
    Temat: Re: sortowanie
    Od: Baranosiu <r...@w...pl>

    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).


  • 257. Data: 2012-10-17 00:19:06
    Temat: Re: sortowanie
    Od: Andrzej Jarzabek <a...@g...com>

    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.


  • 258. Data: 2012-10-17 01:38:31
    Temat: Re: sortowanie
    Od: PK <P...@n...com>

    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


  • 259. Data: 2012-10-17 01:58:30
    Temat: Re: sortowanie
    Od: "M.M." <m...@g...com>

    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


  • 260. Data: 2012-10-17 02:02:49
    Temat: Re: sortowanie
    Od: "M.M." <m...@g...com>

    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

strony : 1 ... 20 ... 25 . [ 26 ] . 27 ... 40 ... 57


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

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

Wzory dokumentów

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