PCPROG.3

26 Jul 1993 - 22 Apr 1994

Messages - pascal

pascal.411 djelovic, -> #407, .bale.
> Dobro, bre, dokle? ;-) Totalno je besmisleno reći da je Pascal brži od > C-a, isto kao i da je C brži od Pascal-a. Nije to toliko glupo. Ta dva jezika jednostavno u nekim delovima imaju različite filozofije rada, od kojih neka može da daje bolje, a neka lošije rezultate. Na primer, C sa stringovima operiše isključivo preko pointera za razliku od recimo Borlandove implementacije Pascala, i tu se uvek pokazuje brži, mada i komplikovaniji za upotrebu.
pascal.412 paki, -> #410, vita
­> Svaka čast za odgovor, podrazumeva se da sam govorio o BORLAND-u... ­> A ako neko zna neki Compiler (Pascal ili C) koji je brzi od gore ­> pomenutih, neka to javno saopšti, bio bih mu vrlo zahvalan. Samo nemoj reći da su spori...
pascal.415 niklaus, -> #395, janko
(:> A šta beše sa onom firmom koja pravi bolje TP prevodioce od (:> Borlanda? Sećam se _formule_ na reklami, ali me mrzi da jurim sad Stony Brook Pascal+. Ništa extra. Što se mene tiče, bolje da ostanem u Porcshe-u. (: (:> Zna li neko nešto više o tome (idealno: ima li program?) Ne, nemam ga. Kad smo se dotakli Paskalja, evo još jednog aduta: QuikByte PASCAL (Quik, bez 'c'). Evo čime nas mami reklama: - Miscrodoft object code compatible .OBJ interface to MASM, MS C, BASIC, FORTRAN, COBOL - True Pascal - ISO/ANSI standards Switch selectable language expresions - Superb math library Unequaled for the PC, in line code generation - Ultra smart optimizing linker for smaller .EXE files (prim. nik. ovo bi moglo da reši krissov problem (:) - Turbo-SC (Turbo Super-Charger) Turbo dialect to QuikByte PASCAL translator (:niklaus:)
pascal.414 niklaus, -> #406, vita
(:> tom polju. Elem , isti algoritam za RAY TRACING u Pascalu i C-u se (:> u C-u BUKVALNO izvrsavao 10 puta sporije! ... Ni ja nisam verovo! Pitanje je kolika je analogija između ta dva programa. Možda bi naj- bolja usporedba bila ta da si C listing dobio uz pomoć jednog iole kvalitetnog TP->TC konvertora. Index odnosa brzine TC:TP ne možeš formirati na osnovu tog usamljenog primera. (:niklaus:)
pascal.416 .bale., -> #411, djelovic
> Nije to toliko glupo. Ta dva jezika jednostavno u nekim delovima imaju > različite filozofije rada, od kojih neka može da daje bolje, a neka > lošije rezultate. Na primer, C sa stringovima operiše isključivo preko > pointera za razliku od recimo Borlandove implementacije Pascala, i tu > se uvek pokazuje brži, mada i komplikovaniji za upotrebu. Hm, zaista. C je, pošto je prljav, osuđen da sa stringovima radi preko pointera i to se teško drugačije može implementirati (?). Pascal je malo višeg nivoa i, pretpostavljam, moguće su razne implementacije raznih stvari. Pa sad, ako C ne može biti u radu sa stringovima brz kao Pascal, onda Pascal može biti spor kao C :) Ali, na kraju, ta razlika u radu sa stringovima se vidi na nivou izvornog koda, tj. sami programi se uglavnom razlikuju. Da bi se testirali sami kompajleri, trebalo bi napraviti iste programe: ili da se Pascal uspori, tj. ne koriste njegovi stringovi nego pointeri, ili da se u C-u definiše nova struktura string, ista kao ona u Pascal-u...
pascal.417 ppekovic, -> #416, .bale.
>> Hm, zaista. C je, pošto je prljav, osuđen da sa stringovima radi preko >> pointera i to se teško drugačije može implementirati (?). Koristeći C++ možeš definisati String klasu koju možeš napraviti da radi potpuno isto kao Pascal tip string. Paya
pascal.418 vita, -> #414, niklaus
> bolja usporedba bila ta da si C listing dobio uz pomoć jednog > iole kvalitetnog TP->TC konvertora. Index odnosa brzine TC:TP > ne možeš formirati na osnovu tog Pa jel imas neki "iole kvalitetan TP->TC konverter" ?? BTW, original source je pisan u Pascalu, a C source je bukvalno Pascal source sa prepravljenim jezičkim nesuglasicama(pr:begin->š) Ajd sad.. Vita
pascal.419 vita, -> #416, .bale.
> izvornog koda, tj. sami programi se uglavnom razlikuju. Da bi > se testirali sami kompajleri, trebalo bi napraviti iste > programe: ili da se Pascal uspori, tj. ne koriste njegovi > stringovi nego pointeri, ili da se u C-u definiše nova > struktura string, ista kao ona u Pascal-u... Pa zasto bi se Pascal NAMERNO usporava da bi se spustio na nivo C-a???? Ako je jezik brzi, onda je BRZI! Merite vi brzinu algoritama i tako nekih stvari, TO presuđuje! Uvek odaberi jezik koji će odgovarati tvom trenutnom poslu! (i tako on odabra C iako Pascal brze renderiše :) ) Vita
pascal.420 vitez.koja, -> #419, vita
#=> Pa zasto bi se Pascal NAMERNO usporava da bi se spustio #=> na nivo C-a???? To nije usporavanje, to je realno odmeravanje snaga pri istim uslovima. Primer sa stringovima ide možda u korist TURBO paskala, no nije teško naći primere gde je C 'na svome'. #=> Ako je jezik brzi, onda je BRZI! Ajde ?! :) #=> Merite vi brzinu algoritama i tako nekih stvari, TO #=> presuđuje! To ne može da se izmeri. Merljive su jedino brzine izvršavanja IMPLEMENTACIJA nekog algoritma u raznim programskim jezicima, gde ljudski (programerski) faktor itekako utiče na rezultat, svakako više nego sam jezik.
pascal.421 kriss, -> #415, niklaus
˙˙ Kad smo se dotakli Paskalja, evo još jednog aduta: QuikByte ˙˙ PASCAL ˙˙ - Ultra smart optimizing linker ˙˙ for smaller .EXE files ˙˙ (prim. nik. ovo bi moglo da reši krissov problem (:) Toooooo! Što manji .EXE, pa pklite, pa samoraspakujući ZIP, pa će valjda da se sabije sve na par K a da ima menije, prozore, miša ... :)))) Šala, naravno, nego jel zna neko gde može da se nađe taj Pascal?
pascal.422 niklaus, -> #418, vita
(:> Ajd sad.. Opet to ne mora da implicira (: zaključku da je TP 10x brži od TCa (čudi me što uopšte postoji situacija u kojoj se to (bez namere) može postići). Biće da se korišćene strukture bolje optimizuju (for speed) u TPu. Ako bi se potrudio, siguran sam da bi nešto mogao da učiniš i za C "ekivalent". (:niklaus:) ps Da ne bude zabune, favorit Niklausa je TP. (: pps Pošalji, pa da vidimo šta si uradio. Naravno ako je PD. (;
pascal.423 .bale., -> #417, ppekovic
> Koristeći C++ možeš definisati String klasu koju možeš > napraviti da radi potpuno isto kao Pascal tip string. Pa to sam i napisao, otprilike...
pascal.424 .bale., -> #419, vita
> Pa zasto bi se Pascal NAMERNO usporava da bi se spustio na nivo > C-a???? vitez.koja ti je odgovorio. Ne bih imao šta posebno da dodam. Mojne da se žestiš, budi strpljiv :)
pascal.425 ognjen, -> #372, a.kircanski
)-> Pa, ako si bejzikaš i prelaziš na paskal, onda ćeš koristiti )-> label-e, isto ti se 'vata. :) Jok, ja mrzim GOTO petlje... Iako sam bej... (ne smem da izgovorim ;) i prelazima na Pascal... :)
pascal.426 ognjen, -> #379, dr.grba
[ja] )-> >> je loša (u odnosu na Pascal). Zašto? Pa, kao prvo, )-> >> kada startuješ neki Basic program on se učitava liniju po )-> >> liniju, [dr.grba] )-> Ti govoriš o Basic interpreterima, a ovde je reč o Basic )-> kompajlerima. [ndragan] )-> Ova priča nema veze sa odnosom bejzik-paskal, nego sa odnosom )-> interpreter - kompajler. Turbo bejzik je bio kompajler kao i )-> turbo paskal, prema tome nije to razlika. Zez, sorry, pokrivam se ušima... :)
pascal.427 djelovic, -> #420, vitez.koja
> To nije usporavanje, to je realno odmeravanje snaga pri istim uslovima. > Primer sa stringovima ide možda u korist TURBO paskala, no nije teško naći > primere gde je C 'na svome'. Ma ne znam kako ste uopšte došli do ovoga. C stringovi su BRčI, baš zbog rada sa pointerima. Jedino što su i mnogo teži za upotrebu :(.
pascal.428 madamov, -> #419, vita
> Ako je jezik brzi, onda je BRZI! Ne postoji takav kriterijum kojim bi izmerio koji je jezik brži. Možeš sam da meriš koji kompajler pravi brže programe.
pascal.429 vitez.koja, -> #427, djelovic
#=> Ma ne znam kako ste uopšte došli do ovoga. C stringovi #=> su BRčI, baš zbog rada sa pointerima. Jedino što su i #=> mnogo teži za upotrebu :(. ################ <- unapred se ograđujem, možda i ne znam šta pričam :) Kako se stiglo do toga da su TP operacije sas stringovi brže, ne znam. Samo sam hteo da kažem kako, ako su stingovu u paskalu i brži, nije teško naći nešto u Cu što šije paskal po brzini. Drugo, kako 0 završeni stringovi mogu biti brži od TP-like stringova ? Uzmimo kao primer kopiranje jednog stringa u drugi. Šta se dešava: TP C memcpy(str2, str1, *str1+1); while(*str2++=*str1++); Prvi (TP) način se realizuje pomoću REP MOVSB instrukcije, dok je za drugi potrebna nekakva JNZ petlja. Po mom skromnom znanju, prvi pristup je brži. Naravno, tu je i najdrastičniji primer - vraćanje dužine nekog stringa. Kod Ca i njemu sličnih ;) tu je potrebna petlja, kod TPa samo naredba dodele (len=string[0]).
pascal.430 djelovic, -> #429, vitez.koja
> Drugo, kako 0 završeni stringovi mogu biti brži od TP-like stringov > Uzmimo kao primer kopiranje jednog stringa u drugi. Šta se dešava: > > TP C > > memcpy(str2, str1, *str1+1); while(*str2++=*str1++); > > Prvi (TP) način se realizuje pomoću REP MOVSB instrukcije, dok je z > drugi potrebna nekakva JNZ petlja. Po mom skromnom znanju, prvi pristup je > brži. > > Naravno, tu je i najdrastičniji primer - vraćanje dužine nekog stri > Kod Ca i njemu sličnih ;) tu je potrebna petlja, kod TPa samo naredba dodel > (len=string[0]). Well, jedna string naredba je u Paskalu očigledno brža od svog C pandana, ali prednost C-a je u tome što u jednoj ili dve kratke petlje začas može da uradi nešto za šta u Paskalu treba mnogo više. Recimo, ako trebaš da ubaciš neko slovo u string, ti ćeš u Paskalu preko left i right razdvojiti string pa ga opet sastaviti. C, naprotiv, ceo posao obavlja u jednoj petlji. Koliko je to brže od silnog kopiranja stringova (do čega zapravo dolazi pri pozivima funkcija left & right) ne treba posebno naglašavati.
pascal.431 spantic, -> #420, vitez.koja
>#=> Merite vi brzinu algoritama i tako nekih stvari, TO >#=> presuđuje! > > To ne može da se izmeri. Merljive su jedino brzine izvršavanja > IMPLEMENTACIJA nekog algoritma u raznim programskim jezicima, gde ljudski > (programerski) faktor itekako utiče na rezultat, svakako više nego sam To nije baš tačno. Itekako su merljive brzine algoritama. Imaš analizu složenosti algoritama. Možeš imati vremensku složenost i prostornu složenost. U današnje vreme je kanda aktuelna samo vremenska ;) Nikako ti nije svejedno da li imaš polinomijalan ili eksponecijalni algoritam. Ma imao ti i najbolji prevodilac, isti ti nimalo neće pomoći ako koristiš neki eksponencijalni "žderač".
pascal.432 dejanr, -> #431, spantic
>> To nije baš tačno. Itekako su merljive brzine algoritama. Imaš analizu >> složenosti algoritama. Možeš imati vremensku složenost i prostornu >> složenost. U današnje vreme je kanda aktuelna samo vremenska ;) Slažem se. Zapravo, kompajleri vrše optimizacije i to se vidi kroz brzinu rada programa, ali su tu retki spektakularni dobici. Sa druge strane, zamena algoritma *zaista* može da dovede do spektakularnog dobitka, čak i do većeg nego kada se program sa XT-a prebaci na Pantium. Primera za to ima puno, recimo svojevremeno je jedan od zadataka bilo pronalaženje savršenih brojeva (broj koji je jednak zbiru svih svojih delilaca, recimo 28 = 1+2+4+7+14). "Zdravorazumskim" algoritmom je za pronalaženje svih savršenih brojeva u numeričkom opsegu rada računara bilo potrebno recimo par meseci "žvakanja" brojeva, a sa dobrim algoritmom par sekundi. Time, naravno, ne želim da umanjim značaj dobrih optimizacionih kompajlera.
pascal.433 uobradovic,
Ova formula mi je potrebna z Ova formula mi je potrebna za jedan program,mislim zadatak GLEDAJTE: a = 1 +(3 korena iz r) Kako se to pise na Pascalu ? )
pascal.434 dejanr, -> #433, uobradovic
>> GLEDAJTE: a = 1 +(3 korena iz r) Nešto kao: a:=1+exp(log(r)/3)
pascal.435 vita, -> #428, madamov
> Ne postoji takav kriterijum kojim bi izmerio koji je jezik > brži. Možeš sam da meriš koji kompajler pravi brže programe. Pa Naaravno, na to sam i mislio...ali ako si procito koju poruku pre ove... (mrzi me da trazim ko je reko) rece covek..sasvim ispravno Ideje nekih jezika su u startu slabije!, tako da ma koliko dobar komajler bio on ce morati da radi sporije.. (pr: C i Pascal , stringovi) Vita
pascal.436 peca.st, -> #430, djelovic
!-> neko slovo u string, ti ćeš u Paskalu preko left i right !-> razdvojiti string pa ga opet sastaviti. C, naprotiv, ceo posao !-> obavlja u jednoj petlji. Koliko je to brže od silnog kopiranja !-> stringova (do čega zapravo dolazi pri pozivima funkcija left & !-> right) ne treba posebno naglašavati. Left i right? To je iz bejzika, u Pascalu to je Copy. :) Inače, to što kažeš može se u pascalu isto uraditi u jednoj petlji! Evo ovako: Procedure UturiSlovo (Var S : String; Gde : Byte; Sta : Char); Var i : byte; Begin Inc (SŠ0Ć); For i := Length (S) downto Gde + 1 do SŠiĆ := SŠi-1Ć; S ŠGdeĆ := Sta; End; Ovo je onako iz glave, valjda nisam pogrešio. :) (podrazumeva se da je ulazni string kraći od 255 karaktera, da bi mogao nešto da uturiš ;) u njega) Peđa. P.S. Sori na Yuscii.
pascal.437 peca.st, -> #434, dejanr
!->>> GLEDAJTE: a = 1 +(3 korena iz r) !-> !-> Nešto kao: !-> !-> a:=1+exp(log(r)/3) !!! ! Zar ne ide ovde ln ? Osim toga, mislim da je njemu trebalo ovo: a := 1 + 3*sqrt(r); Dakle, mislim da je on tražio 3 * koren iz r, a ne treći koren iz r. Peđa.
pascal.438 eagle, -> #434, dejanr
> a:=1+exp(log(r)/3) """ Lapsus, treba ln. Ako osnova nije navedena uzima se 10, ovde treba e. Btw, log za navedenu osnovu bi išao ovako: log(osnova,x) = ln(x)/ln(osnova)
pascal.439 dejanr, -> #437, peca.st
>> Zar ne ide ovde ln ? Imaš pravo, sorry. Glupi Turbo Pascal ima samo ln... a i inače je dosta siromašan sa funkcijama, ne znam što mu ne dodaše arcsin, arccos, stepenovanje i slične potrebne stvari. >> Dakle, mislim da je on tražio 3 * koren iz r, a ne treći koren iz r. Možda... meni je pre ličilo na treći koren iz r. Sada ima i jedno i drugo, pa će uzeti šta treba :)
pascal.440 dejanr, -> #438, eagle
>> Lapsus, treba ln. Ako osnova nije navedena uzima se 10, ovde treba e. U pravu si za lapsus, ali ako osnova nije navedena (a ne može se ni navesti) uzima se e.
pascal.445 madamov, -> #435, vita
> Ideje nekih jezika su u startu slabije!, tako da ma koliko dobar komajler bio > on ce morati da radi sporije.. (pr: C i Pascal , stringovi) I na osnovu toga zaključuješ da je Pascal brži od C-a na nivou jezika? Hm, nedovoljno parametara...
pascal.446 vitez.koja, -> #430, djelovic
#=> uradi nešto za šta u Paskalu treba mnogo više. Recimo, #=> ako trebaš da ubaciš neko slovo u string, ti ćeš u #=> Paskalu preko left i right razdvojiti string pa ga opet #=> sastaviti. C, naprotiv, ceo posao obavlja u jednoj #=> petlji. Nisam čuo za funkcije Left i Right, a ovde govorimo isključivo o Turbo Paskalu u kome one ne postoje. Umesto toga, tamo imaš funkciju "insert" koja radi umetanje stringa u string, a sklon sam poverovati da je pisana u asembleru. Inače, sada kada sam malo razmislio o celoj stvari, koristeći svoja skromna znanja, prilično sam siguran da nećeš naći primer kod koga su C-like stringovi brži od TPovih.
pascal.447 vitez.koja, -> #431, spantic
#=> To nije baš tačno. Itekako su merljive brzine #=> algoritama. Imaš analizu složenosti algoritama. Možeš Da, ali nije bitno. Odgovarao sam na poruku iz čijeg konteksta se vidi da se misli na merenje brzine jednog algoritma u više jezika, a ne više algoritama u jednom jeziku. Nadam se da se slažeš da je u tom sučaju ljudski faktor presudan.
pascal.448 eagle, -> #440, dejanr
>>> Lapsus, treba ln. Ako osnova nije navedena uzima se 10, ovde >>> treba e. > U pravu si za lapsus, ali ako osnova nije navedena (a ne može > se ni navesti) uzima se e. Rečenica se odnosila na log u tvojoj poruci :)
pascal.449 vita, -> #445, madamov
> I na osnovu toga zaključuješ da je Pascal brži od C-a na nivou > jezika? Hm, nedovoljno parametara... Neznam da li shavats o cemu smo pricali! Sto se tice stringova konkretno...jedan je jezik sigurno brzi od drugog , barem malo!...nisam reko koji i za koliko , ali sigurno jeste. Tako da u zavisnosti sta covek radi treba odabrati odgovarajuci jezik+Compiler... Vita
pascal.450 vita, -> #447, vitez.koja
> misli na merenje brzine jednog algoritma u više jezika, a ne > više algoritama u jednom jeziku. Nadam se da se slažeš da je u > tom sučaju ljudski faktor presudan. E pa nece biti...ne zavisi sve od Ljuda :) koji se bavi programiranjem!! Od toga koliko dobro poznaje jezike i programiranje je solidan faktor. Ali kod klasicnog prevodjena negog algoritma iz jednog jezika u drugi (bez vecih promena ideje) je od presudnog znacaja koliko je jezik(compiler) dobar!!! Valjda se sa ovime slazes. Vita
pascal.451 uobradovic,
Hvala na pomoci,ali izgleda da ja to neznam da napisem ili me pascal zeza. Evo sta sam napisao : var a,r : integer; begin writeln ('unesi r '); readln (r); a := 1 + exp(ln(r)/3); writeln ('prvi broj je ',a); writeln ('drugi broj je ',a-1); end. I sta.On mi napise Type mismatch. Koji mu je K***C. Trazio sam treci koren iz r. Hvala na pomoci Uros :)
pascal.452 drpr, -> #434, dejanr
-> Nešto kao: -> -> a:=1+exp(log(r)/3) Mislim da treba da se i ubaci i za znak jer treći koren se može vaditi i od negativnog broja znači valjda ide kao a:=1+ sgn(r)*exp(log(r)/3) cope
pascal.453 drpr, -> #451, uobradovic
-> var a,r : integer; -> a := 1 + exp(ln(r)/3); A nije integer , tj posle ove naredbe rezultat koji se dodeljuje u a će biti realan teko da je tu greška! cope
pascal.455 eagle, -> #451, uobradovic
> Evo sta sam napisao : > var a,r : integer; > a := 1 + exp(ln(r)/3); var a: real;
pascal.454 eagle, -> #452, drpr
> Mislim da treba da se i ubaci i za znak jer treći koren se može > vaditi i od negativnog broja znači valjda ide kao Može koren, ali ne može logaritam. Treba: a:= 1 + sgn(r) * exp(log(abs(r))/3)
pascal.456 peca.st, -> #450, vita
!-> Ali kod klasicnog prevodjena negog algoritma iz jednog jezika u !-> drugi (bez vecih promena ideje) je od presudnog znacaja koliko je !-> jezik(compiler) dobar!!! Ne mora da bude. Kod koji si pisao u jednom kompajleru, dakle specijalno za njega, kada prevedeš sintaksno (ako je moguće) na kod koji će biti dostupan drugom kompajleru, ne mora da reprezentuje odnos brzine ta dva kompajlera, zato što si ti pri pisanju koristio neke mogućnosti prvog kompajlera, optimizovao si kod rukovodeći se kompajlerom, a u drugom kompajleru to se, recimo, sporije izvršava, ali postoji način da uradiš isto onako brzo kao u prvom komp., a možda postoji način da isto to uradiš i brže. Nije dovoljno samo sintaksno prevesti, moraju se vršiti semantičke optimizacije. Peđa.
pascal.457 peca.st, -> #451, uobradovic
!-> var a,r : integer; !-> a := 1 + exp(ln(r)/3); !-> I sta.On mi napise Type mismatch. !-> Koji mu je K***C. Logaritamska funkcija, tačnije u ovom slučaju funkcija korenovanja je, jasna stvar, realna a ne celobrojna. Ti pokušavaš da celobrojnoj promenljivoj dodeliš realan broj, a to neće ići. Promeni prvi red u "var a,r : real;" i radiće bez problema. !-> Trazio sam treci koren iz r. Ok, ja sam "3 korena iz r" shvatio drugačije. :) Peđa.
pascal.458 dejanr, -> #450, vita
Odgovor u temi PC.PROG/dizajn, poruka 2.12
pascal.459 dejanr, -> #451, uobradovic
Prvo, pogrešno si deklarisao brojeve, treba da budu real ili još bolje extended (ako nemaš koprocesor, moraš emulaciju da uključiš, dakle na početku programa {$N+,E+} ili tako nešto. Drugo, ln je definisan samo za pozitivne brojeve, nulu bi morao da ispitaš sa if, a za negativne brojeve da koristiš abs() pa da posle pomnožiš sa znakom od broja.
pascal.460 mpaunovic,
Ova rasprava o trećem korenu me je podsetila na nešto što se valjda učilo iz matematike, ali ja mora biti da nisam bio na času ili sam igrao podmornica. Pa ako može neko da me prosvetli: Recimo x**3 = 1, rešenje je x=1, jeli tako? Jeste :) Medjutim to je i jednačina trećeg stepena, x**3 - 1 = 0 i ona bi znači trebala da ima tri rešenja. A nema. Da li ta jednačina je izuzetak od tog pravila, ili ima rešenja koja su jednaka sva tri?
pascal.461 dejanr, -> #460, mpaunovic
>> Recimo x**3 = 1, rešenje je x=1, jeli tako? Jeste :) >> Medjutim to je i jednačina trećeg stepena, x**3 - 1 = 0 >> i ona bi znači trebala da ima tri rešenja. A nema. Da li >> ta jednačina je izuzetak od tog pravila, ili ima rešenja >> koja su jednaka sva tri? Dobro pitanje, ali ni jedan od dva ponuđena odgovora nije tačan ;) Prvo, pravilo da jednačina N-tog stepena ima tačno N nula je toliko fundamentalno da ga nazivaju "Osnovnim stavom algebre". Tu nema izuzetaka (ako izuzmemo recimo jednačinu n-tog stepena koja uz x^n ima koeficijent 0, jer to i nije jednačina n-tog stepena nego najviše (n-1)-og). Konkretno, jednačina trećeg stepena (a i pomenuta x^3-1=0 je svakako jednačina trećeg stepena) ima uvek tri nule. E sad, neke dve od te tri nule mogu izuzetno da budu jednake, a mogu i sve tri, u kom slučaju je u pitanju jednačina koja se može svesti na trivijalan oblik (x-a)^3=0. Međutim, data jednačina nema jednaka rešenja - ima ih tri i sva tri su različita! Sve to izgleda nemoguće ali nije - jedno rešenje je zaista x=1 a preostala dva su -1/2+j(sqrt(3)/2) i -1/2-j(sqrt(3)/2). Kao što se vidi, druga dva rešenja su kompleksni brojevi, pri čemu je j=sqrt(-1). Uopšte, ako se uzme neki kompleksan broj z=a+bj (a i realan broj je u opštem slučaju kompleksan, samo što je b=0) a zatim predstavi u obliku: Z=RO*(cos FI + j*sin FI) njegov n-ti koren imaće n vrednosti i one će glasiti Y1,2,...n = RO'*(cos ((FI+2*k*PI)/n) + j*sin ((FI+2*k*PI)/n)) gde je RO' n-ti koren iz RO, PI je broj Pi (3.1415...) a k uzima vrednosti 1, 2, ... n. Ako nekoga zanima, mogu da pošaljem (u PC.PROG/algoritmi) algoritam za rešavanje jednačine trećeg stepena i program koji je rešava. Za razliku od većine algoritama koje ćete naći po knjigama, ovde su pokriveni *svi* slučajevi, dakle i razni trivijalni koji se obično preskaču.
pascal.462 dvesic, -> #461, dejanr
>> Ako nekoga zanima, mogu da posaljem (u PC.PROG/algoritmi) >> algoritam za resavanje jednacine treceg stepena i program koji >> je resava. Za razliku od vecine algoritama koje cete naci po >> knjigama, ovde su pokriveni *svi* slucajevi, dakle i razni >> trivijalni koji se obicno preskacu. Zanima ! Zanima !
pascal.463 madamov, -> #449, vita
> Neznam da li shavats o cemu smo pricali! Shvatam ja, ali u tvojim porukama ne piše baš ono što hoćeš da kažeš. B) A tvoja poruka bi trebalo da bude otprilike: kada je o stringovima reč, Pascal bi zbog svoje organizacije podataka ovakvog tipa trebalo da bude brži od C-a. I to je diskutabilno, recimo operacija kopiranja stringa bi trebalo da bude iste brzine, dok bi po tom rezonu funkcije tipa strcat, strrchr i slične u C-u bile sporije, tj. sve one koje kao reper imaju kraj stringa. S druge strane, traženje karaktera sa leve strane u nekom stringu bi opet trebalo da ide istom brzinom. I za strcat je diskutabilno, C treba samo da nađe kraj stringa na koji lepiš drugi string i na tom mestu uradi strcpy, dok Pascal odmah zna gde je kraj stringa, ali mora da izbaci dužinu drugog stringa, zalepi ga na prvi i onda sabere njihove dužine i upiše na početak prvog stringa. Sve u svemu, mnogo priče da bi se dokazalo nešto što i pored svega navedenog ipak zavisi samo od implementacije jezika, tj. od kompajlera.
pascal.464 v.nesic, -> #461, dejanr
> Ako nekoga zanima, mogu da pošaljem (u PC.PROG/algoritmi) algoritam za Zanima :)
pascal.465 paki, -> #461, dejanr
­> Ako nekoga zanima, mogu da pošaljem (u PC.PROG/algoritmi) algoritam za ­> rešavanje jednačine trećeg stepena i program koji je rešava. Za razliku ­> od većine algoritama koje ćete naći po knjigama, ovde su pokriveni *svi* ­> slučajevi, dakle i razni trivijalni koji se obično preskaču. Bilo bi fino :) Nego, pade mi na pamet jedna stvar. Da li je operacija 'kvadratni koren' definisana i za brojeve manje od nule?
pascal.466 gavros, -> #433, uobradovic
> GLEDAJTE: a = 1 +(treći koren iz r) > Kako se to pise na Pascalu ? U Turbo Pascal-u bi to izgledalo ovako: var b:real; function treci_koren(a:real):real; begin if(a>0)then treci_koren:=exp(ln(abs(a))/3) else if(a<0) then treci_koren:=-exp(ln(abs(a))/3) else treci_koren:=0 end; begin readln(b); writeln(treci_koren(b)+1); end. Ovo je za probu,uneseš broj i rezultat će biti 1+treći koren(broj). Pozdrav.
pascal.467 spantic, -> #447, vitez.koja
> misli na merenje brzine jednog algoritma u više jezika, a ne više > algoritama u jednom jeziku. Nadam se da se slažeš da je u tom sučaju > ljudski faktor presudan. Da, upravo tako. Dejanr je izneo primer koji nam je Joza stalno probijao uši sa časova iu PJMP-a oko alociranja manipulacije sa matricom. Mehaničko prebacivanje algoritma tu neće nimalo pomoći.
pascal.468 vita, -> #456, peca.st
> isto onako brzo kao u prvom komp., a možda postoji način da > isto to uradiš i brže. Nije dovoljno samo sintaksno prevesti, > moraju se vršiti semantičke optimizacije. Na to sam mislio kad sam reko "bez veše promene ideje" Pod idejom sam smatrao program kakav je napisan u izvornom jeziku! Prevođenje programa iz C-a u Pascal ce ici mnogo bezbolnije i bez "veše promene ideje" nego prevođenje programa iz C-a u BASIC Vita
pascal.470 vita, -> #463, madamov
> priče da bi se dokazalo nešto što i pored svega navedenog ipak > zavisi samo od implementacije jezika, tj. od kompajlera. Cek malo.... Ali cela ideja ANSI C-a je u tome da stringovi budu onakvi kakvi jesu u C-u (isto vazi i za Pascal). Pa prema tome, neke stvari jednostavno su odredjene u napred i ma koliko dobar kompajler bio, one su jednostavno brče! (Pr: len() u C-u i Pascalu) Vita
pascal.469 vita, -> #460, mpaunovic
> Recimo x**3 = 1, rešenje je x=1, jeli tako? Jeste :) > Medjutim to je i jednačina trećeg stepena, x**3 - 1 = 0 > i ona bi znači trebala da ima tri rešenja. A nema. Da li Pa kako recimo kvadratna jednacina kad je Determinanta=0 ima samo jedno resenje! (dva ista) Eto ti odgovor. Vita
pascal.471 pedjak, -> #465, paki
> Nego, pade mi na pamet jedna stvar. Da li je operacija 'kvadratni > koren' definisana i za brojeve manje od nule? Nije u skupu realnih brojeva.
pascal.472 debelijencija, -> #461, dejanr
Nije da se bunim, ali radi održavanja matematičke pismenosti... :) Ovo što si ti odgovorio čoveku odnosi se na polje kompleksnih brojeva. U polju realnih brojeva ova jednačina ima jedno rešenje i to baš 1. Jednostavno: xž3-1=0 <=> (x-1)(xž2+x+1)=0 <=> x=1 ili xž2+x+1=0. Sada imamo: xž2+x+1=(x+1/2)ž2+3/4 > 0, dakle, nema više rešenja. Ono što si rekao za polje kompleksnih brojeva tačno je, uz par sitnih prepravki koje slede... !=?> pravilo da jednačina N-tog stepena ima tačno N nula je !=?> toliko fundamentalno da ga nazivaju "Osnovnim stavom !=?> algebre". Tu nema izuzetaka (ako izuzmemo Pre svega, jednačina nema nule, nego rešenja, a polinom ima nule. Ipak, to nije toliko bitno koliko da to nije Osnovni stav algebre. Osnovni stav algebre je: Teorema: Svaki polinom sa realnim koeficijentima ima jednu kompleksnu nulu. Koristeći taj stav može se dokazati da ih ima onoliko koliki mu je stepen, pri čemu se koristi Bezuov stav, pa posle još preneti na oblast jednačina. Inače, vrlo je bitno da su svi koeficijenti realni! !=?> dva rešenja su kompleksni brojevi, pri čemu je j=sqrt(-1). U novijoj literaturi imaginarna jedinica se označava sa i, ali to nije toliko bitno koliko da ne može da se piše sqrt(-1)! Jednostavno, koren za negativne brojeve nije definisan. Doduše, ovo važi za realne brojeve, ali korenovanje kompleksnih brojeva nije funkcija, jer da ima više vrednosti za isti broj. (Interesanto je, da je u polju kompleksnih brojeva: sqrt(-1)=˝i ! :) Dakle, i je rešenje jednačine: xř=-1, tj.: Definicija: i je broj za koji važi iř=-1. Uopšte, jednačina xř=-1 je vrlo važna jednačina u razvoju matematike, jer su zbog nje izmišljeni kompleksni brojevi...
pascal.473 dejanr, -> #469, vita
>> > Recimo x**3 = 1, rešenje je x=1, jeli tako? Jeste :) >> > Medjutim to je i jednačina trećeg stepena, x**3 - 1 = 0 >> > i ona bi znači trebala da ima tri rešenja. A nema. Da li >> >> Pa kako recimo kvadratna jednacina kad je Determinanta=0 >> ima samo jedno resenje! (dva ista) Eto ti odgovor. Nije to odgovor. Kvadratna jednačina koju opisuješ zaista ima dva jednaka rešenja, ali jednačina trećeg stepena koju je naveo ima tri rešenja, i to različita. Jedno od njih je realan broj, a preostala dva su kompleksni.
pascal.474 peca.st, -> #465, paki
!-> Nego, pade mi na pamet jedna stvar. Da li je operacija 'kvadratni !-> koren' definisana i za brojeve manje od nule? Paki, učićeš to u trećoj godini, ima da ti bude muka. ;) So, jeste definisana u polju kompleksnih brojeva. Kako je i = sqrt (-1) (dejanr je ovo obeležavao sa j, mada su nas učili sa i) tako se sqrt(x), x<0, predstavlja kao i*sqrt(abs(x)) žemu ovo služi, osim da bi prvo tromesečje u trećoj godini iz algebre u MG bilo dosadno, pojma nemam. Peđa.
pascal.475 paki, -> #472, debelijencija
­> Teorema: Svaki polinom sa realnim koeficijentima ima jednu kompleksnu ­> nulu. Možda treba: '...ima _bar_ jednu kompleksnu nulu.'.
pascal.476 maksa, -> #472, debelijencija
>> nule. Ipak, to nije toliko bitno koliko da to nije Osnovni >> stav algebre. Osnovni stav algebre je: >> Teorema: Svaki polinom sa realnim koeficijentima ima jednu >> kompleksnu nulu. Digresija, šum & zanimljivost - OTA je inače bila Gausov doktorat.
pascal.477 niklaus, -> #473, dejanr
(:> ima tri rešenja, i to različita. Jedno od njih je realan broj, (:> a preostala dva su kompleksni. I to da važi: x1=a+ib i x2=a-ib (x1,x2 ţ CĐR) (:niklaus:)
pascal.478 pedjak, -> #472, debelijencija
> Teorema: Svaki polinom sa realnim koeficijentima ima jednu > kompleksnu nulu. Ne. Teorema glasi: Svaki kompleksan polinom P, dg P ˛1 ima bar jedan koren.
pascal.479 vita, -> #473, dejanr
> Nije to odgovor. Kvadratna jednačina koju opisuješ zaista ima > dva jednaka rešenja, ali jednačina trećeg stepena koju je naveo > ima tri rešenja, i to različita. Jedno od njih je realan broj, > a preostala dva su kompleksni. Ma ok u vezi toga. Ali sta ce uopste ovolika rasprava u PC.PROG.pascal????? :))))
pascal.480 vita, -> #474, peca.st
> Paki, učićeš to u trećoj godini, ima da ti bude muka. ;) Za r neucismo mi to u II-oj??? kod nas u mg mislim.
pascal.481 madamov, -> #470, vita
> Ali cela ideja ANSI C-a je u tome da stringovi budu onakvi kakvi jesu u C-u > (isto vazi i za Pascal). Tako je bilo od početka, nema veze sa ANSI C-om.
pascal.482 peca.st, -> #475, paki
!-> Možda treba: '...ima _bar_ jednu kompleksnu nulu.'. Ne, gosn. Neša Lazarević insistira na tome da je dovoljno reći "ima jednu kompleksnu nulu" ! Peđa.
pascal.483 dekiper, -> #474, peca.st
>! -> Nego, pade mi na pamet jedna stvar. Da li je operacija 'kvadratni >! -> koren' definisana i za brojeve manje od nule? Možda i jeste, ko zna. Bilo bi logično da ako je sqrt(9)=3, da je onda sqrt(-9)=sqrt(9)*sqrt(-1). Pošto se sqrt(-1) popularno zove i imagina- rna jedinica onda sve što treba da uradiš je da promeniš predznak iz - u + i da posle dodaš ovo sqrt(-1). Konkretno: program korenje; š :))))) ć Var broj:real; begin readln(broj); if broj > 0 then writeln(sqrt(broj)); else if broj=0 then writeln(0); else if broj < 0 then writeln(sqrt(-broj),'i'); end. Pozdrav, Deki BTW, ne zamerite na eventualnim sintaksnim greškama u prg-u. Šta ću, na- vikao sam se na C.
pascal.484 peca.st, -> #480, vita
!-> Za r neucismo mi to u II-oj??? kod nas u mg mislim. Kompleksne brojeve smo učili ove godine, ili ja imam rupe u sećanju. ;) Peđa.
pascal.485 mpaunovic,
Zahvaljujem se svima na odgovoru oko kompleksnih brojeva i jednacine treceg stepena. Mnogo sam naucio novih stvari, a neke sam i znao ranije to jest predavane su na fakultetu ali je to davno bilo pa sam pozaboravljao. Inace i kod nas su imaginarnu jedinicu zvali j - valjda je tako zovu inzenjeri, a matematicari kazu i. Ne znam odakle razlika
pascal.486 paki, -> #474, peca.st
­> Kako je i = sqrt (-1) (dejanr je ovo obeležavao sa j, mada su nas učili ­> sa i) tako se sqrt(x), x<0, predstavlja kao i*sqrt(abs(x)) Pa ne može ovako, komšija :) Nas profa uči da sqrt:R->R, a da je i*i=-1. Možda ćemo u trećoj godini proširiti definiciju, ali za sada je ovako :)
pascal.487 paki, -> #483, dekiper
­> Možda i jeste, ko zna. Bilo bi logično da ako je sqrt(9)=3, da je onda ­> sqrt(-9)=sqrt(9)*sqrt(-1). Pošto se sqrt(-1) popularno zove i imagina- ­> rna jedinica onda sve što treba da uradiš je da promeniš predznak iz - ­> u + i da posle dodaš ovo sqrt(-1). E, tu sam te čekao :) A zašto je sqrt(-9) 3*i, a ne -3*i?
pascal.488 paki, -> #479, vita
­> Ali sta ce uopste ovolika rasprava u PC.PROG.pascal????? Smeta li? :)
pascal.489 predragd, -> #248, predragd
> Zašto neke MS-DOS funkcije (IOCTL, čitanje/setovanje > serijskog broja diska) ne rade u protected modu (BP 7.0). > Dok na primer funkcija $41 - brisanje fajla, takođe u > protected modu, radi odlično. Sa druge strane sve te > funkcije u real modu (takođe BP 7.0) rade potpuno > ispravno. Prosto je neverovatno da na Sezam-u niko nije znao odgovor na ovo pitanje. No, kako bilo da bilo uspeo sam da dodjem do zadovoljavajuceg resenja. Ukoliko nekog interesuje ova problematika u prilogu sam ostavio primer pozivanja real mode interrupt-a iz DPMI-a. Programcic je skinut sa Borland download BBS-a, autor mi je nepoznat. Peđa. readwrte.arj
pascal.490 predragd, -> #356, vvelisavljev
> Primetio sam da u programima imam gomilu istih procedura > koje rade sa različitim tipovima podataka (procedure za > unos). Da li objektno programiranje omogućava da ja imam > jednu proceduru za unos koja će da obrađuje sve moje > podatke. Bio bih jako zahvalan ako bi Mogao bi da izvedes nesto kao to radi Turbo Vision 2. Svi podaci se unose kao stringovi, a moguce je definisati kakav ce biti format podataka za unos. Kasnije te podatke konvertujes u tebi potreban oblik. Pedja.
pascal.491 peca.st, -> #486, paki
!-> Nas profa uči da sqrt:R->R, a da je i*i=-1. Tja, teoriju nikad nisam voleo, možda sam i pogrešio. Priznajem da tačnu definiciju broja i ne znam. Postoje dve mogućnosti, ili je rešenje jednačine i*i=-1, ili je i=sqrt(-1). Peđa. P.S. vicevi.esnafski: Ovo je pc.prog.pascal
pascal.492 peca.st, -> #487, paki
!-> E, tu sam te čekao :) A zašto je sqrt(-9) 3*i, a ne -3*i? Paki, pazi malo! Koliko je sqrt(4)? Nemoj samo da kažeš plus/minus 2. sqrt(4) = 2, po definiciji koren vraća pozitivnu vrednost! Drugo je to što je (plus/minus 2) na kvadrat = 4. Ako imaš x na kvadrat = 4, odatle je x = +/- 2. Ali ako imaš x = sqrt(4), odatle je x = 2. Peđa.
pascal.493 paki, -> #491, peca.st
­> Priznajem da tačnu definiciju broja i ne znam. Postoje dve ­> mogućnosti, ili je rešenje jednačine i*i=-1, ili je i=sqrt(-1). Ono prvo :) Pitao sam danas profu. Inače, ovo pitanje sam postavio zbog teksta u Računarima o MatematiKi 386 u kome se kaže otprilike 'Program je stvarno profesionalan, umesto da prijavi grešku na 'sqrt(-9)', kao digitroni, on vraća 3*i.', što mi je malko prismrdelo. ­> P.S. vicevi.esnafski: Ovo je pc.prog.pascal OK, nećemo više :)
pascal.494 uobradovic,
Hvala na odgovorima ! Video sam u cemu je greska. Imam dva pitanja : -> Sta je to Turbo Vision(video sam da postoji na pascalu) ali cemu sluzi -> kako se instalira emm386 Hvala Uros :)
pascal.495 eagle, -> #494, uobradovic
> -> Sta je to Turbo Vision(video sam da postoji na pascalu) ali > cemu sluzi Turbo Vision je biblioteka za kreiranje korisničkog interfejsa. Dakle, ako radiš u TV, programi će ti spolja izgledati isto kao standardni Borlandov IDE (prozori, meniji, dijalozi, editor...) Jako korisna stvar.
pascal.496 dragisha, -> #416, .bale.
-> Hm, zaista. C je, pošto je prljav, osuđen da sa stringovima radi preko -> pointera i to se teško drugačije može implementirati (?). Pascal je Itekako može. Rješenje je ASCIIZ string + pojam dinamičkog niza. Takav sistem pri prosljeđivanju takvog niza kao parametra šalje prvo ukupnu veličinu, zatim pointer na sam niz tako da do proboja ne može doći. To slanje veličine je dio metoda i pravi (:) jezici to rade sami:). (znam da si ti ovo već čitao, ali zbog ostalih i zbog tvog upitnika ponavljam jopet:).
pascal.497 dragisha, -> #420, vitez.koja
-> To nije usporavanje, to je realno odmeravanje snaga pri istim uslovima. -> Primer sa stringovima ide možda u korist TURBO paskala, no nije teško -> naći primere gde je C 'na svome'. Bilo bi zanimljivo da nam daš neki konkretan primjer kad ti već nije teško. Ja nemam ideje:).
pascal.498 dragisha, -> #405, zolika
-> Ne mogu da odolim... :-) Uzmi TopSpeed Modulu-2, i batali Paskale, to -> je preživljeno... (zdravo kolega:) Moja prva reakcija je isto to:), a druga (ono što čovjeka zanima:) je TopSpeed Pascal. TopSpeed Pascal je ISO Pascal, što znači da je "za nijansu" kompatibilniji sa ostatkom Pascala na tržištu nego Turbo Pascal koji je budževina koja će da radi na PCju i nigdje više! Ako je nekome vrhunska ambicija PC programiranje, samo naprijed. Dalje, TS Pas kompajlira u .OBJ, veže se sa C, C++, M2, ASM, ima memorijske modele (+overlay +DLL za DOS), OOP... Zauzima par megabajta zajedno sa IDE. Ima i TP2TS.
pascal.499 dragisha, -> #439, dejanr
-> Imaš pravo, sorry. Glupi Turbo Pascal ima samo ln... a i inače je dosta ?????????????????? Postaje zabavno:). žemu da zahvalimo na ovom trenutku iskrenosti?:)
pascal.500 dejanr, -> #499, dragisha
>> > Glupi Turbo Pascal ima samo ln... a i inače je dosta >> > ?????????????????? >> >> Postaje zabavno:). žemu da zahvalimo na ovom trenutku iskrenosti?:) Ne treba nikakva posebna iskrenost da se Turbo Pascalu zameri što nema dovoljno funkcija nego mora da se piše procedura i za takvu sitnicu kao što je arccos. Svakom jeziku (ili bar svakom koji sam ja video) mogu se sa pravom uputiti mnoge zamerke, i uvek ima mesta za njegova unapređenja. Recimo, stalno unapređujući TopSpeed Modulu 2, kroz dvadesetak godina će, ako se potrude, imati proizvod koji vredi onoliko koliko danas vredi Turbo Pascal ;>
pascal.501 lucas,
Mali problem u Turbo Visiji i Turbo Pascalu 6.0, elem, neće da mi pozove komande u dijalog box-u već pozima samo komande sa menija i statusne linije. npr. komadna cmQuit mi ne radi ako pritisnem button u dialog box-u, izgleda da sam ja glup :) a radi mi kada je pozovem na meniju ili pritisnem mišem na stasus line Pozdrav LUCAS ....
pascal.502 .bale., -> #496, dragisha
> -> Hm, zaista. C je, pošto je prljav, osuđen da sa stringovima radi > preko -> pointera i to se teško drugačije može implementirati (?). > Pascal je > > Itekako može. Rješenje je ASCIIZ string + pojam dinamičkog niza. Takav > sistem pri prosljeđivanju takvog niza kao parametra šalje prvo ukupnu > veličinu, zatim pointer na sam niz tako da do proboja ne može doći. To > slanje veličine je dio metoda i pravi (:) jezici to rade sami:). > > (znam da si ti ovo već čitao, ali zbog ostalih i zbog tvog upitnika > ponavljam jopet:). Može li malo detaljnije? Ja sam hteo da kažem da nema 'leba pored cast-a iz ko-zna-čega u char* ...
pascal.503 kriss, -> #498, dragisha
˙˙ TopSpeed Pascal. TopSpeed Pascal je ISO Pascal, što znači da GDE može da se nabavi to čudo?
pascal.504 niklaus, -> #487, paki
(:> E, tu sam te čekao :) A zašto je sqrt(-9) 3*i, a ne -3*i? Zato što... ű(-9) = ű(9*(-1)) = ű9 * ű(-1) = 3 * ű(-1) = 3 * i (:niklaus:)
pascal.505 niklaus, -> #478, pedjak
(:>> Teorema: Svaki polinom sa realnim koeficijentima ima jednu (:>> kompleksnu nulu. (:> (:> Ne. Teorema glasi: Svaki kompleksan polinom P, dg P ˛1 ima bar (:> jedan koren. A kasnije ćete sa izvodima tačno znati koliko je kompleksnih, a koli- ko realnih korena... (: (:niklaus:)
pascal.506 dragisha, -> #500, dejanr
-> Ne treba nikakva posebna iskrenost da se Turbo Pascalu zameri što nema -> dovoljno funkcija nego mora da se piše procedura i za takvu sitnicu kao -> što je arccos. Svakom jeziku (ili bar svakom koji sam ja video) mogu se Profesionalac će da plati matematičku biblioteku ili će to napraviti jednom za svagda u UNIT i završiti s time. Zar ne?:) -> Recimo, stalno unapređujući TopSpeed Modulu 2, kroz dvadesetak godina -> će, ako se potrude, imati proizvod koji vredi onoliko koliko danas vredi -> Turbo Pascal ;> žuo sam nešto da osvajaju tehnologiju TPU-a, i krešu opcije za rad sa memorijskim modelima da se koliko toliko približe Turbo Pascalu:). -- [A clear conscience is merely the result of bad memory.]
pascal.507 ilazarevic,
Kako da pozovem private proceduru u objektu? Totalni sam početnik što se objekata tiče... :)
pascal.508 kriss, -> #498, dragisha
˙˙ TopSpeed Pascal. TopSpeed Pascal je ISO Pascal, što znači da GDE može da se nabavi to čudo?
pascal.509 paki, -> #504, niklaus
­> Zato što... ­> ű(-9) = ű(9*(-1)) = ű9 * ű(-1) = 3 * ű(-1) = 3 * i žek, odakle ű(-1)=i? Zašto nije -i? Ali OK, nije ni važno.
pascal.510 dejanr, -> #506, dragisha
>> Profesionalac će da plati matematičku biblioteku ili će to napraviti >> jednom za svagda u UNIT i završiti s time. Zar ne?:) 'oće, ako radi sa floating point brojevima. Meni dosta longint. >> > Recimo, stalno unapređujući TopSpeed Modulu 2, kroz dvadesetak godina >> > će, ako se potrude, imati proizvod koji vredi onoliko koliko danas vredi >> > Turbo Pascal ;> >> >> žuo sam nešto da osvajaju tehnologiju TPU-a, i krešu opcije za rad sa >> memorijskim modelima da se koliko toliko približe Turbo Pascalu:). Neka naprave da prevodi onoliko brzo koliko turbo pascal, pravi kod jednake dužine i da se taj kod jednako brzo izvršava, pa da pričamo dalje.
pascal.511 eagle, -> #507, ilazarevic
> Kako da pozovem private proceduru u objektu? Ako private metod pozivaš unutar istog unita (ili programa), možeš ga pozivati kao običan metod. Izvan svog unita privatni metodi i polja su nedostupni.
pascal.512 eagle, -> #501, lucas
> Mali problem u Turbo Visiji i Turbo Pascalu 6.0, > elem, neće da mi pozove komande u dijalog box-u već pozima samo > komande sa menija i statusne linije. > npr. komadna cmQuit mi ne radi ako pritisnem button u dialog > a radi mi kada je pozovem na meniju ili pritisnem mišem na stasus line U principu, sve komande koje napravi neki element dijaloga obrađuju se u handleevent metodu tog dijaloga. Dakle cmquit u ovom slučaju, ili bilo koja komanda nekog dugmeta ne bi trebala da stigne do application.handlevent metoda, što se očigledno i ne dešava u tvom programu. Meniji i statusna linija pozovu putevent koji ubaci komandu u event, i tu komandu getevent pokupi u sledećem krugu i prosledi handleventu koji reaguje, na primer prekidom programa ako je cmquit. Dijalozi, pretpostavljam, obrišu event na kraju.
pascal.513 .bale., -> #509, paki
> žek, odakle ű(-1)=i? Zašto nije -i? Pa to mu je definicija...
pascal.514 paki, -> #513, .bale.
­>> žek, odakle ű(-1)=i? Zašto nije -i? ­> ­> Pa to mu je definicija... Ne, definicija mu je i*i=(-1).
pascal.515 vitez.koja, -> #497, dragisha
#=> Bilo bi zanimljivo da nam daš neki konkretan primjer kad #=> ti već nije teško. Ja nemam ideje:). Pointerska aritmetika, na primer.