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 - Ondra Satai Nekola

Stran: 1 ... 81 82 [83] 84 85 ... 177
1231
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 12:47:30 »
No prave ze ten logaritmus (ne velikosti programu ale dat) muze byt casto v realu az moc optimisticky odhad :-/

http://www.ilikebigbits.com/blog/2014/4/21/the-myth-of-ram-part-i

Což je další argument proti používání funkcionálního programování všude.

Zkus to, prosim, ozavorkovat ;)
Tedy realna RAM neni O(1), ale spis O(log n), a takovou RAM lze realizovat i funkcionalne (pomoci stromu).

Tak to určitě neplatí. Čas přístupu do paměti neroste logaritmicky s velikostí vstupu programu. O(1) je jen horní odhad rychlosti operace. Stačí uvažovat nejpomalejší možný přístup. Pořád to bude reálnému hardwaru mnohem blíž než Turingův stroj.

No prave ze ten logaritmus (ne velikosti programu ale dat) muze byt casto v realu az moc optimisticky odhad :-/

http://www.ilikebigbits.com/blog/2014/4/21/the-myth-of-ram-part-i

To je teda dobrá volovina! Vzít teoretický koncept a aplikovat ho na jedno konkrétní technické řešení... Např. v mém embedded světě nic takového neplatí. Navíc cache slouží k urychlení práce s pamětí! Autor to obrátil, vzal tu urychlenou práci za O(1) a zkoumal, o kolik pomalejší to ve skutečnosti je. Ve skutečnosti O(1) je právě ten přístup bez cache a měl případně zkoumat, o kolik je to s cache lepší než teoretická O(1).

A jak muze byt cache lepsi nez teoreticka O(1)? (hint: zamysli se nad tim, co to O znamena)

Jinak samozrejme vsechny tyhle aplikace vyzaduji nejakou davku nasili. Protoze realny pocitac s omezenou RAM a SSD ma ostatne konecny pocet stavu a tak je to, vzato do dusledku, konecne automat ;)

1232
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 12:32:48 »
Tedy realna RAM neni O(1), ale spis O(log n), a takovou RAM lze realizovat i funkcionalne (pomoci stromu).

Tak to určitě neplatí. Čas přístupu do paměti neroste logaritmicky s velikostí vstupu programu. O(1) je jen horní odhad rychlosti operace. Stačí uvažovat nejpomalejší možný přístup. Pořád to bude reálnému hardwaru mnohem blíž než Turingův stroj.

No prave ze ten logaritmus (ne velikosti programu ale dat) muze byt casto v realu az moc optimisticky odhad :-/

http://www.ilikebigbits.com/blog/2014/4/21/the-myth-of-ram-part-i


1233
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 12:29:28 »
Turinguv stroj s tim ma spolecneho to, ze je to z tradicnich duvodu "zaklad", se kterym je jak lambda kalkulus tak RAM ekvivalentni.

Z hlediska složitosti algoritmů určitě ekvivalentní není.

Ano, jak rikam, detaily behu se mohou lisit. Ale neplati to v te podobe, co jsi psal na zacatku (ze nejde neco implementovat prostrednictvim neceho jineho).

1234
Odkladiště / Re:Pomoc informatiky při pátrání
« kdy: 02. 02. 2017, 12:08:20 »
Existuje v zakone i neco jako krajni meze, kdy je mozne prekrocit normy a dat logy na zaklade odvraceni neceho horsiho

Krajni nouze. Ovsem muzes ji aplikovat pouze pokud neni alternativni reseni v mezich zakona, coz se da v tomhle pripade asi dost tezko aplikovat.

1235
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 11:30:30 »
Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

A na to jsi prisel jak?

https://en.wikipedia.org/wiki/Turing_machine_equivalents

Co má společného Turingův stroj s tím co jsem psal? Já psal o stroji s náhodným přístupem do paměti. Pomocí turingova stroje i lambda kalkulu můžete vyřešit stejné problémy, ale ne ve stejném čase a se stejnou paměťovou náročností. Běžné algoritmy jsou postupy výpočtu pro stroj RAM.

Turinguv stroj s tim ma spolecneho to, ze je to z tradicnich duvodu "zaklad", se kterym je jak lambda kalkulus tak RAM ekvivalentni.

Ano, pokud reknes, ze mas stejnou vyspocetni silu, ale mohou se lisit detaily behu, tak se s tim da souhlasit. Ale je to neco dost jineho, nez jsi psal na zacatku.

1236
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 11:07:27 »
Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

A na to jsi prisel jak?

https://en.wikipedia.org/wiki/Turing_machine_equivalents

1237
mohl by je prenest treba do Ruska. mnohem bezpecnejsi krajina

Pokud ti nevadi, ze te trebas nekdo zavrazdi, organizovany zlocin nepovazujes za hrozbu a oblibujes fasismus...
fasismus je na ukrajine, vidis nekdy v rusku fasismus?

Jasne. Rusko z definice nemuze byt fasisticke, protoze fasista je nekdo, kdo chce ublizovat Rusku...

Muzes si trebas napocitat skore u Ecova urfascism.

1238
Odkladiště / Re:Pomoc informatiky při pátrání
« kdy: 01. 02. 2017, 15:34:19 »
Pise ted Ivan Novy pod jinym nickem?

To je jenom duch doby... :-/

1239
Odkladiště / Re:Židle vhodná pro programátora
« kdy: 01. 02. 2017, 14:45:00 »
Ja bych chtel zidli, kterou navrhnul nejakej obycejnej inzenyr. Hlavne nic, co potkalo design.

Co si predstavujes pod pojmem design? ;)

1240
/dev/null / Re:Co považujete za nejdůležitější?
« kdy: 01. 02. 2017, 11:36:21 »
Jen vám vysvětluji co se v USA vlastně stalo. Protože to přes své ideologické brýle nejste a zřejmě ani nebudete schopen pochopit.

"vysvetlujes"

Vypravej nam jeste chvilku o ideologickych brylich, prosim...

1241
mohl by je prenest treba do Ruska. mnohem bezpecnejsi krajina

Pokud ti nevadi, ze te trebas nekdo zavrazdi, organizovany zlocin nepovazujes za hrozbu a oblibujes fasismus...

1242
Hlavně QA asi těžko může být lepší než vývojář už z principu. Buď jsi ten, který to celé staví a všemu rozumí a nebo jen ten, který to testuje. Testování je super a není jednoduché, ale rozhodně je to méně náročné. Každý programátor může být QA, ale naopak to neplatí. Proto máš v QA i plno holek. Sice neumí programovat, ale strojově generovat automatizované testy podle šablony zvládnou.

Nemůže. Programátor je povahou tvůrce, QA je povahou ničitel. Teprve z jejich vzájemného střetu něco dobrého vznikne.

A to je odpoved na nevyslovenou otazku, kdo nam tady jeste chybel...

1243
Vývoj / Re:Dědičnost dnes
« kdy: 29. 01. 2017, 11:28:17 »
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

Citace
To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

Jedna z možných implementací by byla např. takováto:

Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.
Maticové násobení bude umět matice a realizováno bude pomocí skalárních součinů.
Čtvercová matice by byla potomkem obecné matice a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Permanent a determinant jsou dve ruzne (prestoze podobne) veci.

1244
Mechanika? Pripadne jake switche?

1245
Vývoj / Re:Dijkstrův algoritmus - python
« kdy: 26. 01. 2017, 18:15:02 »
Takže jediná věc, co ti z domácího úkolu chybí, je ten domácí úkol? ;)

Zamysli se, co budeš potřebovat. Co třebas nějakou datovou strukturu, kde si budeš držet zatím nehotové vrcholy?

Stran: 1 ... 81 82 [83] 84 85 ... 177