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

Stran: [1] 2 3
1
Studium a uplatnění / Re:Přesun od PHP k Pythonu?
« kdy: 20. 12. 2018, 15:39:48 »
Řekl bych, že to bylo myšleno takto:
...
AttributeError: Cau instance has no attribute '__x'

no, ano, takhle se to chová. :)  vtip je v tom uvědomit si, že python nemá vůbec žádné řízení přístupu. takže si mylně interpretujete nepřítomnost symbolu jako nějakou jinou funkcionalitu.

name mangling je zřídka používaná funkcionalita, kterou potřebujete, když si třeba budete psát framework, co nutí uživatele podědit nějaké vaše třídy a současně uživatelům vašeho frameworku chcete zabránit některé metody overridovat nebo chcete zabránit kolizím v názvech. to znamená něco, jako javovské final.

2
Studium a uplatnění / Re:Přesun od PHP k Pythonu?
« kdy: 20. 12. 2018, 13:02:37 »

Takže pokud preferuji OOP cestu, tak Python je spíš horší cestou? Jako mě to php celkem i sedí, zdá se mi přehledný, ale to bude tím že mě do toho asi tak posadili a ať se učím. Možná, že to bude znít někomu jako blbost, ale php mi příjde docela podobný js, určitý zákonitosti tam jsou sice jinak, ale jinak mi oba jazyky sedí.

to závisí, jak se na oop díváte. pokud chcete, aby se striktně dodržovala teorie, tak je horší cestou. pokud preferujete praktickou využitelnost, tak vám asi bude vyhovovat. jenom aby nedošlo k mýlce: python je objektovej jazyk. všechno v pythonu je objekt. má třídy i metatřídy. jenom se některé věci dělají trochu jinak, protože v praktické rovině to dělá člověku práci jednodušší.

každopádně pokud vám vyhovuje js, tak klidně používejte js. já nikomu nic nevnucuju.

okolo toho js (a properties) by Vás mohlo zajímat toto: http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html

3
Studium a uplatnění / Re:Přesun od PHP k Pythonu?
« kdy: 20. 12. 2018, 12:49:41 »
Neni to jedno podtrzitko, ale dve a neni to dohoda programatoru, ale vlastnost jazyka. Takto pojmenovana metoda neni svym jmenem pristupna z venku, coz je nezbytne nutne k tomu, aby je bylo mozno prepisovat v odvozenych tridach.

to jako vážně? name mangling není analog private. private se zapisuje s jedním podtržítkem, name mangling je spíš něco jako javovské final. akorát že manglované jméno se hledá standardním způsobem, tedy i mimo třídu. např. toto bude fungovat:

_Ahoj__a = 4
class Ahoj():
 def x(self):
  return __a

q=Ahoj()
print(q.x())


4
Studium a uplatnění / Re:Přesun od PHP k Pythonu?
« kdy: 20. 12. 2018, 09:30:48 »
Python není jazyk pro OOP dogmatiky, protože preferuje praktičnost před principama OOP. Takže třeba nerespektuje zapozdření (což zjednodušuje jazyk, debugování i práci např. s callbackama).

Python neporušuje zapouzdření. To dělají jen nezodpovědní programátoři.

pokud můžete metodě explicitně předat parametr self, tak nemáte zapouzdření. proto se taky v objektových jazycích, co chtějí zapouzdření udržet, vymýšlí všemožné způsoby, jak se tomu vyhnout. to je jediný smysl existence napr.  delegates v .netu.

WTF? to si vzal kde? Self, this nebo cokoliv jineho je vetsinou jen reference(ukazatel) na danou tridu. To se zapouzdrenim nema v podstate nic spolecneho. Jinak nevidim duvod proc by jedinym smysl delegates melo byt poruseni zapouzdreni.

Smyslem existence delegates je právě vyhnout se porušení zapouzdření. Což je stav, který by vznikl, kdyby byla ta metoda vidět jako funkce s explicitně přístupným self.

Dejme tomu, že je self pointer (což v cpythonu skutečně platí). Nicméně python jako jazyk nepředává parametry odkazem, alébrž objektem (viz CLOS, z kterého to python zdědil), takže se o pointerech nemluví.

Problémy s explicitním předáváním okolo zapouzdření jsou dva:
1) V typickém objektovém jazyku máte private atributy, co nesmí být přístupné zvenku. Pokud povolíte explicitní self/this pointery/objekty a chcete to reálně používat, musíte zvenku povolit přístup k vnitřku odkazovaného objektu zvenku, včetně private atributů, což je porušení zapouzdření.
2) V pythonu konkrétně se private atributy specifikujou dohodou mezi programátorama tak, že co začíná jedním podtržítkem, je private atribut. Ale jsou přístupné, jazyk nebrání přístupu k nim a to je porušení zapouzdření. Samozřejmě normálně bude programátor tu konvenci respektovat, takže nepůjde proti zapouzdření, takže v praktické rovině tohle nebude normálně problém. Problém to je akorát v rámci teorie a OOP dogmat.
3) Self/this nebo jak si ten pointer pojmenujete je v typickém objektovém jazyce implementačně závislej pointer, co je generovanej kompilátorem (a může jich být pro jeden objekt více různých, aby fungovaly přístupy k atributům zděděným z různých tříd). A aby kompilátor mohl vygenerovat správný this pointer, staví se na vlastnostech zapouzdření. Kompilátor potřebuje mít tohle pod kontrolou a nedovolit programátorovi, aby si tam předával, co chce. Python je jeden z mála jazyků, co má věci jinak, v pythonu se funkci předává přímo objekt (resp. vnitřně pointer na datovou strukturu, reprezentující objekt) a funkčnost přístupu k atributům objektu řeší místo kompilátoru objekt samotnej.

5
Studium a uplatnění / Re:Přesun od PHP k Pythonu?
« kdy: 19. 12. 2018, 23:56:52 »
Python není jazyk pro OOP dogmatiky, protože preferuje praktičnost před principama OOP. Takže třeba nerespektuje zapozdření (což zjednodušuje jazyk, debugování i práci např. s callbackama).

Python neporušuje zapouzdření. To dělají jen nezodpovědní programátoři.

pokud můžete metodě explicitně předat parametr self, tak nemáte zapouzdření. proto se taky v objektových jazycích, co chtějí zapouzdření udržet, vymýšlí všemožné způsoby, jak se tomu vyhnout. to je jediný smysl existence napr.  delegates v .netu.

6
Studium a uplatnění / Re:Přesun od PHP k Pythonu?
« kdy: 19. 12. 2018, 21:02:11 »
Tak jsem si říkal, zda by Python pro mě nebyl lepší. Jedná se o celkem komplexní jazyk, který se využívá v různých odvětvích, ale není tak omezen jako PHP

Základy pythonu se dají naučit rychle. A dá se to i nějak používat. Podle mě je navržený jednoduššeji, než třeba to PHP (protože PHP bylo navržené hodně nekonzistentně atd..)

Python se dost používá okolo zpracování dat, "data science", umělé inteligence apod.

Python je výbornej jako glue language.

Python není jazyk pro OOP dogmatiky, protože preferuje praktičnost před principama OOP. Takže třeba nerespektuje zapozdření (což zjednodušuje jazyk, debugování i práci např. s callbackama).

Citace
(tím myslím že v PHP se dělaj hlavně weby).

PHP bylo původně template engine, napsaný v perlu. A tohle dědictví si s sebou holt táhne do dneška. I lidi, co tvrdí, že PHP není programovací jazyk, mají vlastně pravdu. ;)

7
Studium a uplatnění / Re:Bakalářská práce - téma
« kdy: 18. 12. 2018, 21:16:40 »
Tohle dost závisí na škole a lidech, co tam učí. Od toho se ta témata bakalářek odvíjí. Představa, že si vymyslím téma a budu si dělat co chci je dost mimo.

8
no a pokud se bude číst z raidu, to znamená synchronizovaně, bude efekt horší.

Chtělo by ta tvrzení něčím podložit a nejen napsat "bude efekt horší" a podobné cancy. Úplně normálně si tu vymýšlíte.

tak to tak nějak vyplývá z toho, jak to celé funguje. ale jestli to potřebujete nějak potvrzovat nebo vyvracet, můžete si vzít osciloskop a jít měřit. moje potřeba komukoli cokoli dokazovat je naprosto nulová.

9




koukám ještě na ten graf a přece jen se z něj dá něco vyčíst i o špičkách za běžného provozu. protože je tam vidět rozdíl mezi náhodným a sekvenčním čtením, což je rozdíl v energii, který imo padne z významné části na pohyby hlavičky. v grafu vidím rozdíly cca 0,5-2W a bude tam peak odpovídající době, kdy se hlavička pohybuje (to může být tak 10% z čtecího cyklu, záleží).

no a pokud se bude číst z raidu, to znamená synchronizovaně, bude efekt horší.

10

To má ten disk jen jednou - i s rezervou - při studeném startu, když roztáčí plotny a jen velmi krátce. 4 GB disk jsem už neviděl ani jako flashku v poslední době. Bylo by lepší, kdyby jste pohledali informace ze změřené spotřeby ne při chvilkovém proudovém rázu při startu a ke konkrétnímu modelu. Běžně má novější disk disk o větší kapacitě nižší spotřebu.


já hledal ten disk podle názvu, nedal jste přesnější údaje. ;) no ale to je jedno.. zrovna tenhle údaj nejde moc vylepšit, dokud jsou ty plotny stejně těžké a disk má stejné otáčky. pokud by to chtěli vylepšit, musel by se roztáčet opravdu dlouho (což by zas dělalo problémy s probouzením disku atd..)

pro výběr zdroje je důležitý údaj o špičkovém proudu z datasheetu nebo aspoň změřený při rozeběhu. zdroj musí všechno utáhnout i když se disky roztáčí současně. pokud utáhne všechno při startu, má i rezervy na různé špičky v odběru během normálního provozu. ten střední odběr, co ukazujete na grafech, moc neříká nic o špičkách, které vznikají během provozu (a s kterýma se zdroj musí vypořádávat, na 12V lince je povolená tolerance 10%, z které pokud se i během špičky odběru vyleze, není chování periferií na 12V lince definované)

mě je samozřejmě jasné, že během normálního provozu je ten střední odběr několikrát nižší. takže když chce někdo ušetřit za zdroj, tak si nastaví v biosu, aby se disky roztáčely postupně. což je ale jenom takovej trik. stejně zdroj musí mít vevnitř dost velké kondenzátory, aby kompenzoval špičky během běžného provozu. ale dostatečně velké kondenzátory mívají právě až ty výkonnější a kvalitnější zdroje. výrobci šetří na kondenzátorech. a někdy to dělají i výrobci serverového hw - potkal jsem třeba redundantní serverové zdroje, co počítaly s kapacitou kondenzátorů toho druhého redundantního zdroje a když tam nebyl, tak se ty kondíky během asi půl roku opotřebovaly a server začal dělat blbosti.

11

Jasně ty disky berou okolo 5W (RED dokonce okolo 3,5W) ale budeme počítat 20 W.

tak vy si počítejte co chcete. nicméně při návrhu hw se vychází z mezních hodnot (jako třeba maximální odběr), nikoli ze středních hodnot.

update: argumentujete wd red. wd red podle datasheetu má v 4GB variantě jen na 12V lince špičkový odběr 1,75A. To dává nějakých 21W. viz https://cdn.cnetcontent.com/3a/07/3a07b8d6-7086-4c6f-80dd-ac1685c20336.pdf.

12
Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

Výkonná grafická karta s odběrem okolo 40-50W? Jako vážně? To by tam těch disků muselo být několikanásobně více, výkonná grafická karta bere aspoň 200-300 W.

počítá se cca 20W/disk, což při těch 6 discích dává nějakých 120W.

ten vývoj v čase, co OP popisuje, se dá vysvětlit klidně i odcházejícíma kondenzátorama na výstupu zdroje.

13
Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

14
Hardware / Re:CNC stroj na malování
« kdy: 29. 11. 2018, 11:56:26 »
Nechcem byt za hlupaka ale tie odkazy su presne odpovede na Vase problemy. S toho co tu pisete chcete znova vytvorit koleso.

z druhé strany, pokud se OP pokouší ten problém nějak vyřešit sám, asi mu to dá víc, než když někde opíše celé řešení. já v tomhle lidi podporuju, protože znám řadu lidí, co se díky googlu odnaučili myslet. navíc práce se štětcem v cnc je zajímavej problém, tam bude určitě existovat mnoho řešení.

kdybych si s tím hrál já, tak bych si na grafickém tabletu nakreslil nějaké testovaci obrazce (různé tvary, různě rychle atd..). na grafickém tabletu proto, že můžu zaznamenávat polohu pera v čase, včetně náklonu.

15
Jako první bych kouknul, jestli mají ty disky v pořádku napájení a jestli se nepřehřívají. Dokud není ok tohle, diagnostika ostatních věcí může vést k nesmyslným závěrům. A to stejné pro řadiče.

Stran: [1] 2 3