Aritmetika u pokretnom zarezu-koliko je neophodna

Pozdrav mradomir-e,
Bas sam se obradovao kada sam video tvoju poruku, nije te bilo 2 meseca, sigurno si imao neku frku.

Uopste nisam protiv real (ili float) tipa u izrazima, samo sam hteo da vidim koliko programera to koristi. Ali izgleda da neki vise redova ispisu na forumu nego sto ispisu redova programskog koda. Ipak, zahvalan sam nekolicini koja je konkretno odgovorila, a sve ostalo se svelo na diskusiju: sta ce nam PASCAL kada je C super za programiranje mikrokontrolera.

Znas da sam kupio Delphi 2006 (dao sam skoro 1000EUR) i kupio sam ADVMemo od firme TMS Software (jeftino 40EUR). Ali sa ovom komponentom imam probleme. Ranije sam koristio njihov SyntaxMemo sa parserima i to je lepo funkcionisalo. Imao je funkcije da vrati token indeks i token rec (zavisno od pozicije u tekstu) sto je neophodno za sintaksnu analizu. Sada ADVMemo (poboljsana verzija u anglosaksonskom smislu) je sarenija komponenta ali nema parser u vidu tekst fajla. Ima komponentu sintaks stajler sa svojstvima koja dozvoljavaju da se definisu razne grupe reci sa posebno definisanim fontom i atributima. Medjutim ima funkciju koja vraca token na poziciji X,Y kursora (a ne teksta-uzas) pa stalno mora da se pretvara pozicija u tekstu na poziciju X,Y. Sto je najgore vraca token i ako je X,Y na nekoj reci koja je u komentaru, katastrofa. To nije moglo da se desi u SyntaxMemo. Osim toga postoje svojstva za reci koje oznacavaju pocetak i kraj programskog bloka (begin..end) i automatski taj par reci oznaci kada je kursor izmedju njih. Ali ako imas case..end ili repet..until potpuno si nemocan. Help je nikakav pa se mucim da nesto smisleno napravim sa ovom komponentom. To me mnogo usporava u pisanju editora.

Na kraju, ipak cu biti za to da postoji tip sa pokretnim zarezom u izrazima. Razmisljam samo o formatu. Mislim da osnovni bude 8 bita eksponenta i 24 bita mantise. Video sam da signal procesori imaju i format 16 bita eksponenta i 16 bita mantise, sto je razumljivo za te aplikacije. Pitanje je dali pored osnovnog tipa pokretnog zareza treba jos neki, i dali da se ide prema ovome sto je u signal procesorima, ili prema vecoj mantisi. Veca mantisa znaci vecu tacnost i na kvadrat vise procesorskog vremena. Dakle ako postoji real, dali dodati shortreal ili longreal ili ne dodati nista, s obzirom da su svi ucesnici ove teme pisali da su u 2..3% slucajeva koristili realnu aritmetiku.

Srdacan pozdrav.

Prvo da se izvinim što me nema neko vreme,
nekako se nakupilo gluposti koje više imaju
veze sa knjigovodstvom nego sa našom strukom,
ali šta ćeš i sam znaš kako je kada imaš firmu.

Kada je preciznost u pitanju nisam imao potrebe
za nečim boljim od 8+24, odnosno da budem precizniji
1 bit znak, 8 bita eksponent i 23 bita mantisa.
Po IEEE standardu to je "single". Mogu ti poslati
ako ga nisi skinuo (standard).

Parser... hm.. pa evo šta sam ja zaključio posle mnogo
razmišljanja. Editor je tu da izgleda šareno i da pomaže
programeru prilikom pisanja koda. ADVMemo stvarno tu
prednjači. Ja sam istu stvar odradio sa SynEdit-om.
Njegova uloga prestaje kada se klikne na COMPILE.
Dalje stvar prihvata skener koga sam ručno napisao.
Njegov zadatak je da učita fajl u memoriju, čita karakter
po karakter, prepozna tokene (ključne reči), preskače
komentare i slično. Parser od skenera preuzima tokene
proverava sintaksu, poziva generator koda itd.
Tu sam mnogo puta počinjao ispočetka jer mi se nije
svideo kod koga sam malo po malo krpio i dorađivao.
Preporučio bih ti da se uzdaš "u se i u svoje kljuse",
dakle definiši šta je trebalo da odrađuje ADVMemo
(a neradi), pa napiši svoj kod.

Nadam se da sam bar malo pomogao.

Pozdrav,
mradomir.

Dragi korak,
iako ova tema poprima neki ton koji mi se nikako ne svidja, i rado bih sa tim zavrsio, pokusacu jos jednom da kazem o cemu ja pricam, a o cemu ne pricam.

Da ne bih odlutao u neke vlastite vizije, pokusacu da sto direktnije odgovorim na tvoj post, direktno odgovarajuci na tvoje recenice.
Dakle,



Ja uopste nisam zainteresovan za taj dokaz. Vec 50-tak godina se sirom svijeta vodi polemika oko toga bez pojave nekog vizionara koji bi me ubjedio da li je C bolji od Paskala ili Paskal od C, pa sumnjam da bi me i ti ubjedio.
Po mom misljenju, slicnost tih jezika je dovoljno velika, a i svi noviji kompajleri jednog jezika imaju tendenciju da u sebe ugradjuju osobine onog drugog koje ih poboljsavaju, tako da je za mene ta rasprava bespredmetna.
Ako se potrudis da malo pazljivije procitas ono sto sam ja pisao, mogao bi da vidis da sam ja pisao o trenutnom stanju embedded industrije i sta je iz te perspektive ¨smislenije¨ (molim te obrati paznju da sam napisao smislenije, a ne bolje), a ne koji je jezik bolji iz akademske perspektive, ili iz perspektive programiranja za PC.



Ja sam mislio da govorimo o nekom konkretnom primjeru (neces valjda da napravis univerzalni kompajler za sve mikrokontrolere!?), a ne o akademskoj univerzalnosti, jer si ti sam poceo temu sa pitanjem o potrebi FP za mikrokontrolere, a onda zahtijevas neku univerzalnu pricu o Paskalu i C-u na svim platformama iz proteklih pola vijeka. Ja nevidim smisao toga.



Ovakvi komentari me bas ne inspirisu na dopisivanje. Ja sam uvijek za salu, ali ovo mi ima neki drugi prizvuk. Mada mozda gresim.



Ne sjecam se da sam napisao nesto, sto bi te izazvalo da se ovim pravdas.


Pratio sam tu temu, i da sam imao nesto da kazem protiv Paskala, ja bih to vec tada i tamo napisao.


Kada trazis necije misljenje, mislim da treba da budes spreman na negativne kritike jednako kao i na pozitivne. Negativne kritike su u vecini slucajeva korisnije od pozitivnih. Ne trebas se nalaziti uvredjenim ako neko izrazava negativan stav, vec pokusati da iz toga izvuces nesto korisno.
Moze se desiti da je negativna kritika i opravdana. Meni se to desava cesto, ali nemam problema sa tim.


Ja nisam mislio na greske u runtime nego greske u vreme pisanja i debagovanja. U vreme izvrsavanja potpuno je nebitno da li negdje fali zarez ili je algoritam za proracun putanje satelita pogresan ili neko nije nesto dobro zalemio. Sve te greske su fatalne.


Ovo je tacno, ali se pri ovakvoj nekoj izjavi ona mora staviti u neki odredjeni kontekst. Ja sam nedavno saradjivao na jednom projektu ciji je glavni cilj i ideja vodilja za sve bio: da bude ako je moguce jeftiniji od kineskog ekvivalenta, ili bar ne skuplji. E da je u takvom slucaju koriscen neki procesor u kojem bi se projektant mogao raspistoljiti u nekom programskom jeziku visokog nivoa apstrakcije, to bi kostalo ne manje, nego tri puta vise od kineskog uredjaja. To su zakoni trzista. Naravno da je lakse napraviti dig. kameru na visual Basicu nego na C-u, ali nije pitanje sta je lakse, nego sta ces moci da prodas, a to neces moci sigurno, ako si koristio procesor koji je tri puta skuplji nego onaj kod konkurentske firme jer ti je bilo udobnije objektno programiranje od klasicnog.
Tako ti je npr. i kod PC, kad se radi o proizvodnji najzahtjevnijih 3D igrica. Pisi ti njih i u cemu god hoces i u cemu je tebi lakse i udobnije, ali nijedan danasnji PC ih nece svariti ako nisu pisane u C++. I sta tu meni znaci sto je Java portabilnija i udobnija kad to ne moze da radi?



Ja ne znam za neki programski jezik u kome programer ne mora o ovom da razmislja (izuzev za velika slova). A i sto se tice velikih slova, meni to olaksava, a ne otezava posao, jer ih ne koristim stihijski, vec po konvenciji koje se drzim, te mogu odmah da vidim iz upotrebe velikih slova u imenu varijable da li je to funkcija, varijabla, klasa... Slobodu jezika treba usmjeriti u svoju korist, a ne nemarnim odnosom prema njoj sebi otezavati posao.
Ako nekom smeta sto je a =+ b isto sto i a = a + b, onda neka se drzi jedne od te dvije stvari, niko ga netera da nasumice kuca jedno ili drugo,i ja ne vidim sta je tu toliko problematicno.
I kao sto sam vec ranije rekao, malo veca sloboda nego sto je to uobicajeno, mala nedorecenost u nekim stvarima i slicne druge stvari koje postoje u C su namjerno ostavljene za one kojima bi to moglo zatrebati (a u vreme nastanka C-a i s obzirom na njegovu svrhu i namjenu) takvih je bilo mnogo. Zasto npr. tip int nema fiksnu velicinu - pa zato da bi se maksimalno iskoristila masina na kojoj ce program da radi. To pravi probleme oko prenosivosti, ali kad su performanse u pitanju, iskoristi masinu kolko mozes, a kad je prenosivost u pitanju, ogranici se na minimum koji standard garantuje i to je to. Ne moze se o toj osobini jezika govoriti, a da se to nestavi u neki kontekst. U nekom slucaju to je dobro, a u nekom lose. Ja sam srecan kad imam mogucnost da biram, a ne ko onaj magarac sto je stalno gledao lijevo-desno na hranu s ove i one strane, nije mogao da se odluci kud bi prije, pa crko od gladi.


Ko pise lose programe u C-u, pisace lose i u Paskalu. I obrnuto. I opet cu pokusati da stavim stvari u kontekst: najmanje 100 000 linija koda na 8-bitnom mikrokontroleru?!



Na ovo cu odgovoriti tvojim rjecima:


Jos jednom puno pozdrava svima,
ja mislim da ja nemam vise nista pametno da dodam na ovu pricu o C vs Paskal.
Bilo bi mozda dobro da se tema usmjeri na ono pitanje o kome je i pocela.

<sub>[Ovu poruku je menjao Odin D. dana 07.04.2007. u 13:05 GMT+1]

[Ovu poruku je menjao Odin D. dana 07.04.2007. u 13:09 GMT+1]</sub>

Odin D.:

OK, nema smisla da dalje raspravljamo. Nisam imao nameru da uputim ni jednu uvredu, ako jesam izvini. Ponekad u rasparavama volim da pojacam kontrast izmedju dva stava da bi diskusija bila plodotvornija. Aii vidim obojica smo dovoljno tvrdoglavi da to ne pomaze.

Pozdrav.

A taman postade zanimljivo :-(

Ne vredi gubiti vreme mradomir-e.

Ponudio sam da Odin D napise 10 primera na C-u (za koja misli da je prednost na strani C-a, naravno da nisu besmisleni) ali on je to zaobisao i u zadnjem tekstu se bavio analizom onoga sto sam ja napisao.

Inace jos se mucim sa AdvMemo, tezi je za koriscenje, a pravili ga da bude laksi od SynMemo (anglo-saksonska logika).

Pozdrav.

Ne bih da se pravim pametan ali ovo je odlican primer za sta ne treba koristiti FP racun.
Ovo se racuna kao Merene vrednost:= (52*ADkonv-2480)/16, integer deo se dobija jednostvano siftovanjem ulevo za >>4, decimalni deo se dobije ili lookup tabelom ili tezinskim koeficijentima za cetiri bita koja ispadnu. Mnozenje sa 16 uzeto pod pretpostavkom da je AD konv 10-bitni, a da kompajler zna da radi sa 16-bitnim integerima(ja jos nisam video neki koji to ne ume). Ovo je neuporedivo brze od FP racuna, koji ne samo zna da bude spor na 8-bit MCU nego jos operise sa toliko korisnih resursa i brlja po steku da treba strogo voditi racuna kad se koristi npr-u interapt rutini, onda je uvid u generisani ASM neophodan da vidis sta se stvarno desava.