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 - zboj

Stran: 1 ... 85 86 [87] 88 89 ... 101
1291
Vývoj / Re:Komplexita parsingu
« kdy: 21. 10. 2015, 11:25:37 »
O jaky typ gramatiky se jedna?
Vždyť to tam píše.

Aha me se nejak spojilo LLVM s C++ a to rozhodne neni CF gramatika.
To ne, v případě C++ je parsing turingovsky úplný (díky templatům).

1292
Vývoj / Re:Komplexita parsingu
« kdy: 21. 10. 2015, 10:47:26 »
Ve škole nás učili, že CF parsing je O(n^3). Na stránce o LLVM jsem se teď dočetl, že parsing je NP-úplný. Trochu mě to zmátlo, co mi uniká?
Rozpoznání, zda CF gramatika nějaké slovo přijímá, je skutečně za použití dynamického programování vždy nejvýše O(n^3). Nicméně jakmile se generuje nějaká sémantická reprezentace (AST nebo něco ekvivalentního), je z toho rázem NP-těžký problém a v některých (prakticky ale nezajímavých) případech může jít o problém nerozhodnutelný - snadno lze sestavit gramatiku, podle níž vyžaduje parsing exponenciální počet kroků vzhledem k délce vstupu. V praxi to moc nevadí, vstup je typicky rozdělen do "segmentů", takže místo O(2^n) to ve skutečnosti je O(2^n_1) + ... + O(2^n_k), kde n_i jsou malá čísla (a v mnoha praktických aplikacích to vůbec exponenciální není, ale jde o nejhorší případ). V LLVM jde mimochodem o něco jiného, némlich o časovou komplexitu inference typů, která se provádí až po parsingu, kdy už existuje AST.

1293
Vývoj / Re:Komplexita parsingu
« kdy: 21. 10. 2015, 10:40:35 »
O jaky typ gramatiky se jedna?
Vždyť to tam píše.

1294
Teď v návodech co se k autům dávají jsou popsaní všelijaké přihrádky, ale co se týká možných závad, tak pokud se o nich píše, tak to končí radou "...a obraťte se na autorizovaný servis."

Jo, jenze auta drive byla konstruovana tak, ze se s tim doma dalo neco delat. Ted treba na Opelu Kadetu se neda vymenit termostat bez demontaze rozvodneho remenu a deklu. WTF??? A pred par dny jsem si muzel najit na YT video, abych zname vymenil zarovku ve Fordu Mondeo. Kristova noho, on se tam musi vymontovat reflektor, aby se k tomu clovek dostal! Dva srouby na reflektoru odsroubovat, jeden povolit a dva na odsroubovani masky, to vse kvuli posrane zarovce. A to to tam ani nesedi na nejakem poradnem dorazu, aby bylo zaruceno, ze po remontazi clovek nema ujeta svetla. Takze pocitam, ze po vymene zarovky muzete jit nechat sestelovat svetla. No ktery kreten tohle vymyslel? Asi nejky genius, co na studiich usoudil, ze nektere predmety jsou na hovno. Vykastrovat a napichnout na kul!
:D

1295
Vývoj / Re:Kvantové výpočty
« kdy: 19. 10. 2015, 15:29:35 »
Právě píšu simulátor kvantového počítače a zajímalo by mě: když jsou stav i operace plné komplexních čísel, co zaručuje, že výsledek je vždy reálné číslo?
Těch čísel tam je víc. Po kolapsu (zániku superpozice) zůstane nějaký vlastní stav, což je v případě qubitů nějaké binárně zapsané - z definice vždy reálné - číslo. Pravděpodobnost stavu i je <αi|αi> a takový skalární součin je vždy reálný (protože z im=-im plyne im=0). Střední hodnoty pozorovatelných veličin (<ψ|Â|ψ>) jsou reálné díky již zmíněné hermitovskosti příslušných operátorů.

1296
Vývoj / Re:Kvantové výpočty
« kdy: 19. 10. 2015, 15:23:41 »
Právě píšu simulátor kvantového počítače a zajímalo by mě: když jsou stav i operace plné komplexních čísel, co zaručuje, že výsledek je vždy reálné číslo?

Vlastnosti operátorů, jež popisují změny stavů kvantových systémů – je požadováno, aby vždycky šlo o hermitovské operátory, jejichž charakteristickou vlastností je, že mají reálné spektrum.

(ve skutečnosti je požadavek jen na reálnost spektra, čemuž všechny hermitovské operátory vyhovují; existují ale i nehermitovské operátory s reálným spektrem, ale to už bychom se dostali do oblastí pole kvantové fyziky zatím ještě značně nezoraného)
Změny stavů popisují unitární operátory. Hermitovské operátory popisují pozorovatelné veličiny.

1297
Jo. Kdyby tu někdo založil téma o správném kojení, tak se asi dozvíme, že J to umí nejlíp a všichni kolem jsou kreténi.

Tak az J bude kojit, doufam, ze da na web fotky. Ale doporucoval bych, aby to delal pod dozorem nekolika lidi, kteri zachrani dite v pripade, ze na nej J zacne rvat, ze je kreten a bude s nim chtit mlatit o zed.
:D

1298
Studium a uplatnění / Re:K čemu školy?
« kdy: 02. 10. 2015, 10:44:34 »
Záleží, odkud titul je.

Záleží, nesmí být z IT matfyz, to je pak tutovka.
Abych to jenom nehaněl, tak jsou jiné ústavy kde jsou na tom líp.

Matfyz nebo jaderka. Obě mají zastoupení lemplů podobné jako jiné techniky, akorát absolventi mají asi desetkrát vyšší sebevědomí :D V praxi jsou pak ty slabší kousky úplně stejně k ničemu jako třeba někdo z VŠE. Takže určitě záleží na tom odkud, ale nemůžeme se bavit západní Indii, kde ani školství nefunguje a firmy si sem akorát jezdí zakládat levné pobočky.
Z matfyzu lemply celkem spolehlivě odfiltruje první semestr.

1299
Studium a uplatnění / Re:K čemu školy?
« kdy: 02. 10. 2015, 01:49:14 »
Nevím, co se na těch školách učí, ale mám s jedním vysokoškolákem dost podobnou zkušenost, co se týče sítí. Absolutní základní neznalosti, totální neschopnost porozumět obyčejnému statickámu routování, naučený poučky, který nebyl schopnej pochopit, natož převést do praxe... z fleku by mi na to napsal skripta, ale tím by skončil. Nechci tím odsuzovat paušálně všechny vysokoškoláky, ale z vlastní zkušenosti vím, že titul rozhodně není žádnou zárukou kvality.

Záleží, odkud titul je.

1300
Studium a uplatnění / Re:Co má v IT nejlepší budoucnost?
« kdy: 01. 10. 2015, 19:41:34 »
kit o getteroch klasicky trepe, uz pol roka nedal ziadny konkretny priklad


Ten "trepe" o všem.

1301
Studium a uplatnění / Re:K čemu školy?
« kdy: 01. 10. 2015, 19:40:02 »

A matfyz si vytyčil za cíl připravovat na náročná povolání, tedy je náročný.

V oboru matematiky a fyziky možná. V oboru budoucí povolání v IT nikoliv, absolventi mají trestuhodné neznalosti z praktického IT.

O jaké neznalosti konkrétněji jde?
Žádné, jsou to kecy, IT je na matfyzu na velmi dobré úrovni.

1302
Vývoj / Re:Jazyk pro matematické výpočty
« kdy: 28. 09. 2015, 15:57:05 »
Pro HMM a SAT zrovna existují knihovny v C, takže jdou volat z v podstatě libovolného jazyka. Z obecného pohledu se hodí pro matematické a obecně symbolické výpočty Swift díky své syntaxi a typovému systému (Apple slíbil vydat otevřený překladač pro Linux). Práci s tenzory pak můžu zapisovat elegantně matematicky, např. násobení matic bude
Kód: [Vybrat]
let A = Tensor(indices: .Contravariant, .Covariant)
let B = Tensor(indices: .Contravariant, .Covariant)
...
let C = A.i.j * B.j.k
Pro manipulaci s vektory lze mít jeden operátor pro násobení dávající skalární, vektorový nebo tenzorový součin podle kontextu:
Kód: [Vybrat]
func *(t1:Vector, t2: Vector) -> Scalar { ... }
func *(t1:Vector, t2: Vector) -> Vector { ... }
func *(t1:Vector, t2: Vector) -> Tensor { ... }

A tak dále. Swift lze přímo míchat s kódem a knihovnami napsanými v C/C++ a využívat OpenCL, OpenMP a podobné knihovny/techniky pro zrychlení výpočtu. Např. ve Stanfordu už Swift pro matematické/symbolické výpočty používají.

1303
Vývoj / Re:Převod výrazu na AST
« kdy: 28. 09. 2015, 10:22:38 »
To jde jednoduše v C++ (předefinováním operátorů, jak už tu zaznělo), nicméně pro iOS existuje elegantnější řešení ve Swiftu. Omezíme-li se na sčítání a Double, jde to takto:

Kód: [Vybrat]
protocol Expression {
    func evaluate(vars:[String:Constant]) throws -> Constant
    var string:String { get }
}

extension Expression where Self:CustomStringConvertible {
    var string:String { return description }
}

protocol Constant : Expression {}

extension Constant {
    func evaluate(vars:[String:Constant]) throws -> Constant { return self }
}

extension Double : Expression, Constant {}

enum ExpressionError : ErrorType {
    case FreeVariable
    case UnhandledType
}

struct Variable : Expression {
    let name:String
    init(name:String) { self.name = name }
    func evaluate(vars:[String:Constant]) throws -> Constant {
        if let value = vars[name] { return value }
        else { throw ExpressionError.FreeVariable }
    }
    var string:String { return "$" + name }
}

struct Var {
    static var x:Variable { return Variable(name: "x") }
}

struct PlusExpression : Expression {
    let lhs:Expression
    let rhs:Expression
    init(lhs:Expression, rhs:Expression) { self.lhs = lhs; self.rhs = rhs }
    func evaluate(vars:[String:Constant]) throws -> Constant {
        return try lhs.evaluate(vars) + rhs.evaluate(vars)
    }
    var string:String { return lhs.string + " + " + rhs.string }
}

func +(lhs:Expression, rhs:Expression) -> Expression {
    return PlusExpression(lhs: lhs, rhs: rhs)
}

func +(lhs:Constant, rhs:Constant) throws -> Constant {
    if let x = lhs as? Double {
        if let y = rhs as? Double {
            return x + y
        }
    }
    throw ExpressionError.UnhandledType
}

let expr = Var.x + 5
print(expr.string)
print(try expr.evaluate([ "x": 3 ]))

Triviálně to jde samozřejmě rozšířit na řetězce, komplexní čísla, matice atd.

1304
Vývoj / Re:Jazyk pro matematické výpočty
« kdy: 26. 09. 2015, 23:13:43 »
HMM nejsou moc složité (a algebra tam nikde není).

Je tam lineární algebra.

IMO s tou jednoduchostí to je jako u SATu - triviální problémy vyřešíte učebnicovým algoritmem (konfliktem řízené učení klauzulí), který na těžší problémy nestačí.
Lineární algebru jsem tam teda nikde neviděl. Zato hodně pravděpodobnosti.
Pro HMM ale existuje jen ten "učebnicový" algoritmus, na rozdíl od SAT se urychlit nedá.

1305
Vývoj / Re:Jazyk pro matematické výpočty
« kdy: 26. 09. 2015, 22:18:57 »
Domnívám se, že v jakémkoliv jazyce jde naprogramovat cokoliv. Ale předpokladem je mistrovské zvládnutí daného jazyka a v tomto případě i detailní znalost problematiky HMM a SAT, související algebry a schopnost tohle vtesat do algoritmů. Pokud tohle zvládáš, tak tě upřímně obdivuju.

Spíš bych doporučoval si najít vhodné knihovny nebo celý framework zabývající se problematikou. A s tím už přijde i požadavek na jazyk, který tento framework potřebuje k obsluze.

Příklad: já si teď tak trošku hraju s neuronovými sítěmi, machine learning apod. V této oblasti teď hodně jede framework TORCH. A ten se světem komunikuje v jazyce LUA. Což je skriptovací jazyk nad C. A celé se to opírá o OpenBLAS, což je knihovna pro lineární algebru psaná v C a Fortranu.

Tím chci říct, že není nutné omezit se na jenom jeden jazyk, klidně vem z každého to nejlepší.

PS: ten TORCH+LUA je docela porod, ale kdybych to měl bastlit od píky (tady řekněme násobení matic) sám, tak s tím seknu dávno.
HMM nejsou moc složité (a algebra tam nikde není). SAT je ale oříšek, moderní metody jsou poměrně komplikované a naivní implementace je pomalá. Nicméně nikdy neuškodí zkusit si algoritmus napsat, člověk aspoň problematiku lépe pochopí.

Stran: 1 ... 85 86 [87] 88 89 ... 101