Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Logik

Stran: 1 ... 63 64 [65] 66 67 68
961
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 14. 10. 2010, 12:01:01 »
Ale já jsem říkal, že můj algoritmus prochází nejvýhodnější řešení jako první (zkouší nejdříve nejlevnější balíčky)....
Já jsem to říkal, takže je to pravda?
Dal jsem Ti jasný protipříklad, kde je řešení složeno z nejdražších balíčků.

Citace: jaromír
Zrovna před chvílí jsem to ověřil.
A víš vůbec, že jsou všechny čísla dělitelný pěti? Právě jsem to ověřil: 15 je dělitelný pěti a 35 taky....

Citace: slowthinker
Máš-li určit řešení Ř(n), budeš k tomu potřebovat spojit Ř(1) a Ř(n-1), Ř(2) a Ř(n-2), Ř(3) a Ř(n-3) atd. Musíš tedy znát právě Ř(1) až Ř(n-1).
Ř(0) potřebovat nebudeš.
A to mi má vadit? Tak prostě dokážu něco navíc.

A mimo to, co když opravdu chci nejlevnější sadu nula výrobků?

962
Vývoj / Re: Licence webu psaného na zakázku
« kdy: 13. 10. 2010, 22:59:04 »
Citace
Pokud jsi (jako fyzická osoba) zhotovitelem díla vytvořeného na objednávku, tak vykonavatelem autorského práva je objednatel. Toliko litera zákona.
Ale todle se imho aplikuje pouze ve vztahu zaměstnanec/zaměstnavatel.
Jakmile děláš na ičo, tak už to imho je záležitostí smlouvy mezi Tebou a
objednatelem. Nebo se pletu?

963
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 13. 10. 2010, 17:40:50 »
Citace
Chceš tím říct, že "tvoje" definice je v praxi nepoužitelná, zvlášť pokud je délka vstupu konstantní? Pak souhlasím. Protože v praxi algoritmy pracují s daty ve fixním formátu.
Chci tim říct, že bavit se o ASYMPTOTICKÉ složitosti, tedy vyšetřovat jaké je chování algoritmu při přibližování nějaké veličiny (ať již jde o délku vstupu nebo o cokoli jiného) limitně k NEKONEČNU, je u fixního vstupu blbost, protože fixní vstup se nikdy k nekonečnu blížit nebude, anžto má horní hranici.

Jako bys tvrdil, že třídění má složitost lineární a dokazoval to tím, že když uděláš algoritmus, kterej bude mít na vstupu pevných sto chlívků pro čísla, z nichž některé budou prázdné, ale ty chlívky budou mít libovolnou velikost, tak algoritmus, co ten vstup seřadí bude mít lineární složitost.

Citace
Algoritmus, který by uměl pracovat s libovolně velkým n, je jiný algoritmus (složitější a pomalejší - alespoň dokud nebudou existovat stroje, které umějí zpracovávat libovolně velká data).
1) Nový kolečko? NP třídy jsou definovaný pomocí turingova stroje. Ne na reálnym HW.
2) Zpracovámí dlouhých čísel je i na současném HW vcelku jednoduchá úloha s lineární složitostí (potřebuji jen sčítání a porovnávání). Takže nevím, proč by mělo jít o "pomalejší" algoritmus. Jelikož je sublineární algoritmus je nesmysl (BÚNO vždycky alespoň vstup přečtu), tak předělání algoritmu z fixed width na variable length neudělá s asymptotickou složitostí vůbec nic.
3) Asymptotická složitost z definice prostě nemůže používat pevný zápis vstupu, protože ten je omezen (viz předchozí odstavec).
4) Ty se fakt chceš bavit o složitosti na reálném hardware? A budeš do toho počítat velikosti různejch cache a pamětí? Takže na spoustě míst najednou nastane skok, jak nebude stačit na ta a ta data L1/L2/L3 cache či paměť - jak to do výpočtu zahrneš?
A můžu na tom stroji akcelerovat pomocí GPGPU? A jak do výpočtu zahrneš TLB, asociativitu cache, branch prediction....? A jak chceš řešit asymptotickou složitost, když od určitý velikosti se Ti to nevejde ani na harddisk? A....

Promiň, ale to je prostě blbina, složitost se vždy počítá na nějakém abstraktním stroji a pokud je důležité kódování vstupu, tak na TS.

Citace
Tohle je ale jiná indukce:
Pro krok n je vyžadováno, aby byly vyřešeny všechny kroky od 1 do n-1. Zdůrazňuji termíny "všechny" a "1". Krok pro nulu nemá žádný význam.
?????? Ano, a kdo to stanovil, že se musí začít od jedničky? Báťuška Stalin a tak je to pravda? Nebo to učili v mateřský škole? A oni jsou nějaký dvě matematický indukce? Omlouvám se za sarkasmus, ale fakt by to chtělo, aby sis o věcech, o kterejch píšeš něco zjistil, nebo to alespoň netvrdil tak jistojistě.

Jak např. dokážeš, že kůň na šachovnici n*n doskáče všude, když to platí jen na šachovnici 4x4 a větší? To jako tady indukci použít nesmím, protože se MUSÍ začít od jedničky?

Pro matematickou indukci je nutné dokázat že:
1) P(n_0), n_0 náleží do Z
2)  Pro každé n ze Z: n >= n_0 platí P(n) => P(n+1)
A tím dokážeš, že tvrzení P platí pro každé n větší rovné n_0
http://math.feld.cvut.cz/habala/teaching/dma/dmknih03.pdf

světe div, se, pokud to chci dokázat pro všechna celá čísla, tak dokonce budu dokazovat i
P(n+1) => P(n). Jaká svatokrádež! :-) :-) :-)

PS: (pro složitější důkazy se druhá implikace nahrazuje)
2)  Pro každé n ze Z: n > n_0 platí: P(n_0) & P(n_0 + 1) & ...  & P(n - 1) => P(n)

964
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 13. 10. 2010, 13:05:20 »
jaromir: Složitost se vždy řeší dle nejhoršího možného vstupu dané délky. Navíc program, který nenajde správné řešení vždy je na nic - jak můžeš vědět, že nalezené řešení je správné?
Stejnětak čas kdy se najde optimální řešení je nic neříkající údaj: jediný, co je směrodatný je čas, kdy algoritmus doběhne. Protože než doběhne, tak nevíš, jestli to optimum je opravdu optimum.

965
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 13. 10. 2010, 12:56:31 »
slowthinker:Fixní élka vstupu u složitosti je nesmysl. Už třeba proto, že se bavíme o asymptotické složitosti, tedy o složitosti kdy délka vstupu se limitně blíží k nekonečnu. Takže buďto můžeš prohlásit n za konstantu, nebo mu povolit růst do nekonečna (to ale nejde s fixní délkou vstupu).
Ono pokud měříš složitost dle délky vstupu pro n zadané fixní délkou, tak samozřejmě nejdéle to vždy poběží, když n je maximální. A vstup je furt stejně dlouhý, takže vlastně měříš složitost algoritmu: "jaký je nejlevnější košík pro C", kde C je konstanta (2^délku n). Ale to je už trochu jinej algoritmus.
(např. proto, že neumí řešit všechny případy).

Seřazení dvaceti čísel variabilní délky má taky lineární složitost. (s délkou čísel roste jen lineárně) - a přesto má řazení složitost větší: n*log(n).



Citace
Tohle tvrzení k důkazu nijak nepřispívá, ze dvou prázdných košíků stejně nic nesestavíš. S tou indukcí bych na tvé místě začal od jedničky... 
Při indukci je vyžadováno, aby pro krok n byl vyřešen krok n-1. Takže mám dvě možnosti, buď vyřeším úplně triviální případ pro nulu (byť z nulového košíku nikdy další skládat nebudu), nebo pro jedničku, kdy je to složitější. Jsem línej člověk a tak radši vyřeším tu nulu. :-P.
PS: Jedička se pak vyřeší jako běžnej krok, holt se tam prostě půlka neuplatní, protože neexistuje žádná vhodná kombinace A a B, ale co mi po tom?

jaromír:
V čem je lepší?
Ty jen projdeš stromovou strukturu.... :-) Že je velikost té stromové struktury exponenciální (2^n vrcholů stromu)ty už jaksi nevadí.... Vždyť sám píšeš, že pro větší počty to bude pomalý.
Jestli chceš přesně vědět, v čem je dynamický programování lepší, tak třeba v tom, že pokud máš balení s jedním a dvěma kusama, obě za korunu kus, tak zatímco dynamické programování rozvine jen jedno řešení a u druhého zjistí, že není lepší a zahodí ho už hned jak vezme do ruky to dvoukusový balení, tak ty rozvíjíš obě možnosti a zjistíš, že jsou ekvivalentní teprve poté, co prohledáš celý podstrom.
Exaktnějc řečeno, tvoje řešení není pseudopolynomiální, zatímco dynamické programování ano.

Citace
Tímto způsobem se mi nemůže stát, aby se nejvýhodnější sestava objevila na konci hledání, neboť by musela být kombinací těch nejdražších balíčků.
Ach jo. Opravdu?
Chceš 1600 kusů
400 kusů celkem za 4000
1 kus za 10000000
+ hromada 300 - 399 kusových balení za cenu pod 3000.
Výsledná kombinace bude obsahovat 4x4 kusy, ale na tu přijdeš skoro až jako poslední.

Další věc je, že i když přijdeš na nejlepší kombinaci rychle, tak pokud jsou ceny hodně podobné, tak stejně zbytek stromu musíš projít hodně do hloubky, než přijdeš na to, že
ostatní kombinace jsou horší.





966
Vývoj / Re: Potřebuji radu ohledně programovacího jazyku
« kdy: 12. 10. 2010, 20:00:54 »
Já taky neříkám, ať programuje ve fortranu. :-) Já jsem se ohrazoval proti tomu, že gcc je na špici co se týče optimalizací výslednýho kódu. Samozřejmě, že na normální psaní je úplně jedno, jakej se používá kompilátor, pokud teda kompiluje korektně a nepadá (takže bych vyloučil ten borland, se kterým jsem si svýho času dosti užil...).
Na GUI programování bych mu doporučil buďto javu, nebo python + nějakej framework, nebo C# - co je podle jeho gusta.

967
Vývoj / Re: Potřebuji radu ohledně programovacího jazyku
« kdy: 11. 10. 2010, 22:36:38 »
borlandy a watcomy .... no ty sem opravdu nikde neviděl doporučovat - třeba borlandí C++ kompilátor je děs běs. Ani nevim o tom, že by byl někde jinde než na widlích. Co mám zkušenosti, tak nejvíc se používá icc/ifort (kupodivu i na AMD dává výtečný výsledky) nebo kompilátory od portland group. GCC se většinou používá jako "last option" když snaha o překlad něčim "rozumnym" selže.

Nevím, co je myšlený spojením "klasická PC platforma". Jestli je tím myšlený Windows, tak kolik lidí překládá na windows výkonnostně náročný programy? Já snad ve svém okolí neznám žádného, a to se pohybuju kolem lidí, co dost počítaj. V podstatě všichni numerici, fyzici, aerodynamici atd... co znám počítaj na linuxu.
Aby taky ne - ono aby člověk používal programy, který se výkonem právě strefujou do možnosti PC je dosti nepravděpodobný. A jakmile jsou nároky na výkon menší, tak proč by řešili kompilátor, jakmile je rychlost PC omezuje, tak maj někde cluster a na clusteru linux.

IMHO jedině, kde je smysluplný řešit rychlost na widlích, je kompilace výkonostně náročných programů pro druhé, který linux nemaj (např. enkodéry videa, statické výpočty apod.). Jenže kolik lidí todle dělá - v poměru k počtu lidí ve všech různejch univerzitách, výzkumácích i ve vývojovejch centrech komerčních firem?

968
Vývoj / Re: Potřebuji radu ohledně programovacího jazyku
« kdy: 11. 10. 2010, 18:03:25 »
Ehm, co se týče optimalizací (alespoň pokud dobře chápu že je tim myšlena optimalizace přeloženého kódu), tak rozhodně se nepřetahuje gcc s MS. Pro výpočtářské kompilace se používaj profi kompiláory (ifort, PGI) a rozhodně ne GCC (ze zkušenosti kód cca 20% pomalejší, nehledě na někdy obtížnější linkování matematickejch knihoven, který bejvaj k proprieálním kompilátorům přibalený).
MS kompilátory pak vypadávaj už čistě díky platformě, protože hodně málo kdo počítá na windowsech (nemluvě o výpočetních clusterech - ty snad na ničem jinym než unixu/linuxu nejsou).

Jinak poměrně progresivním trendem pro vývoj vědeckého software je právě kombinace vysokoúrovňového jazyka pro zápis samotného vnějšího algoritmu s voláním vysoce optimalizovaných funkcí v C či Fortranu. Viz např. scipy, numpy, fy2py, pyfort atd.. v pythonu.

969
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 11. 10. 2010, 14:04:51 »
Nebuď dogmatik. To přiřazení tam je - akorát v jiný formě.
Je jím první řádek cyklu. Schválně jsem čekal, jestli se někdo chytne :-)
Klasický dynamický programování jede "po prvcích" - ale já jedu po "počtech".
Po prvcích by šlo taky - pak bych musel s každým prvekm vytvořit
všechny možné kombinace s dosud existujícími kombinacemi a nebylo by to tak elegantní.


A rekonstrukci košíku jsem sem nedal úmyslně - důležitý je pochopit myšlenku a ta se snadnějc pochopí z tohodle, a kdo to pochopí, ten si to snadno dopíše....

---

Jinak ono dynamický programování je v podstatě totéž, co B&B, akorát prohledává stavovej prostor v jinym pořadí.
Mů invariant je: než sestrojím stav s počtem prvků X, sestrojím všechny stavy s počtem prvků menším než X.
Tvuj invariant je: než v dané konfigurac košíku na Y tém místě v košíku vyzkouším prvek X, vyzkouším na tom místě všechny prvky menší než X a větší rovny než prvek na místě Y-1.

Že by ten Tvůj invariant byl jednodušší se mi moc nezdá.

Důkaz "dynamického" algoritmu je jednoduchá indukce dle ceny:
- Je-li košík N minimálním (má nejmenší možnou cenu) pro počet prvků n, pak jakékoli dva košíky A a B, pro které platí A+B=N (sesypání košíků) jsou minimální.
Sporem: není-li tomu tak, pak BÚNO existuje stav minimální košík A' a tedy i cena N' = A' + B je menší než N, což je spor.
- Pro nula prvků je nejlevnější prázdný košík.
- Vyřešil-li jsem stavy 0..n-1, pak každý minimální košík pro n je kombinací dvou minimálních košíků pro 1..n, nebo se sestává z jednoho balení. (triviální důsledek předchozího lematu)

V případě B&B to imho takhle elegantně nepůjde.

970
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 10. 10. 2010, 23:26:32 »
Právě že to dynamický programování je i zdaleka nejjednodušší algoritmus na napsání. Odhadem na 10 řádek v čemkoli (no dobře, assembler možná dvacet). nehledejte problém tam, kde neni.

Kód: [Vybrat]
Inicializuj mincena[1..n] na nekonečno.
pro i z 1 ... n
 pokud existuje balení o i prvcích: mincena[i] = cena i-prvkového balení
 pro j z 1 ... i/2
    pokud mincena[j]+mincena[i-j] < mincena[i]: mincena[i] = mincena[j] + mincena[i-j]

That's all folks. Tádydádydádydááá.... :-)

971
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 10. 10. 2010, 22:09:37 »
Já nevim, imho to neni o nic jednodušší než dynamické programování. Prostě se mi to zdá jako snaha vymejšlet kolo....

972
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 10. 10. 2010, 20:53:14 »
Jo, už jsem to pochopil. Fuj. Víc se k tomu říct nedá. Pročti si diskusi a najdeš tam několikrát zmiňovaný daleko rychlejší řešení. Heslo "dynamický programování".

973
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 10. 10. 2010, 19:46:41 »
A čím se to liší od předchozího algoritmu?

974
Vývoj / Re: Optimální algoritmus výpočtu
« kdy: 10. 10. 2010, 17:23:09 »
Promiň, na todle se nedá reagovat. Chaotickej kód bez jedinýho komentáře s jednompísmenejma proměnejma u kterejch není jasný co vlastně znamenaj, navíc bez jakýhokoli rozumnýho formátování.

Nerozumím, co si tím chtěl říct, ale je to jasnej příklad, jak se programovat NEMÁ.

975
Odkladiště / Re: Zveřejňování bezpečnostních chyb?
« kdy: 10. 10. 2010, 15:40:31 »
IMHO můžeš, pokud zveřejněním neporušíš žádné NDA.

V rámci žurnalistiky můžeš dokonce citovat části autorských děl, čili postih díky autorským právům nijak nehrozí a nenapadá mě nic jiného, co by mohlo zveřejnění bránit.

V USA se nesmí zveřejňovat nic, co slouží k prolomení ochrany - ale pokud autor už díru zalepil, tak by to snad bylo legální i tam...

Stran: 1 ... 63 64 [65] 66 67 68