Vlákno názorů k článku Ruby v příkladech (3) - Začínáme s aplikací od Wejn - Zdravim, je to mirne hnidopiseni, ale: array na prazdnost...
-
Wejn (neregistrovaný)Zdravim, je to mirne hnidopiseni, ale:
- array na prazdnost se da testovat i pres:
array.empty?
coz mi prijde hezci nez:array == []
- nacist soubor pres YAML lze i pres:
@@content = YAML.load_file('file_name')takze ta indirekce pres:File.open("file_name") { |f| @@content = YAML::load(f) }neni nutna (nehlede na to, ze pri pouziti vasi varianty bude drobny problem pri prirazeni do lokalni promenne, pokud jiz neexistovala, nebot bude block-local). - kod na nalezeni nejdelsiho stringu z dane arraye se da trosku upravit na:
return vyber.sort_by { |x| -x[0].length }[0][0]misto puvodniho:return vyber.map{ |pole| pole[0] }.inject do |memo, jmeno| memo.length > jmeno.length ? memo : jmeno end
- array na prazdnost se da testovat i pres:
-
ad 3. kodreturn vyber.sort_by { |x| -x[0].length }[0][0]je sice zdánlivě elegantnější, ale rozhodně je to pomalejší. To je typická chyba lidí, co příliš používají vyžší programovací jazyky a zapomínají co se děje pod kapotou (pokud to vůbec kdy věděli). Pokud teda ruby nepoužívá tak chytré lazy evaluation a výsledek bude stejný. Ale o tom dost silně pochybuji. V daném případě, kdy to pole bude obsahovat 1-3 prvky, je to putna, ale představte si, co by se stalo, použít stejný kód na 10^6 prvků. -
Wejn (neregistrovaný)
Tohle mi fakt bavi :-) Tak my se tady bavime o +-365ti zaznamech ... a vy tu vytahnete 10^6 a jeste se me snazite urazet, ze nad tim nepremyslim (pokud na to tedy vubec mam :) ).
Ja chapu, ze slozitostne je to moje minimalne O(n*log(n)) a to puvodni O(n), protoze ja delam trideni (qsort), kdezto puvodni reseni dela jen 2x pruchod tim polem. Jenze pri ~400 prvcich je rozdil asi tak:
wejn@ns ~ $ ruby a.rb Velikost: 400 user system total real new: 0.000000 0.000000 0.000000 ( 0.001714) orig: 0.000000 0.000000 0.000000 ( 0.001567) user system total real new: 0.000000 0.000000 0.000000 ( 0.001742) orig: 0.010000 0.000000 0.010000 ( 0.004466) user system total real new: 0.000000 0.000000 0.000000 ( 0.001608) orig: 0.000000 0.000000 0.000000 ( 0.001983)pri pouziti nasledujiciho benchmarku, coz zajiste nehraje roli.Az se nekdy v budoucnu rozhodnu operovat nad daty z celonarodniho scitani lidu, nebo tak neco ... tak se opravdu zamyslim nad slozitosti (a treba pujdu pouzit merge sort misto quick sortu) ... ale do te doby bych vas poprosil, abyste netahal 10^6 prvku tam, kde se jedna o stovky.
-
Co to tady na mě zkoušíte? Jestli vám přijde normální místo nalezení extrému pole seřadit a pak si vzít příslušný krajní prvek, tak mě teda ne. Jestli to první řešení dělá dva průchody polem tak je stajně tak špatné, protože to jde jedním. Jestli považujete za lepší řešení, které má o polovinu znaků míň, i když danou úlohu řeší krajně neefektivně, tak by vás měli od programování hnát bičem. Tady jde o princip. Jen nedouk bude hledat extrém řazením. A přesně to jste. Argumenty o velikosti toho pole si strčte za klobouk. Krom toho se nejedná o +-365 ale o 1-3 záznamy. Jenže to by jste si nesměl sedět na vedení a stačí si pozorně přečíst můj vlastní příspěvek. Příště se pokuste místo gonád zapojit tu věc mezi ušima než na něco reagujete.
-
Wejn (neregistrovaný)Jsem moc rad, ze jste mi to vysvetlil ... snad abych vzal klice od zahrady a sel se nacpat senem?
Nejedna se o 1-3 zaznamy, ale o cca 365 (+- nejake duplicity), protoze narozdil od vas pocitam velikost cele "domeny" (vstupu v nejhorsim pripade), ne jen sample vstup.
Docela se mi libi vas pristup - moje reseni je to nejlepsi (tm), i kdyz jeho psanim stravim 2x vic casu.
Ja se zase ridim jinym klise "first make it work, then make it fast". I kdyz by se tu dalo zminit i "you ain't gonna need it" a dalsi principy.
Proste a jednoduse -- dokud pisu trivialni apps tohoto typu, ROZHODNE nebudu studovat slozitost kazde operace (oops, vedel jste, ze odebirani prvku z Array je v Ruby O(n) misto O(1) ???), ale nejdriv to rozchodim a pokud by to nahodou bylo treba, tak teprve budu hledat zpusob jak to zrychlit.
To je diametralne odlisne od navrhu slozitejsich systemu, kde je treba udelat rozumny design pred napsanim radky kodu ... a taky rozmyslet tu slozitost ;)
Btw, jaksi nemam potrebu vas (sveho oponenta) v diskuzi urazet, ac mate rozdilne nazory ... proc vy ano? -
anonymníOK, vy si hledejte extrém řazením, já si o vašich programátorských kvalitách budu myslet své. Vy jste začal první opravovat autora, který použil alespoň adekvátní algoritmus k úloze. Takže moje reseni je to nejlepsi (tm) sedí, ale na vás. Já jsem alespoň dokázal uvést jasný technický argument a tím je složitost. Vy jste nedokázal argumentovat ničím. Já když mám nalézt extrém, použiju algoritmus pro nalezení extrému, vás samozřejmě napadne jako první použít řazení. To je skutečně logické a je na to potřeba 2x méně přemýšlení. Doufám, že váš kód nebudu nikdy muset použít.
-
YF (neregistrovaný)proboha clovece uklidnete se - gdyby slo o 'princip' jak rikate pak
byse tento problem nikdy neresil pres pole - v clanku slo o predstaveni jazyka - a wejnuv zamer byl evidentne ukazat zde pragmaticnost jazyka a jeho konstrukci v cems je jazyk nesporne zajimavy - a vy vypada to uplne nedavate - doporucuju necist root a varit si pravidelne bylinkovy cas - take terapeut by nebyl uplne od veci -
anonymníA proč bych to proboha neřešil přes pole? Opravdu hezký příklad. Kdybych měl v tom jazyku jednopísmenný operátor, který by uvedenou úlohu mimochodem řešil (ve skutečnosti by byl určený k úplně něčemu jinému) a dělal to složitostí O(nn), tak bych samozřejmě bylo dobré ukázat pragmatičnost jazyka právě použitím tohoto operátoru. Bezva. Jdu si dát ten bylinkovej čaj. Root se nám začíná hemžit pragmatiky.
-
anonymníNejde tady o O(x). Jde tady o použití algoritmu řazení na úlohu nalezení extrému. Když potřebuji zašroubovat šroubek, tak si taky neberu kladivo i když v tom konkrétním případě by to byl použitelný nástroj, protože shodou okolností je to do dřeva. Stejně jako od řemeslníka, který si místo šroubováku vezme kladivo, tak ani od programátora, který si místo "šroubováku" vezme "kladivo" jen proto, že je líný šáhnout o přihrádku vedle, ale zrovna ho "držel v ruce" (má to o pár znaků kratší kód), si nenechám zkurvit "koupelnu". Děkuji nechci. Prostě správný nástroj na konkrétní úlohu a je jen projev lenosti, ignorance a omezenosti použít nástroj, který má nota bene větší složitost, jen a pouze z toho důvodu, že se to v daném jazyce napíše o pár znaků kratším kódem.
-
Wejn (neregistrovaný)WTF?
Kdyz uz vymyslite analogie, zkuste alespon takove, ktere budou davat smysl.
Kladivem spravne "sroubek" neutahnete ... zatimco setridenim posloupnosti spravne najdete pozadovany extrem (a shodou okolnosti i ten druhy a jeste k tomu jako bonus kompletni usporadani).
Vase analogie by mozna mohla byt "sroubovak" vs. "vrtacka s nastavcem na sroubovani" (tedy neco jako mnozinova inkluze), ale jen tezko "kladivo" vs. "sroubovak" (disjunktni mnoziny).
Jako chapu vase rozhorceni nad tim, jak jsem lenivy a omezeny ... ale zkuste hrat trochu fer, ok? :) -
jrave (neregistrovaný)
oba jak mali, a oba mimo ;-)))
wejn: jde opravdu o 1 - 3 zaznamy (pokud nema v jeden den svatek vic jak 2 lidi), protoze predtim, jak sis jiste vsimnul, se vyberou zaznamy pouze z daneho dne.
a takovy profesionalni koder jako monsignor pichi by mel vedet, ze ani kod ktery obhajuje neni uplne koser, protoze mi prijde uplne zbytecne nejdriv si delat nove pole obsahujici pouze jmena a pak ho prohledavat.
takze asi takhle :
return vyber.inject { |memo, jmeno| memo.length > jmeno[0].length ? memo : jmeno[0] }vyhrady k implementaci prikladu:
proc uvadet i kombinovanou podobu, kdyz ji jednoduse muzeme dostat spojenim vsech hodnot z daneho dne. ( a odpadne ono hledani nejdelsi varianty ;-))) ?
a jeste, proc muset porovnavat 2 cisla, kdyz by slo porovnavat jedno ? bud zapisovat datum jako xxyy (pokud to nechceme pouzit pro razeni, je jedno, jestli bude prvni mesic nebo den), nebo je nechat ve stejne podobe, a konverzi provadet pri nacitani (treba za pomoci metody yaml.load_documents, i kdyz to by vyzadovalo oddelit kazdou polozku) ?
-
Wejn (neregistrovaný)
No hezky, hezky :-)
Ja jsem si "v zapalu boje" ani neuvedomil, ze to bezi pres "vyber" a ne pres cely vstup. Shame on me! :)
Navic ten vas inject se da taky prepsat "lepe" (aby byl i monsignor spokojen), protoze jak jsem napsal o neco niz -- Enumerable#max bere blok:
return vyber.max { |x,y| x[0].length <=> y[0].length }:-)
Ad spojeni hodnot: no, to mi taky nebylo jasne, ale na miste je argument s jiz existujicim formatem dat (ktery jsem dostal i na svoji pripominku ohledne pouziti jineho formatu datumu).
-
Bez té kombinované podoby jsou skutečně dotazy datum -> jméno jednodušší, ale zase by se zkomplikovaly opačné dotazy (jméno -> datum), pokud bych se např. ptal, kdy je v kalendáři "Petra a Pavla". No a dotazy jméno -> den bych považoval za důležitější a častější, tak jsou data optimalizovaná pro ně.
Připomínku k lepší implementaci hledání beru (a rovnou uvádím, že míst ke zlepšení nebo upřesnění najdete v mých kódech i textech určitě více), ale dal bych asi přednost řešení s metodou max, které uvádí Wejn. A jsem rád, že se ty připomínky na zlepšení objevily v diskusi, když už to nenapadne mne.
Optimalizace, kdy bych datum zapisoval jako jeden Integer (třeba 3.5. jako 305) mi na můj vkus přijde dost drsná. Stejně tak mít v jednom souboru 366 YAML dokumentů (vlastně o něco více díky těm rozděleným jménům). Ale je to můj styl, který nikomu nevnucuju (no, trochu vnucuju tím článkem :-). Netvrdím ale, že je jediný správný. Navíc jsem měl ta kalendářní data už hotová víceméně v tom tvaru, který jsem použil (kalendář jsem kvůli článku neopisoval :-). -
Petr Mach (neregistrovaný)Proč dělat věci složitě, když to jde jednoduše? Výkon by mohl být dobrý důvod, ale ne u tak malého množství dat. Kdybychom se měli hnát za výkonem za každou cenu, pak budeme moci programovat přinejlepším v jazyku symbolických adres a nebudeme mít k dispozici prakticky žádný software. Zamysli se nad svým extremismem.
-
I ty Brute? Já to vzdávám. To je tak velký problém pochopit, že použít na hledání extrému algoritmus na hledání extrému a hnát se za výkonem za každou cenu je přece jen rozdíl? Proč dělat věci složitě, když to jde ještě složitěji pomocí algoritmu pro řazení? OK, pro celý svět je logická úvaha: Hele, mám najít největší hodnotu. Aha, tak to prostě seřadím a vezmu první/poslední prvek a mám to. Jen já jsem pitomec, který se žene za výkonem za každou cenu. Jen já jsem ten blbec, který v jednom cyklu proběhne data a prostě a jednoduše najde ten extrém, protože to bylo přece to zadání a cíl, kterého jsem měl dosáhnout. Já jsem samozřejmě ten blbec, který opravuje autora článku, který shodou okolností použil právě ten logický a jednodušší algoritmus a místo něj navrhuji něco nesrovnatelně složitějšího a výpočetně náročnějšího. Achjo :-( Jdu si dát čaj.
-
Wejn (neregistrovaný)
Ha! A ono nabizi ... jen jsem nevedel o tom, ze existuje i verze, ktera bere blok (proto jsem ju nepouzil).
Takze "nejlepsi" reseni je vlastne:
return vyber.max { |x,y| x[0].length <=> y[0].length }coz uz by se mohlo zamlouvat vsem, huh? :)(mimochodem je nejrychlejsi z tech 3)
-
ad 1. a 2.: Svatá pravda.
ad 3. Nevím proč, ale mně prostě přijde ten můj původní zápis z nějakého důvodu průhlednější. Možná je to ale jen otázka vkusu.
Jinak souhlasím s tím, že držet den a měsíc v Array není úplně ono, ale ten program reflektuje strukturu toho YAML souboru, který jsem neopisoval z kalendáře, ale získal už v (téměř) takovém tvaru. Ani mne ale nenapadá, jak by my mohl pomoci Hash. Možná mi něco uniklo, ale nativní Date objekt reprezentuje konkrétní den včetně roku, což se v tomto případě, IMHO, moc nehodí.
ČLÁNKY DO MAILU