Matematické Fórum

↑ MichalAld:

To snad ne. Ve výrazu a*b*c je to sice jedno, ale násobení a dělení má stejnou prioritu a výraz a/b*c nelze vyhodnocovat jinak, než zleva doprava.

Pokud jde o logické podmínky, tam se (pokud vím) dá nastavit, zda se mají vyhodnocovat vždy komplet, anebo jen do jasného výsledku.

↑ Aleš13:

S omezeným rozsahem typů by měl samozřejmě programátor počítat. Platí např.

[mathjax]\Huge e\approx \frac {(n+1)^n} {n^n} =\left( \frac {n+1} {n}\right) ^n[/mathjax]

ale zatímco pravý výraz je pro program v pohodě a n lze zvyšovat skoro do aleluja, levý zhavaruje už pro velmi malé n. A obávám se, že žádný optimalizátor programu s ním nic nenadělá.

To je ale zase trochy jiná písnička.

Myslím, že co se objevily objektové jazyky a přetěžování operátorů, tak se na tyhle věci klade větší důraz. Protože v objektových jazycích můžeme operátory používat i pro jiné než základní typy, násobit tedy nemusíme jen čísla, ale také  třídy, s tím, že překladač netuší, co to to násobení ve skutečnosti bude. Nebo můžeme mezi sebou násobit "properties" - což se sice navenek tváří jako proměnná, ale vevnitř to může něco dělat.

Myslím, že asociativita operátorů je celkem standardní pojem. To nevylučuje, že nemusí být definovaná (že může být jakákoliv), ale co jsem si všiml, tak v C-like jazycích bývá daná dost přesně. Přijde mi nesmysl, aby výraz typu

a*b/c*d*e/f/g*h se jednou počítal tak jak jsem ho napsal a podruhé třeba a*b*d*e*h/c/f/g.

Je samozřejmě nesmysl, aby se takovýhle výraz vyhodnocoval zprava, ale to parser obecně neví, a musí se mu to říct v rámci definice gramatiky jazyka.

Intuitivně bych řekl, že u LL jazyků se všechny výrazy vyhodnocují zleva. U LR jazyků (jako je céčko) je to nejspíš jedno. Jsem si téměř jistý, že v céčku se podmínky vyhodnocovaly zprava. V C# se zase naopak vyhodnocují zleva.

A samozřejmě nic nebrání podmínky psát tak, aby na tomhle nezávisely, tedy je vhodně ozávorkovat, nebo to rozdělit do více příkazů.

Ale nic z toho přece nesouvisí s obecným problémem asociativity operátorů, která určuje, v jakém pořadí se bude vyhodnocovat vícenásobný výraz.

Já teda nechci tvrdit, že tomu nějak rozumím, jen jsem se kdysi nudil, tak jsem studoval, jak se programují překladače.

A jestli to správně chápu, tak v tom stromě, který vytváří parser, prostě neexistuje nic jako "rovnocená priorita". Vždycky je tam jen operand_1 * operand_2, a ty dva operandy se zase mohou "rozpadat" do dalších stromů.

Takže výraz typu a*b*c vždycky povede buď na strom a * (b * c) nebo (a * b) * c, tedy a * () nebo () * c, a kterou variantu si parser vybere závisí právě na asociativitě těch operátorů.

U dělení je asociativita jasná, tam ji otočit nemůžeme, u násobení si ji v principu můžeme zvolit. Nebo ji nechat stejnou jako u toho dělení. Nevím přesně, jak se to dělá.

Parser netuší nic o komutativnosti násobení, netuší že A * B = B * A, a je mu to jedno. Chci říct, že na to nesmí spoléhat a nemůže si pořadí prohazovat dle libosti. Protože když bychom operátor násobení použili pro násobení tříd představujících třeba matice, tak bychom dostali nesmyslné výsledky (násobení matic není obecně komutativní).

↑ MichalAld:  ↑ Aleš13:

Vidím, že jsem rozpoutal debatu, která už je, přiznávám otevřeně, mimo moje obzory. Mně se kdysi hodilo nějaké takové řešítko do několika mých programů a když jsem viděl, jak z těch tradičních infixových zápisů lezou ty stromy, poněkud jsem se vyděsil. Pak jsem objevil prefix a postfix, což mi bylo sympatické. Nepootřebuju nic přetěžovat, pracuju pouze s reálnámi čísly, proměnnými a funkcemi a k tomu mi postfix stačí.

Ale téma nebudu ještě uzavírat, takže pokud si chcete ještě podiskutovat, máte volné pole :-)

Jasně, to já jen, když už jsem se tu zakecal, nadhodil pár věcí které nebývají úplně zřejmé, ale přesto jsou legální. Jednou jsem se na to nachytal a pak těžce hledal chybu, tak si to kvůli tomu dobře pamatuju :-)

No jo, už to tak vypadá.

Pravda je, že já tohle nikdy nepužíval, jen jsem si na to vzpoměl... takže to asi není úplně nejlepší případ.


Tak ať nepíšu blbosti, tak jsem koukal, jak to je třeba v javě, a ony jsou skoro všechny operátory left-associative. Ale nějaké jsem našel i ty right-associative. Zpravidla jsou to unární operátory, ale také jsou to ty operátory typu +=, *=,...

Orders of operation


Takže a *= b *= c by se mělo vyhodnocovat zprava. Jako kdybychom to napsali na dva řádky:

b *= c;  // b = b * c
a *= b;  // a = a * b

Doporučuji, psaní parserů je výborná relaxace :-) Samozřejmě poctivé psaní ab initio, žádný Yacc a podobně :-)

Je to tak. Mně to přijde, že všechny ty generátory parserů byly vymyšlené v době, kdy se šetřilo každým gigabytem :-) protože napsat rekurzivní parser je jednodušší než se učit s tím generátorem. Stačí implementovat funkce getsymbol() a ungetsymbol() (návrat o krok zpět mi přijde přirozenější než se trápit s lookahead algoritmem) a jde to samo, nejen na výrazy, ale než se vzpamatuješ, máš rozebraný celý jazyk.

Nevím :-) Do LR parseru jsem se nikdy nepustil, na ruční práci je to moc složité a zatím všechno šlo řešit LL parserem s backtrackingem (ten není u LR potřeba). Vlastně ani nevím, který jazyk je LR a nedá se vyjádřit LL.

Zběžně jsem na to koukal (parser na c-like jazyk jsem nikdy nepsal, tak jen takhle odhaduju) a připadá mi, že ten přístup s rekurzivním analyzátorem by na to měl fungovat:
https://cs.wmich.edu/~gupta/teaching/cs … 20form.htm
Aspoň jsem tam nenašel protipříklad, ale ten se stejně vždycky najde až když to člověk začne doopravy psát :-)

Asi neupravilo, pravověrní céčkaři (to jsou ti, co se do krve hádají, že pole je pointer) považují svůj jazyk za dokonalý, tudíž jakákoliv úprava může být jen k horšímu :-) Spíš se udělá ten hack do parseru, imho to nebude nic obtížného, jinak bych se o tom určitě už někde dočetl. Jinak s tím LL a LR je to přesně tak, proto se LR vyhýbám, není moc intuitivní a programování pak není dostatečně zábavné :D