A programozáshoz mennyire kell matek?

36. (2021.10.22 17:05) "Az már jobban hangzik, hogy a fordító hibázott,"

Olvasd el, hogy mit írtam. Nem azt írtam, hogy a fordító hibázott. Hanem azt, hogy "vagy te csináltál rosszul valamit, vagy a fordító". Nem ugyanaz mintha azt írtam volna, hogy a fordító hibázott.

38 (2021.10.22. 18:52) adta meg eddig a legjobb "megfejtést"

"Az meg nyilvánvaló, hogy sok esetben nem is éri meg egy cégnek kódot lopni, mert azt végig kell vizsgálni, hogy hibamentes-e vagy sem, az idő alatt meg inkább megíratják a sajátot."

Erről már én is írtam korábban. Igen elég minimális az az alapkészlet amiből kiindulnak. És pont ezért. Bizonyos szint felett itt is megjelenik a felelősség kérdése. És nagyon nem mindegy, hogy hol vannak a határok. Az, hogy az MS meg egy rakás program eleve kizárja magát a felelősségből az egy dolog. De vannak érdekes megoldások. Pl. bizonyos helyeken pont ezért tilos pl. a windows frissitése mert azon az egy változaton lett tesztelve a program. Pl. mi rögzíteni szoktuk, hogy melyik windows változat, milyen verziójú dll-ek stb. voltak a gépen amikor otthagytuk és teszteltük a cuccot. Aztán ha borul az egész jöhet a jogi vita, hogy mennyiben függ őssze a hiba az általunk készített program hibájával, a windows frissitésből adodó hibával (az felel aki a windowst frissitette), vagy az ezt követő nem kellő teszteléssel (szintén az felel aki a windowst frissitette). És itt nem csak súlyos pénzekről van szó, hanem esetleg ember életekről is (ld. pl. egy kórházi rendszer csak két beteg gyógyszerezését keverje össze egy hiba miatt, és az még egy enyhébb eset). És utána lehet rohangálni, hogy akkor ki miatt következett be a gyógyszer csere, ki hol hibázott. Ezért sem szeretjük az "ismeretlen" eredetű kódrészleteket, meg a teljesen ismeretlen libeket befordítani. Pl. egy C fordító esetén az adott változaton végig teszteljük az alap libeket (nyilván a printf-et nem fogjuk megírni), de ott megint pontosan dokumentált, hogy melyik fordító melyik verziójával, milyen verziójú libekkel fordítottunk. És ha frissités van akkor tesztelés kezdődik előlről. Ezért ma már (nagyjából 60 éve legalább) a szoftver fejlesztés egyik legdrágább, legidőigényesebb része a tesztelés lett. És ebbe nem igazán férnek bele az innen-onnan esetleg GPL meg ki tudja még milyen licence alá eső inenne-onnan leszedett libek meg kódrészletek. Ha én átadom a programomat, hogy ez márpedig működik akkor az egész programért felelősséggel tartozom (büntető jogi is! Azaz kattanhat a bilincs, és záródhat a cella ajtó jó pár évre), nem éri meg kockáztatni.

Ugyanez a remote sebezhetőségek, backdoorok. Egy több ezer soros libet átnyálazni azért, hogy van-e benne valami esetleg "elrejtve" nem éri meg egy darab HASH függvény miatt. Elég jól le vannak írva az eljárások (egészen szájbarágósan), az alapján ezek könnyedén megírhatóak, ha valaki látott már a print ("Hello, World!")-nél bonyolultabb programot.

Most próbáltam egy kóddal: ha változó van az osztóban, akkor látványos az eltérés, viszont ilyenkor még a léptetés is sokkal lassabb, mint egyébként. Amúgy pártized másodperc - és van hogy a sima osztás javára.

Tudom, hogy a léptetésnek kellene gyorsabbnak lennie és elismerem, a dokumentáció is arról szólt, amit bemásoltam.

Lehet az is, hogy rosszul csináltam, valósítottam meg, mert "rossz vagyok matekból".

[link]

Akár hash algoritmusokról, akár másmilyenekről tudtok linkelni olyan mondatszerű leírást, ami alapján egy jól képzett programozó meg tudja írni bármilyen nyelven?

A <algoritmus neve> <pseudo code> kulcsszavakra bizonytalan találatok érkeznek, konferencia-kivonatok, "abstract"-ek stb.

Lehet más módon kell keresni ezeket a sikeres találatok érdekében?

#43: Édes f**om, te komolyan Pascalban akarod kipróbálni, hogy a bit shift vagy az osztás-e a gyorsabb? És honnan tudod, hogy a fordító abból milyen kódot generál majd?

Az ilyesmit assemblerben szokás tesztelni, nem magas szintű nyelvben, pláne nem Pascalban

"Amúgy pártized másodperc"

Az ilyesmit nem másodpercben mérjük, mert lehet egy proci 800 Mhz-es is és 4 GHz-es is, hogy más ne is említsek.

A fordítást nulla optimalizációs szinten kell megejteni, mert a fordító már O1-en is bekavar, a standard O2-n meg pláne hozzányúl a kódunkhoz.

Az, hogy az operandus konstans-e vagy változó, nem szabad, hogy számítson, tehát a mérést akkor szabad csak megkezdeni, amikor a literál már a regiszterben van.

A kódot generáltasd ki assembly-be és azt töltsd fel.

Netwide formátumba ha lehet, ne AT&T legyen.

Most néztem bele a kódba. Bazz, O hármon SOHA ne optimalizálj.

Szivatod magad a méréssel.

Időméréshez van egy függvény, GetTickCount a neve. Azt használd.

Fentebb arról volt szó, hogy amikor (a múltban kipróbáltam Pascal-ban az időmérést), akkor "hazudtam" :) most meg bemutatom és jól megkaptam a magamét. Azelőtt még nem volt probléma, hogy Pascal-ban csináltam az időmérést csak az volt mondva: "hazudok".

A GetTickCount "deprecated", a GetTickCount64 használható helyette, de elvileg csak Delphi-kompatibilitásból támogatja.

"A kódot generáltasd ki assembly-be és azt töltsd fel.

Netwide formátumba ha lehet, ne AT&T legyen."

Hmm, fordításkor generálódik egy ".o" fájl, ezzel mit csináljak? :)

Raspberry PI-n lefordítva ezt mondja a ".o" fájlra a file parancs: LF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped