Příspěvky

1

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 10. 06. 2025, 22:43:38 »

Vyumelkovany proto, ze se cela diskuze toci jenom kolem jednoho undefined signed arithmetic shiftu. O nejakem podelanem shiftu ten jazyk vubec neni.

Jop, C není o jednom podělaném shiftu.

Ale tahle diskuze je o tom jestli je C těžké. A to, že tu můžeme takhle složitě rozebírat chování jednoho podělaného shiftu, tu obtížnost ilustruje naprosto dokonale.

OT: ciste na zaklade tohoto operatoru jde naprosto to stejny rict o Jave, kde zrovna shifty taky pekne ohnuli, takze je to plny prekvapeni.

2

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 05. 06. 2025, 08:17:32 »

jj já vím, co ta operace dělá. ale právě kvůli té problematické -1 (tedy samé jedničky v registru) to je IMHO vždycky způsob, jak se skutečně střelit do nohy. Vlastně právě i kvůli tomu, když píšu testy na kód se signed hodnotami, tak tam vždycky vrážím právě i -1, co to udělá.

docela bych řekl, že kdo toto potřebuje v praxi, tak prakticky vždycky by to měla být unsigned hodnota. Nějaký průchod polem dělením intervalu atd. - nezáporné indexy atd. Akorát unsigned je dlouhý slovo, tak jsme líní to psát...

Praktický případ - neuronka kvantizovaná do integer aritmetiky. Tam je fakt jedno, jestli je nějaká váha 0 nebo -1 v integeru, protože je to rozdí 0.0 vs něco jako -0.000001, což je na úrovni kvantizační chyby a nemá to vliv na výslednou accuracy.

Pravda, v tom případě by se to dalo použít. Takže v podstatě výpočet toho skalárního součinu s FX hodnotami na začátku každého neuronu a potom vydělení (posun) na správné místo řádové tečky. Dobře to je pěkný případ (i když popravdě se na to FX nehodí, možná ale není někdy zbytí, než mít jen integer aritmetiku).

3

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 04. 06. 2025, 10:52:52 »

Jenom takova technicka - k cemu je v C potreba operace posunu na signovane datove typy?

Taky jsem se chtěl zeptat. S tím se zase tak často člověk nesetká. S unsigned posuny ano, ale se signed?

Arithmetic right shift se dá použít na rychlé dělení konstantami 2, 4, 8, 16... signed čísel. I na současných CPU je integer dělení velmi drahá operace v porovnání s bit shiftem. Nelze přitom použít operátor dělení konstantou a doufat, že to překladač optimalizuje, protože integer dělení na signed integerech dává jiné výsledky než bitový posun. Výsledek operace (-1 / 2) je 0 a výsledek operace (-1 >> 1) je -1. Pokud se překladač rozhodne vygenerovat z operace dělení konstantou bitový posun, musí generovat extra kód, který tohle handluje.

Takže když chci extra rychlý kód pro dělení signed integerů konstantou a jsem smířen s tím, že to nedává identické výsledky jako operace dělení v C, je arithmetic right shift jediná varianta.

jj já vím, co ta operace dělá. ale právě kvůli té problematické -1 (tedy samé jedničky v registru) to je IMHO vždycky způsob, jak se skutečně střelit do nohy. Vlastně právě i kvůli tomu, když píšu testy na kód se signed hodnotami, tak tam vždycky vrážím právě i -1, co to udělá.

docela bych řekl, že kdo toto potřebuje v praxi, tak prakticky vždycky by to měla být unsigned hodnota. Nějaký průchod polem dělením intervalu atd. - nezáporné indexy atd. Akorát unsigned je dlouhý slovo, tak jsme líní to psát...

4

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 04. 06. 2025, 10:23:43 »

Jenom takova technicka - k cemu je v C potreba operace posunu na signovane datove typy?

Taky jsem se chtěl zeptat. S tím se zase tak často člověk nesetká. S unsigned posuny ano, ale se signed?

5

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 03. 06. 2025, 14:04:02 »

OT k těm bitovým a aritmetickým posunům. Ani jinde to není úplně růžové. Třeba Java je na jednu stranu mnohem specifičtější, ale posuny jsou omezeny na 31 resp. 32 bitů, což dokáže docela dobře zmást.

U céčka je situace jasná - musí běžet na čemkoli, od osmibitových MCU přes DSP až po 64bitové příšery. Takže spousta věcí je prostě závislá na architektuře.

6

Vývoj / Re:Programovací jazyk Ada v České republice

« kdy: 29. 04. 2025, 20:27:42 »

Já jsem v diskuzi četl vyjádření íté manažera jedné letecké společnosti, který by dle svých slov velmi rád zaměstnal Ada vývojáře, ale protože univerzity žádné nedodávají, lituje, ale společně s vedením se rozhodl využít to, co pracovní trh nabízí, tedy C++.

Některé firmy si dokážou vývojáře vychovat pro svoji platformu. To je (z toho, co znám) například Kx systems nebo Jane Street. Ale jasně, jestli někdo hledá "hotové" lidi, co se první den posadí k notebooku a začnou makat na enterprise systému...to je zajímavá pohádka.

7

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: 19. 04. 2025, 13:09:52 »

Velkým zákazníkům jde spíše o to, aby neleaknuly jejich data, tj., aby model nezahrnul jejich otázky do svých znalostí. Některým jde o kód. Vlastně jakákoli práce s copilotama vede k leaku dat, které navíc patří firmě/zaměstnavateli, ne tomu vývojáři, co to tam dobrovolně kopíruje. A dalším jde o to, aby v obecných dotazech nebyly senzitivní informace. Třeba akciovky mají poměrně přesně zákonem dané, jak oznamují některé změny, akvizice atd. A pokud si třeba firemní copywriter nechá "připravit" tiskové prohlášení veřejným LLM, tak to už si říká o velký problém.

Ehm. Naprostá většina firem má maily v Google/MS Cloudu, soubory sdílí přes google/one drive/sharepoint, komunikuje přes Slack, Teams, Meet a Zoom - to "tiskové prohlášení" se připravuje právě tam - zdrojáky a CI mají na GitHubu a hotové aplikace pak běží v Azure, AWS a podobně (=včetně kompletních zdrojáků, pokud je to interpretovaný jazyk, a ze snadno reverzovatelných binárek (určitě tam bude verze s debug symboly) pokud náhodou není). A ty teď tvrdíš, že se situace nějak změní, když budou používat LLM často i od té stejné firmy (Gemini = Google, ChatGPT = efektivně Microsoft, Claude = AWS) hostované na té stejné infrastruktuře?

A ty extrémně paranoidní, co teď mají on-premise Azure a on-premise GitHub/GitLab prostě budou mít vedle toho další rack s GPU - on-premise LLM. Zrovna třeba DeepSeek teď dělá přesně tohle.

Já tvrdím jen to, co nám říkají zákazníci. Na začátku 2024 to bylo jedno, to jim stačila podpora Azure OpenAI, OpenAI (a tím to docela haslo, i když se podporoval i WatsonX), dnes jich hodně chce lokální modely, a ta snaha je tam je značná (i přes cenu). Ale víš jak, ona je to sociální bublina našich zákazníků, kteří potřebují hybrid cloud (jinak by asi šli k jinému dodavateli) a často běží disconnected clustery.

Jinak je vtipný, že taky máme Google mail, Google doc a Google meet. Ovšem (zjednoduším) zákaz copilotů (což ale chápu).

8

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: 18. 04. 2025, 12:47:50 »

V tomto oboru trošku dělám (takže si možná pod sebou podřezávám větev :-) ale to už nějak doklepu), ale osobně bych počkal, jak se vyřeší problém s tím, na čem jsou ty LLM natrénovány. Jsou to obecně zdrojáky s nějakou licencí a obecně už to vypadá tak, že velké firmy spíše chtějí provozovat vlastní LLM, ne ty veřejné (právě kvůli tomu, aby jejich data neleaknula a nevyužil je někdo jinej).

Řekněme si to na rovinu, současné LLM porušují licenci vstupních dat, na kterých proběhl trénink. Otevřený kód a vzájemné kopírování to na ně všechny prásklo. Myslíš si, že se tohle změní uzavřením? Myslím, že nikoliv, jen to nebude tak snadno dohledatelné.

Velkým zákazníkům jde spíše o to, aby neleaknuly jejich data, tj., aby model nezahrnul jejich otázky do svých znalostí. Některým jde o kód. Vlastně jakákoli práce s copilotama vede k leaku dat, které navíc patří firmě/zaměstnavateli, ne tomu vývojáři, co to tam dobrovolně kopíruje. A dalším jde o to, aby v obecných dotazech nebyly senzitivní informace. Třeba akciovky mají poměrně přesně zákonem dané, jak oznamují některé změny, akvizice atd. A pokud si třeba firemní copywriter nechá "připravit" tiskové prohlášení veřejným LLM, tak to už si říká o velký problém.

9

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: 18. 04. 2025, 09:53:10 »

V tomto oboru trošku dělám (takže si možná pod sebou podřezávám větev :-) ale to už nějak doklepu), ale osobně bych počkal, jak se vyřeší problém s tím, na čem jsou ty LLM natrénovány. Jsou to obecně zdrojáky s nějakou licencí a obecně už to vypadá tak, že velké firmy spíše chtějí provozovat vlastní LLM, ne ty veřejné (právě kvůli tomu, aby jejich data neleaknula a nevyužil je někdo jinej).

Tedy popravdě mě docela překvapuje, že se tady píše, jak se často používá copilot atd. To je taky věc, která se začíná hlídat, protože SW firmy prodávají "svoje" dílo a nechtějí, aby je někdo později zažaloval, že jsou v tom kusy, které vlastní někdo jinej a LLM je použil.

Ale jak píše Pavel - tvoří to už teď bariéru pro služebně mladší se dostat do oboru. Navíc je tady opět problém toho, jak ty mladší lidi natrénovat už na škole, když už teď si pomáhají AI (kolega říká, že se jejich výsledky nijak nezlepšily ani po nástupu SO, ani po nástupu AI - takže tady je to nefunkční berlička).

10

Hardware / Re:Myš reaguje až na silnější stisk tlačítka

« kdy: 01. 04. 2025, 19:39:59 »

Ty lepsejsi myse na to maji sroubky, typicky nekde pod lepikama ... v horsim pripade pod kluzakama. Ty nedestruktivne vetsinou nesundas. Ty levny kramy = spotrebak = jsou zacvaktuny a rozebrat je muzes leda nasilim, a pak slepit zpet, protoze predstava ze to pritom nerozlames je scifi.

mám nějakou Logitech (nevím model, protože nálepka se už ošoupala a tam je jeden šroubek, co je dobře přístupnej. Druhá stana je se zobáčky, ale to nevadí, to se vyklopí. Od určitého času kupuju jenom myši, který to mají dělané takto rozumně a ne že se ušetří dva centy za šroubek a myš je po otevření už navždy rozsypaná.

Vypadá to nějak takto, i když já mam jinej model https://www.bustatech.com/wp-content/uploads/2010/08/110820101332.jpg

11

Hardware / Re:Myš reaguje až na silnější stisk tlačítka

« kdy: 31. 03. 2025, 18:47:32 »

Řešil jsem to stejné u myši Logitech takto:
https://youtu.be/3LaN6LxYSgA?si=owgK5eDvUb5SBbef

Jakkoli se použití WD40 jeví absurdní, je i po pár letech vše ok.

(na vlastní nebezpečí  )

Moc děkuju, taky jsem si tím právě "opravil" Logitechku, která mě už s vynecháváním stisků pěkně štvala.

Jako traduje se, že oprava čehokoli je jednoduchá:
1) WD40 na to, co se má hýbat
2) lepicí páska na to, co se naopak hýbat nemá

Akorát mě nikdy nenapadlo, že to skutečně opraví mikrospínač (pořád mi vrtá hlavou jak, čekal bych přesnej opak, když budou špinavý kontakty).

Tak ještě jednou dík

12

Hardware / Re:Koupě retro kalkulačky HP 12c, 15c

« kdy: 06. 08. 2024, 17:09:57 »

na alze je hp 12c v akci, ma to smysl dneska?

Ne když není ani na solar.

V tomto případě to není potřeba, ta kalkulačka vydrží s dodanýma baterkama roky (5 let v mém případě a pořád maká). Ale jestli koupit, to neporadím, záleží na use case

13

Vývoj / Re:Modernita vs. tradice při programování

« kdy: 26. 07. 2024, 19:32:07 »

tak dost programovacích jazyků, nástrojů, frameworků atp. se vyvinulo směrem k jejich typickému usecase.., třeba jakkoliv by asi bylo možný psát např.prometheus exportéry ve Fortranu, tak se to spíš neděje, a člověk si to napíše v pythonu, nebo v golangu.

Momentálně spolu s lidma z týmu pošilháváme po Julii, zdá se, že některé numerické knihovny a zázemí pro distribuované nebo paralelní výpočty je tam udělané - subjektivně - líp než v Pythonu.

Nu a ohledně té modernity/tradice.. Samozřejmě že člověk se chce vyhnout novému a neznámému, tak přemýšlíme, jak Julii volat z Pythonu, no

Julia může být dobré řešení, ale pozor - taky to má pár tmavých koutů :-) Dost záleží na tom, jak budete výsledek nasazovat. Pokud to má běžet někde "lokálně" (ale klidně i v cloudu, ale jen pro vás), tak to jde nasadit rychle. Ale jestli to má být balíček pro zákazníka, tak to si raději 3x otestujte

[a tiše závidím, že řešíte takové problémy, taky bych už něco podobného chtěl začít dělat].

14

Vývoj / Re:NoSql document databaze

« kdy: 29. 03. 2020, 14:47:32 »

Chápu správně, že ten dotaz je na porovnání databáze s ACID (řekněme tedy RDBMS dnes typicky založené na SQL) a dokumentových databází? Asi nejkratší odpověď bude, že databáze s ACID garantují jiné dvě vlastnosti z CAP teorému, než dokumentové databáze - konzistence vs. dostupnost.