Milyen rendezéseket szoktatok használni?

7-es vagyok: Az ilyen programokból mi derül ki mégis? hogy egyik rendezés gyorsabb mint a másik? Naná, nyilván, ezt nem kell bebizonyítani, tudja mindenki, ez rendben is van.

De nincs értelme a gyakorlatban ezzel vacakolni, amikor már rég megvalósították mindet, akkor mégis miért kellene nekem vagy bárkinek újra és újra leprogramozni? Pár tizedmásodpercért? Nem hiszem, hogy éles, valós példán, ami nem valami specializált szimuláció, hanem egy gyakorlatban is használt, általános probléma ennek lenne értelme.

Az erőforrás egyre olcsóbb, ami drága az az idő, nem az érdekli a főnököt, hogy 1 vagy 1.5 másodperc alatt fut le, hanem hogy egy vagy két nap alatt lesz-e kész. Sehol nem tolerálják a pepecselést, finomítgatást. Maximum szabadidődben refaktorálhatsz ahogy jólesik, nincs mindenkinek családja, élete, ez rendben is van, de biztos lehetsz benne, hogy a proprietary szoftverekben elkerülik a rendkívül drága és kis nyereségű kódoptimalizálást, határidőre ki kell tolni a cuccost, a dedline mindennél fontosabb. Talán majd egy későbbi verzióban, esetleg, de ha a tesztek határértéken belül maradnak a kutyát nem érdekli.

#15:

"Semmi értelme időt elcseszni ilyesmire, hogy a végén 0.001 ezred másodperccel gyorsabb legyen a kód, ez sehol sem szempont."

Szerinted nem szempont. Egyébként sem milliomod másodpercekről van szó, hangsúlyoztam, a nagy elemszámot.

Csak tudod, vannak olyan helyek, ahol a deadline mellett egyéb szempontokat is figyelembe vesznek. Pl. mikrokontrolleres fejlesztések, ahol az erőforrások szűkösek, a firmware-nek bele kell férnie egy 5 USD-s eszközbe, mert csak azért nem fog a százezer, netán félmillió példányban kigyártandó kütyüjébe 10-15 dolláros procit venni az ötös helyett, mert te nem vagy képes igényesen leprogramozni egy sortert. Bizonyos körülmények között még az architektúrára (8,16,32 bit) is figyelemmel kell lenned. Ha érdekel netán, elmondom miért. És nem, nincs mindenhol sql.

És adott helyeken, ha te nem vagy figyelemmel a bejövő adatokra és nem annak megfelelően választasz algoritmust, akkor ha ezt észreveszik, szépen felállítanak az asztaltól és elkisérnek a kijáratig, ahol elbúcsúznak tőled.

Ez a mondatod pedig:

"Programozás-történelmi okokból még tanítgatják, mint a lyukkártyát meg az ENIAC-ot, de gyakorlatban nem kell használni, felesleges."

Már ne is haragudj, de a vicc kategóriája. Lyukkártyát már nem használnak, az ENIAC-ot megléptük egymilliószor, de rendező algoritmusokat ma is használnak sok helyen.

Ahogy az a kijelentésed is tévedés, hogy bármely fejlesztőeszközbe implementálva lenne az összes elemi algoritmus, vagy akár csak a rendező algoritmusok. Ezt nem is tudom, honnan veszed.

Amúgy, a delphi-ben pl. implementálva van sok minden. Azt is lehet mondani, gondolni, nyilván profik által. Mégis, tele a net komponens csomagokkal, amelyek fényévekkel jobbak, mint a beépítettek. A "gyári" Indy komponenscsomag annyira shit, lassú, megbízhatatlan volt, hogy arra nincsenek szavak.

---------------- Alábbiakat már idézem:

Rendezésnek nevezünk egy algoritmust, ha az valamilyen szempont alapján sorba állítja elemek egy listáját. A rendezési algoritmusok a programozás kezdete óta jelen vannak és érdeklődés középpontjában állnak, mivel egy rendezett adathalmazzal több és hatékonyabb műveletek végezhetők, mint egy rendezetlennel.

A gyorsrendezés általában gyorsabb az egyéb rendezéseknél, mert a belső ciklusa a legtöbb architektúrán nagyon hatékonyan implementálható, és _>>> az adatok jellegének ismeretében <<<_ az algoritmus egyes elemei megválaszthatóak úgy, hogy csak nagyon ritkán fusson négyzetes ideig.

Tehát, az adatok jellegének ismeretében választunk algoritmust, ezt pedig akkor tehetjük meg, ha hatékonyság analízist végzünk a bejövő adatokon. Nem csak a hasunkra ütünk, hogy jó lesz mondjuk a heap és kész, lesz.rom..

Majd legfeljebb szív vele a megrendelő, vagy a user.

Újra oda lyukadunk ki: speciális esetek, közvetlen hardware programozás, firmware-ek, mikrokontrollerek. Szerintem teljesen nyilvánvaló mindenki számára, aki ezen a pályán ténfereg, hogy minél közelebb vagyunk a vashoz, annál szűkebb a keret, nincs annyi lehetőségünk, nincs annyi erőforrás, nem bízhatunk mindent a nyelvre, mert az is egyre "butább", egyre több dolgot kell "kézzel" megcsinálnunk. Ebből a szempontból pl:

Deplhi > C > ASM

Rendben? És egy szóval sem mondtam, hogy minden algoritmus minden nyelvbe ("fejlesztőeszköz"? az honnan jött?) implementált lenne.

Feleslegesen kardoskodunk, csak azt akarom ezzel az egésszel megvilágítani a kérdező előtt, hogy nem görcsöljön órákat/napokat egy rendezésen, használja amit a nyelv kínál, és kész, a valóságban csak speciális, hardware-közeli esetekben lesz szüksége az ilyesmikre.

Viszont mintha te azt sugallnád neki, hogy igenis fontos, hogy amint megtanulta a hello word-öt meg az "első 1000 prímszámot kiírni visszafelé" létfontosságú programokat, ne is menjen tovább amíg nem tud quicksortolni? Én ezt vitatom csak.

"Viszont mintha te azt sugallnád neki, hogy igenis fontos, hogy amint megtanulta a hello word-öt meg az "első 1000 prímszámot kiírni visszafelé" létfontosságú programokat, ne is menjen tovább amíg nem tud quicksortolni? Én ezt vitatom csak."

Dehogy! Azt ő kérdezte, én meg válaszoltam. Nem sulykolok én bele semmit. Azt viszont hiszem, vallom, hogy akkor tanul meg programozni, ha ismeri ezeket az algoritmusokat. Ha megír egy quick sortot, akkor a nyelv elemeit fogja használni, gyakorol, tanul, felismer, megért összefüggéseket. Az elemi algoritmusok kellenek is. Kivédhetetlenül. Ilyenekből fog építkezni. Ha majd oda kerül, és azt mondják neki, te, írj már egy RLE kompresszort, akkor válaszolja azt erre, hogy:

bocs, de azt én nem tanultam? Vagy körbe néz a neten és ha talál egy (vagy hibás, vagy jó) implementációt, akkor azt fogja tálalni? Esetleg ugyanezt teszi a sorttal a láncolt listával, netán összetettebb algoritmusokkal is?

Nagyon jól csinálja ha implementál, sőt, az összes sort rutint (nincs is túl sok) tanulmányozza, értse át, tudja meg minek mi az előnye, hozadéka, hátránya. Így fejlődik a legjobban.

Hu, hat a vitaba nem szallnek be :D

Bubble ha kodbol kell rendezni, amit en masolom be a sablonobol - legtobbszor egyszerubb ha pl sajat osztalyt kell datum alapjan sorrendbe rakni. Oke, tudom, a List Sort-ja is megcsinalja, de lusta vagyok interfeszt megvalositani hozza. Ket kulon tomb sorrendbe rakasa egy tomb alapjan meg tobb munka (legalabb ket perccel tobb, es kinek van arra ideje?)

Egyeb esetben pl datumok es szovegeket a List.Sort megcsinalja.

A maradek (kb 95% eset) pedig mar sortolva kerem le SQL-bol az adatokat :)