Příspěvky

46

Vývoj / Re:Algoritmus pro skládání kousků dřeva

« kdy: 09. 06. 2016, 11:30:15 »

V tom případě by mohl algoritmus vypadat následovně (opět je jen lineární obvykle fungující implementace v případě "rozumné" distribuce dílků):

1. Nadefinovat left=0 (levá hranice), right=0 (pravá hranice), current=0 (aktuální pozice konce)
2. Vzít následující element, porovnat current-element-left a current+element-right a podle toho, který z nich bude větší, umístit element doleva či doprava. Minimalizuje buď přesah nebo není-li žádný, maximalizuje prostor pro další krok
3. Podle předchozího kroku upravit current = current+-element a pokud překročí left/right hranice, tak i ty
4. Loop to (2) until input empty

Protipříklad:
Váš algoritmus: 1-3+1+4=5
Správné řešení: 1-3-1+4=4

Já vím, že existují protipříklady, proto jsem "lineární obvykle fungující implementace v případě rozumné distribuce". Nelze (aspoň si to zatím celý svět myslí) vyřešit NP-úplný problém v rozumném čase.

Nicméně, jak podotknul "j", v zásadě by tento případ vylepšilo nastavení "end" na délku maximálního dílku. Nicméně některé zase zhorší: 1+1-4 místo 1-1+4. V zásadě jde o to před největším dílkem dostat se na 0 nebo na max...

47

Vývoj / Re:Algoritmus pro skládání kousků dřeva

« kdy: 09. 06. 2016, 09:44:55 »

Teď koukám, že jsem zprvu nepochopil zadání - pořadí je pevně dané, což?

V tom případě by mohl algoritmus vypadat následovně (opět je jen lineární obvykle fungující implementace v případě "rozumné" distribuce dílků):

1. Nadefinovat left=0 (levá hranice), right=0 (pravá hranice), current=0 (aktuální pozice konce)
2. Vzít následující element, porovnat current-element-left a current+element-right a podle toho, který z nich bude větší, umístit element doleva či doprava. Minimalizuje buď přesah nebo není-li žádný, maximalizuje prostor pro další krok
3. Podle předchozího kroku upravit current = current+-element a pokud překročí left/right hranice, tak i ty
4. Loop to (2) until input empty

48

Vývoj / Re:Algoritmus pro skládání kousků dřeva

« kdy: 08. 06. 2016, 15:29:07 »

Na první pohled bych řekl, že jde o NP-úplný problém, takže rychlé a spolehlivé řešení neexistuje.

Nicméně celkem dobré výsledky bude dávat následující:

1. seřadit podle hodnoty
2. odebrat ze seznamu nejvyšší hodnotu a přičíst (pokud je aktuální suma záporná) či odečíst (je-li aktuální suma kladná)
3. loop until seznam empty

49

Vývoj / Re:Java Lamdas slow as fak

« kdy: 19. 03. 2016, 15:50:24 »

Je tam nekolik problemu:

JIT optimalizuje az po nekolika (tisicich) pusteni dane funkcr. Proto je vhodne zvolit nejaky microbenchmark tool  - JHM treba a korektne napsat benchmarky.

Zalezi jak se napise kod. Vytvaret lambdu pro kazdy prvek, kdyz se vlasyne nemeni, je zcela zbytecne, navic by se o to mozna prave postaral JIT. I tak normalne by to nevadilo, ale v takovem umelem benchmatk se to pochopitelne projevi.

Posledni priklad - letmo - vytvari pro kazde volani 3x Integer class. Zatimco u for verze kompolator nejspis zcela vyhodi ten temporary objekt ci ho da na stack, takze vysledkem bude zcela primy preklad pres par scitani.

Je treba rict, ze lambda je ve sve podstate virtualni callback, ktery negativne ovlivnuje moznosti optimalizace. Bezne to nevadi, bo moderni SW je na tom postaveny, ale v pripade jednoduchych matematickych smycek typu secti mi pole cisel to neni nejlepsi varianta.

Ale jeste jednou viz vyse - dost mozna cast vyresi JIT po vice pruchodech.

50

Hardware / Re:Pracovní notebook okolo 40K

« kdy: 12. 01. 2016, 09:56:03 »

co poviete na tento notebook?
https://m.alza.sk/dell-xps-15-strieborny-d3755695.htm?catid=18842920

Touchpad uprostřed - jedna z nejneergonomičtějších věcí, co jsem kdy viděl. Kdo nezažil, nepochopí - neustále si budeš při psaní ťapat dlaní na touchpad a posunovat/klikat myší.

51

Hardware / Re:Pracovní notebook okolo 40K

« kdy: 30. 12. 2015, 09:04:58 »

Ad trackpoint - záleží na vkusu, touchpad mi přijde rychlejší, já třeba trackpoint na svojí Toshibě úplně vypnul :-)

Jinak IMHO je to prašť jako uhoď, která je to značka, spíš bych se zamyslel nad následujícím:

• Budeš ho přenášet? - pokud jo, 15.6" je docela dost, váha 2.2kg, 15.6" se dá sehnat i s váhou 1.8kg, ale obecně bych zvážil spíš menší
• Paměť 8GB - na domácí brouzdání ok, na moderní IDE je to na hraně, bral bych 16GB (případně některé Acery mají atypické 10GB či 12GB)
• Procesor - IMHO ok, mám o něco starší i7 low voltage 4 hyperthreads a náročný vývoj je celkem v klidu

52

Hardware / Re:Pracovní notebook pro vývojáře

« kdy: 16. 06. 2015, 08:37:56 »

Tvoje informace jsou mylne, limit intelich desktopovych CPU je 32GB a to zcela umyslne a umele. Dokonce i kdyz si koupis skt 2011 a mas desku ktera umi 128GB+, tak je ti to k prdu, pokud do ty desky das I7 a ne xeon. U AMD je to jinak, jenze tam je to zas nastyru s vykonem per jadro.

Řeč byla o ultrabook procesorech a tam je ten limit 16GB celkem běžný:
http://ark.intel.com/products/81015/Intel-Core-i7-4510U-Processor-4M-Cache-up-to-3_10-GHz
http://ark.intel.com/products/85214/Intel-Core-i7-5500U-Processor-4M-Cache-up-to-3_00-GHz

53

Hardware / Re:Pracovní notebook pro vývojáře

« kdy: 15. 06. 2015, 10:48:48 »

Ultrabooky maju bohuzial dost blbu rozsiritelnost a konfiguracia s viac ako 8 GB RAM a viac ako 256 GB SSD je alebo neskutocne predrazena, alebo castokrat aj nemozna.

Limity dnešních CPU / chipset jsou obvykle 16GB, takže technicky obvykle není problém, cenově dalších 8GB není extra hodně. Otázka, co to udělá se spotřebou. Kdysi se mi líbily myslím Acer nebo Asus, které měly 10-12GB - 8GB mi přijde na hraně, 16GB už je obvykle plýtvání.

Jinak jsem kdysi váhal taky nad Zenbook UX305, vypadá velice povedeně až na jednu věc - touchpad uprostřed místo pod mezerou. To jsem zažil u dřívějšího notebooku a neustále jsem si pravou dlaní aktivoval myš :-/

Nakonec jsem skončil u Toshiba Portégé Z30-A-1E1, zatím velká spokojenost ve všech směrech - nízká váha, vysoká výdrž, výkon a dost velký SSD. Předtím jsem váhal, jestli 13.3 nebo 14, ale nakonec rozhodla aktuální sleva :-) a popravdě to vysoké rozlišení udělá daleko víc než kousek palce navíc.

54

Server / Re:Změření IOPS jednotlivých procesů

« kdy: 05. 08. 2014, 13:58:44 »

/proc/???/io
http://man7.org/linux/man-pages/man5/proc.5.html

55

Vývoj / Re:Java: anonymní třída a final

« kdy: 09. 07. 2014, 22:04:46 »

Anonymní třída nemá přístup na aktuální stack, proměnná (pointer) se kopíruje jako skrytý member do anonymní třídy.

Takže v případě pokus o přiřazení nové hodnoty z aktuální funkce by neměla třída up-to-date hodnotu a opačně v případě přiřazení z anonymní třídy by neměla aktuální funkce up-to-date hodnotu (ať už by běžela v rámci stejného threadu nebo paralelně). Navíc v době provádění kódu anonymní třídy už nemusí scope funkce ani existovat.

V zásadě jde tedy jen syntactic sugar, jak zabránit potenciální nekonsistenci obsahu mezi lokální proměnnou a její (skryté) kopii ve třídě. GC s tím nemá nic společného.

56

Vývoj / Re:Proč je JavaEE nepopulární?

« kdy: 11. 05. 2013, 20:11:43 »

Java je objektový jazyk a v době jejího návrhu (první polovina 90. let; první produkční verze je AFAIK z 1995) se lamda výrazy běžně nepoužívaly (v C se používaly např. ukazatele na funkce). Kromě toho lamda výraz (anonymní funkce) je rys funkcionálního programování, ne objektového. Ano, taky bych uvítal, kdyby to tam bylo (když je to i ve SmallTalku ;-) ) společně s ekvivalentem .Netového LINQu, ale rozhodně to není možno nazvat slovem "samozřejmost".

http://code.google.com/p/guava-libraries/wiki/FunctionalExplained
http://functionaljava.org/

To druhé je možná polomrtvé (i když úplnější), to první v pár projektech používám. Oproti nativní lambda je to o něco ukecanější, ale v zásadě možná o to čitelnější...

57

Vývoj / Re:Vlastní CMS - Java vs PHP

« kdy: 01. 02. 2013, 17:59:20 »

Java:
- v porovnani s PHP zlozity kod (napr. hashtable vs asoc. pole v PHP)

Omlouvám se za lehce OT, ale co je na hashtable složitého oproti asociativnímu poli v PHP? Že místo hranatých závorek napíšu get() ?

Spíš bych naopak bil ty, co vymysleli, že není nutné rozlišovat sekvenční pole od asociativního - soudruzi sice ušetřili jedno klíčové slovo, ale donutit pak třeba kód postavený na reflection, aby serializoval prázdný hash jako {} (v případě JSON), to je nadlidský úkol.

58

Odkladiště / Re:2012-31-07 mínus 1 mesiac = ?

« kdy: 28. 08. 2012, 15:42:32 »

Obojí je "správně".

Podstatné je, aby splňovalo:

Kód: [Vybrat]

a <= b -> a+n <= b+n

Jakkoli se to zdá samozřejmé, tak už jsem viděl implementace, které z 31.1. + měsíc udělaly 3. březen...

59

Sítě / Re:Wi-Fi připojení po 10 sekundách spadne

« kdy: 07. 12. 2011, 11:38:54 »

Tak s tímhle jsem bojoval zrovna včera. S tím, že WiFi AP je na normálním notebooku a řeší jej hostapd.

Na restart jsem líný, ale po všech ifconfig wlan0 up, down, přehazování pořadí dhcpd a hostapd pořád nefungovala. Nejdéle vydržel připojený samostatně telefon, ale kdykoli se přidal jiný notebook, tak to bylo opakované authentication ok (občas fungoval i internet), a v krátkém sledu connected-disconnected. Poté přestal fungovat i telefon, který se zaseknul na dhcp requestu. Zvláštní bylo, že dhcpd na requesty odpovídal, ale přes WiFi už (zpátky) nic neprošlo, nejspíš zprasený packet a proto to disconnected.

Po hodině rvaní si vlasů jsem spíš omylem ještě za běhu hostapd napsal ifconfig wlan0 down, čímž jsem asi rozhodil driver a po novém puštění hostapd už jelo všechno v pohodě. Možná by pomohl i rmmod a modprobe na ath3k, to zjistím až příště

Jestli je to router, tak by mohlo stačit restartovat

60

Vývoj / Re: Strategie alokování paměti v C++

« kdy: 26. 03. 2011, 12:56:50 »

Kdysi jsem řešil něco podobného, bo původní alokátory byly přinejmenším v multi-thread naprosto příšerné.

Optimalizoval jsem jen malé bloky, velké příliš používané nejsou. Strategie je celkem triviální, ale účinná (O(1)). Do nějaké velikosti byl seznam 8-byte, 16-byte, 24-byte, 32-byte atd., od větších velikostí vždy po 1.5 násobku. Alokoval se vždycky velký blok a ten se rozsekal na menší a strčil se vždy celý řetězec do toho seznamu. Výhodou byl výskyt bloků pro stejné účely v rámci stejného kusu paměti, což je dobré pro cache (na druhé straně dvojice node-objekt byla v různých částech, ale snad to procesor zvládal ). Při dealokaci se jen zkontrolovala velikost a strčila se do správného seznamu - základní úvaha je, že když byl daný blok jednou třeba, bude někdy v budoucnu opět využit. Spojování děr apod. jsem tedy vůbec neřešil, stejně by to jen nadělalo zmatek pro cache.

Samozřejmě, pro hodně-multi-thread vytížené serverové věci je dobré mít ještě per-thread cache, buď s explicitním nebo implicitním uvolňováním po nějakém počtu alokací. To hromadné uvolnění je velice levné - jen O(1) pro celý řetěz bloků stejné velikosti.