jezici.1dragisha,
[Reply to PC.PROG.3/jezici:145 (nbatocanin)]
-> Kako preskače? Nove naredbe se definišu preko postojećih
-> konstrukcija, pa znači da se tako zadaje i njihova semantika. Prosto
-> i jednostavno.
Postojeće konstrukcije, koje su prema tebi već napisane preko već
postojećih, a sve to na nivou mikroinstrukcija u untyped jeziku... Ako se
dobro sjećam, rekao si da je vertikalna kompatibilnost očuvana tako što je
'stari' kliper sav napisan sa #command/#translate... Odakle se vuče
semantika?
Ne štima.
-> > UBR, ne sjećam se da sam ranije vidio riječ "ograničeno".
-> > Krećemo se:). --
->
-> Nikad nisam ni izbliza tvrdio da je Clipper pretprocesor najmoćnija
-> stvar u svemiru i šire koja definiše nove programske jezike, čuva
Rekao si da je budućnost velikih sistema u nečemu poput klipera, ne u
'klasičnim' jezicima. Ako sam to preslobodno protumačio, skjuzmi.
--
[Stationary mice have bigger balls. (c)1991]
jezici.2nbatocanin,
-> #1, dragisha> untyped jeziku... Ako se dobro sjećam, rekao si da je
> vertikalna kompatibilnost očuvana tako što je 'stari'
> kliper sav napisan sa #command/#translate... Odakle se
> vuče semantika?
>
> Ne štima.
Ajde da pojednostavimo stvar: u s'87 bila je sledeća naredba:
@ x,y SAY "Pera"
to se prevodilo (semantika) u niz p-instrukcija koje su na koordinati
(x,y) ispisivale tekst "Pera". 5.x prethodnu naredbu prihvata, ali je
nema u svom kernelu: ona se pretprocesira u:
DevPos (x, y) ; DevOut ("Pera")
što se dalje prevodi u p-kod. Tako je očuvana kompatibilnost na nivou
sorsa. Što se tiče semantike, za naredbe iz s'87 je ista, a za nove
je nova :) Princip je potpuno identičan i za naredbe korisnika.
> -> Nikad nisam ni izbliza tvrdio da je Clipper
> pretprocesor najmoćnija -> stvar u svemiru i šire koja
> definiše nove programske jezike, čuva
>
> Rekao si da je budućnost velikih sistema u nečemu poput
> klipera, ne u 'klasičnim' jezicima. Ako sam to preslobodno
> protumačio, skjuzmi. --
Ne, ne, ne :) To se nije odnosilo na odnos opšti/specijalizovani
jezici: rekao sam (i mislim) da su klasični koncepti u programskim
jezicima veoma trapavi po pitanju širenja postojećih jezika. Zašto je
to (širenje) potrebno? Zato što programi postaju sve složeniji i
složeniji, koriste sve više dodatnih biblioteka i sl, a dugo je
jedini mehanizam za, uslovno rečeno, "pojednostavljenje" jezika bio
izdvajanje grupe naredbi u procedure. Taj koncept je veoma dobar, ali
i ograničen - jednostavno će u budućnosti biti potrebno još
mehanizama! OOP je jedan takav moćan mehanizam. Osim njega, biće
potrebno još mnogo manjih rešenja za razne stvari. E, pretprocesor
ugrađen u Clipper je po meni jedna od tih konstrukcija.
jezici.3jasicp,
Koja je najnovija verzija Turbo C++ ? ( Mislim na Borlanda i ne na BC++ seriju
KK
jezici.4dekiper,
-> #3, jasicpNajnoviji su:
Turbo C++ 3.0 for DOS (ne postoji 3.1 provereno (ili 4.0))
Turbo C++ 3.1 for Windows
ima još i Turbo C++ 3.1 for Windows & Protogen (takozvani Turbo Visual C++)
Pozdrav, Deki
jezici.5vmisev,
ova poruka je reply na 11.223 KOMUNIKACIJE.6:vax djelovic
---------------------------------------------------------
> 1. Praktično da nema Fortune 500 kompanije koja već nije izvršila komple-
> tan reengineering/reverse engineering postojećih sistema i time batalila
> stare Cobol programe. Takođe, vidim da sve veći i veći broj inženjerskih
> firmi prelazi sa Fortrana na C++.
Mislim da je kod nas broj firmi, a institucija pogotovo, koje rade pod
COBOL-om još uvek veoma veliki. Izgleda da nisam bio dovoljno jasan u svojim
porukama :( Naime, ja nisam tvrdio da treba učiti COBOL zato što bez njega
neće moći da se živi, već, vezano za predhodne poruke i ceo tok diskusije,
smatram da jedan programer mora da bude svestrano stručno obrazovan. A kako
COBOL smatram značajnim jezikom, koji na žalost još uvek nije samo istori-
jski značajan (mada će najverovatnije to uskoro biti), mislim da programer
još uvek mora da zna I COBOL. Eto :)
> U takvim uslovima mislim da na fakultetu treba da se uče noviji jezici ko-
> ji sadrže lokalne promenjljive, rekurziju i ostale stvari koje Cobol nema
Ma slažem se ja sa tim. Ali i dalje mislim da treba raditi I COBOL. Bar
jedan semestar. A što se tiče C++, ti si djelovicu gavni krivac što sam se
debelo zagrejao da naučim isti. Jeste. I što sam kupio par knjiga. I što sam
počeo da neke pojave iz, što bi sociolozi rekli "objektivne stvarnosti" :)
gledam kroz analogije sa C++ (npr, u nekom odnosu nekih entiteta prepoznam
preklapanje :)).
> 2. Zašto se, zaboga, Fortran uči pre Bejzika?
Ovo pitanje mi je ustvari otvorilo oči! Pošto su baze ono što mene za-
nima, ja zapeo COBOL pa COBOL. Da je neko rek'o da se ukine Fortran, ne bih
ni prstom mak'o ;) E, što ti je čovek prokletinja, čudo jedno :)
Vladimir
jezici.6zcvele,
ş> nauče nešto novo. Ali da li bi pristao da celog života
ş> radiš u fortranu? :>
To stoji jednim delom. Ali fortran je još koliko se god kunete u C nezamenjiv
za neke matematske stvari. Drugo i sam fortran se kao jezik modernizovao i imaš
i dalje jako puno inženjera naročito građevinaca i mašinaca koji pišu software
u Fortranu. Za Cobol ne znam, a da li ima smislasada zbog jedne male izmene
promeniti softvare i preformatirati sve baze da bi se čisto prešlo na softeware
u C-u. Informacije radi C ne znam i imam želju i volju da ga naučim, i većinu
softvera koji sam pisao napisan je u PASCALU.
ş> Znaš, kad pogledam, prave stvari se uče tek od 3. godine
ş> (što se tiče programiranja, IS i ostalo). So, čemu ove
ş> prve dve godine? Ah,
Okreni se malo oko sebe i pogledaj koliko tvojih kolega sa godine zna o
programiranju kao ti. Tako sam i ja razmišljao na prve dve godine
faxa,(automatičar sam a ne programer) zašto me muče tolikom matematikom i
sličnim stvarima. Veruj mi neće ti trebati 100% znanja koje si naučio ali će ti
sigurno trebati 40%. A ako već sve znaš šta se uči na prve dve godine daj lepo
2 godine za jednu i rešio si problem.
Pozdrav Cvele
jezici.7zcvele,
ş> Nisam aludirao na pamet već na cicijašluk. Ako nisi
ş> primetio, ljudi koji su došli "odande" uglavnom misle
ş> samo na sebe i ne žele da se angažuju išta više nego što
ş> je potrebno da oni sami napreduju.
Stvarno bi voleo da mi ovo malo detaljnije objasniš. Samo pokušaj da gledaš iz
ugla tih ljudi koji su "odande" (odande= mars, pluton, venera, bosna,..) došli.
jezici.8dcolak,
│ 2. Zašto se, zaboga, Fortran uči pre Bejzika?
Možda zbog toga što je pascal lakši od C-a, zato što je Fortran
bolji od Basica itd itd... Nema logike, nikad je nije ni bilo..
Sledge DAMMIR!
jezici.9dcolak,
│ Hajde, nemoj biti bukvalista, znaš na šta sam mislio.
│> Lepo, znači naučio si C++ na spektrumu? Ne, ipak je to bio Unix?
│> Ne? Pascal? Da, sa sve objektima, a na lepom malom spektrumu, ili
│> 4.77 xt-u.. ? Pfffft...
│ ──────────
│ Hajde, nemoj biti bukvalista, znaš na šta sam mislio.
Primeti podvučeno, to je veza sa realnošću. Tvrdiš da se UNIX, ili
C++ daju naučiti na 4.77 xt-u? ...I don't think so..
Sledge DAMMIR!
jezici.10dcolak,
│ Opet vrdaš :) Niko nije govorio o problemu iz ugla korisnika, već pro-
│ gramera i projektanta. A, osim toga iz gore navedenog bi se dalo
Ne vrdam. Propuštaš glavnu stvar, krajnjeg korisnika. Sve je
posvećeno njemu, no mnogi PRO momci zaboravljaju takve stvari.
Analogija sa animacijom postoji, grubo i jeftino ili fino i skupo?
│ zaključiti Da, sad se setih. Pa i pod Oracle (radi i pod MS DOS) imaš SQL
│ Forms i SQL Menu.
Da, setio si se ;) E vidiš, mnogi se nisu setili... Tuga... No, ni
FORMS nije lepota..
Sledge DAMMIR!
jezici.11dcolak,
│ u Fortranu. Za Cobol ne znam, a da li ima smislasada zbog jedne male izmene
│ promeniti softvare i preformatirati sve baze da bi se čisto prešlo na
│ softeware u C-u. Informacije radi C ne znam i imam želju i volju da ga
│ naučim, i većinu softvera koji sam pisao napisan je u PASCALU.
Da li ima svrhe _zbog male izmene_ prelaziti na C? Ako će postojati
izmena+1 onda definitivno vredi, no, to je svakome jasno. BTW, zašto
nisi uzeo C pod svoje? ;) Nije težak, kako ga mnogi znalci prikazuju.
│ sličnim stvarima. Veruj mi neće ti trebati 100% znanja koje si naučio ali
│ će ti sigurno trebati 40%. A ako već sve znaš šta se uči na prve dve godine
│ daj lepo 2 godine za jednu i rešio si problem.
Ajooj, pa naravno čoveče, naravno, na kraju poglavlja sam pomenuo da
to ipak nije za ovu temu, možda za temu školstvo ne VAX...
Sledge DAMMIR!
jezici.12dcolak,
│ Obavezno da, ali u kojoj meri ćeš primenjivati to svoje znanje
│ zavisi samo od tebe.
Hoćeš da kažeš, obavezno je učiti Cobol na faxu (normalno) ali
nije bitno primeniti to znanje (glavna boljka u školskom sistemu)?
Kao što sam rekao, već zadiremo u pitanja školstva, ako želite da
nastavimo, birajte drugu conf, ne ovu..
Sledge DAMMIR!
jezici.13spantic,
> Zašto _korisnik_ da uči upitni jezik? Bolje da se bavi drugim stvarima
Ama odakle vadiš svoje ideje? Konkretno, odakle ti ideja da korisnik
traba da zna da zada upit u SQLu?
jezici.14spantic,
> Ja sam fortran naučio u gimnaziji. I odavno sam shvatio neke druge
Da li znaš koji je jezik ARPA prihvatila kao jezik za paralelne procesore?
jezici.15maksa,
-> #6, zcvele>> i imaš i dalje jako puno inženjera naročito građevinaca i
>> mašinaca koji pišu software u Fortranu.
Sa' će neko da skoči, al' to je, čini se, ipak vrsta koja
odumire. ;) Svi, čak i inžinjeri, se lagano šaltaju na objektni
pristup, i tako treba da bude. ;)) Reference ? Na pr. poruke
sa usenet-a koje je djelovic slao u NOVOSTI su imale pitanja
u stilu: "radim konačne elemente, i imam klasu koja ..." i
sl. Ako je C++ uspeo da se nametne i u ovoj (numerički vrlo
zahtevnoj) disciplini (MKE), onda verovatno može da se kaže
da fortranu (najzad ;) gledamo leđa.
jezici.16dcolak,
-> #13, spantic│ Ama odakle vadiš svoje ideje? Konkretno, odakle ti ideja da korisnik
│ traba da zna da zada upit u SQLu?
Odakle vadim ideje? Iz svakodnevnice koja nas okružuje. Već sam
ranije dao pointere na nemale firme gde je takva situacija.
BTW, nije moja ideja da korisnik treba da zna SQL već PRO momaka.
Sledge DAMMIR!
jezici.17dcolak,
-> #14, spantic│ Da li znaš koji je jezik ARPA prihvatila kao jezik za paralelne procesore?
Da li znaš koji je jezik odabran za službeni u VJ?
Sledge DAMMIR!
jezici.18vmisev,
-> #10, dcolak > Ne vrdam. Propuštaš glavnu stvar, krajnjeg korisnika.
Vrdaš, vrdaš :) Kako propuštam korisnika kad sam u onom većem delu ko-
ji nisi citirao pričao o tome kako se može udovoljiti korisniku da mu se
život olakša do gluposti. I normalno da je korisnik uvek na 1. mestu.
>> Da, sad se setih. Pa i pod Oracle (radi i pod MS DOS) imaš SQL Forms i
>> SQL Menu.
> Da, setio si se ;) E vidiš, mnogi se nisu setili... Tuga... No, ni FORMS
> nije lepota..
Uf, bre... 'Ajd opet. Pre ovoga pričam o QMF i AS, na kraju se setim
da se laka komunikacija sa korisnikom može uraditi i na brzaka iz, da tako
kažem, matičnog okruženja za SQL, a ti tek to navodiš kao deo posvećen kori-
snicima...
Vladimir
jezici.19dragisha,
-> #14, spantic-> > Ja sam fortran naucio u gimnaziji. I odavno sam shvatio neke druge
->
-> Da li znas koji je jezik ARPA prihvatila kao jezik za paralelne
-> procesore?
I to zbog toga što je bio najprikladniji za vektorizacije i šta ti ja
znam.
Jedna novost u ovoj oblasti je Modula-2*. Gledaću da pošaljem announce.
--
[Unless you can see black then white has no meaning]
jezici.20dragisha,
-> #7, zcvele-> ş> Nisam aludirao na pamet vec na cicijasluk. Ako nisi
-> ş> primetio, ljudi koji su dosli "odande" uglavnom misle
-> ş> samo na sebe i ne zele da se angazuju ista vise nego sto
-> ş> je potrebno da oni sami napreduju.
->
-> Stvarno bi voleo da mi ovo malo detaljnije objasnis. Samo pokusaj da
-> gledas iz ugla tih ljudi koji su "odande" (odande= mars, pluton, venera,
-> bosna,..) dosli.
Ti stvarno očekuješ objašnjenje?:) Dobro, evo i ja ću da se pridružim:).
Možda i prepričam koju dogodovštinu iz vremena mog boravka tamo.
--
[Smile. It's the second best thing done with YOUR lips.]
jezici.21goxx,
-> #8, dcolak■ 2. Zašto se, zaboga, Fortran uči pre Bejzika?
■ Možda zbog toga što je pascal lakši od C-a, zato što je Fortran
■ bolji od Basica itd itd... Nema logike, nikad je nije ni bilo..
Kada sam ja počeo da učim programiranje, u trećem razredu gimnazije
prvi jezik je bio fortran, a zatim u četvrtoj godini cobol i basic
istovremeno (i mašinac za NAR :). Redosled fortran-basic su nam
objašnjavali time što je fortran teži od basic-a i ko nauči fortran
lako nauči basic. To je, bar što se mene tiče, apsolutno tačno. U
stvari, basic nisam ni učio, već sam ga jednostavno "znao". Mislim
da taj redosled nije tako loš. Jedino mi je žao što u srednjoj
školi nismo radili pascal (koliko se sećam to se samo radilo u
matematičkoj gimnaziji po nekom specijalnom programu).
Goran
jezici.22spantic,
-> #15, maksa> Sa' će neko da skoči, al' to je, čini se, ipak vrsta koja
> odumire. ;) Svi, čak i inžinjeri, se lagano šaltaju na objektni
Ja se u to ne bih kladio ;) Naime, jedan moj prijatelj, g. Dejan Mirčevski
je trenutno na doktorskim studijama u Hjustonu, Teksas i radi u ekipi koja
formira prevodilac za paralelne procesorske sisteme. Šta misliš koji je jezik
zapravo u pitanju?
Rade na razvoju FORTRANA 77D i FORTRAN 90D, naravno zasnovanim na F77 i F90
standardima.
Na osnovu njih je ARPA definisala standardni jezik za paralelne procesore,
HIGH STANDARD FORTRAN ;)
Bojim se da FORTRAN neće izumreti :))
> da fortranu (najzad ;) gledamo leđa.
Da li bi štogod bacio u to ime? :)
jezici.23spantic,
-> #16, dcolak> BTW, nije moja ideja da korisnik treba da zna SQL već PRO momaka.
Navedi mi jednog, ali samo jednog profesionalnog programera koji
ima takve ideje.
jezici.24spantic,
-> #17, dcolak>│ Da li znaš koji je jezik ARPA prihvatila kao jezik za paralelne procesore?
>
> Da li znaš koji je jezik odabran za službeni u VJ?
Ako misliš na programski jezik voleo bih da znam. Projekti za vojsku
su bili rađeni u svemu i svačemu. Dosta FORTRAN-a na primer ;)
jezici.25spantic,
-> #19, dragisha> I to zbog toga što je bio najprikladniji za vektorizacije i šta ti ja
> znam.
Da, ali sadašnji koncept je još interesantniji.
Usput, da li je izašao GNUFortran?
jezici.26.bale.,
-> #15, maksa> sl. Ako je C++ uspeo da se nametne i u ovoj (numerički vrlo
> zahtevnoj) disciplini (MKE), onda verovatno može da se kaže
> da fortranu (najzad ;) gledamo leđa.
Polako, polako... Cool.
jezici.27.bale.,
-> #17, dcolak> Da li znaš koji je jezik odabran za službeni u VJ?
Fortran D? :-)
jezici.28dcolak,
-> #21, goxx│ da taj redosled nije tako loš. Jedino mi je žao što u srednjoj
│ školi nismo radili pascal (koliko se sećam to se samo radilo u
│ matematičkoj gimnaziji po nekom specijalnom programu).
Radilo se i u IX gimnaziji.
Sledge DAMMIR!
jezici.29maksa,
-> #22, spantic>>> da fortranu (najzad ;) gledamo leđa.
>>
>> Da li bi štogod bacio u to ime? :)
Da, sve ove knjige koje imam o istom. U vatru. ;)
jezici.30dr.grba,
-> #21, goxx>> Kada sam ja počeo da učim programiranje, u trećem razredu gimnazije
>> prvi jezik je bio fortran, a zatim u četvrtoj godini cobol i basic
>> istovremeno (i mašinac za NAR :). Redosled fortran-basic su nam
>> objašnjavali time što je fortran teži od basic-a i ko nauči fortran
>> lako nauči basic. To je, bar što se mene tiče, apsolutno tačno. U
Sećam se priče o jednom eksperimentalnom odeljenju matematičara u Kikindi,
pre petnaestak godina. Učili su: Fortran, BASIC, COBOL, PL/1, Prolog.
Ni dana nisu proveli baveći se projektovanjem algoritamskih struktura.
Iz tog odeljenja danas ima dva-tri programera, svi rade isključivo na COBOL
aplikacijama. Verovatno bi bili bespomoćni kada bi im se zabranio GO TO.
jezici.31postmast,
From: jovicic@fon (Aleksandar Jovicic)
Subject: Re: vax
Date: Fri, 3 Jun 1994 11:58:00 GMT
Damir Colak (dcolak@sezam.UUCP) wrote:
: Zelis da se bavis C-om pod Unix-om, a profan te tera da pises debilne
: programe u pascalu! Ma sve je to dubre...
Pa imaces ti prilike da pises i C pod UNIX-om u III godini (kad dodjes dotle),
a sto se Pascala tice on i nije tako los (citaj: nije los za pocetnike, jer
ljudi zbog prestroge sintakse ne uspevaju da se toliko upetljaju koliko to mogu
u C-u, znaci dobar je za ucenje PRINCIPA programiranja).
A ako nisi primetio, ti i ja i nismo na informatickom fakultetu :)
(bar kako kazu neke kolege iz AISEC-a), jer primecujes koliko imas informatickih
predmeta na prvoj (bez komentara o profesorima), a stanje nije puno bolje
ni na II i III godini. Cini mi se da i na ostalim fakultetima koji se bave
informatikom stanje nije puno bolje nego kod nas (na ETF-u ih ugusise
elektronikom, PMF-u matematikom), tako da bi resenje bilo
osnivanje novog fakulteta ali... (nastavak nije ni potreban)
Sto se naseg faksa tice postoji predlog (sa kojim se slazem) da se smer bira
od prve godine (jos kad bi se to izglasalo...) ali tebe i mene to ne kaci.
--
A. Jovicic - FON
************************************
* jovicic@fon.fon.uni-bg.yu *
* sys2!jovicic@fon.fon.uni-bg.yu *
* f1jovici@yuearn11.bitnet *
* ejovicic@ubbg.etf.uni-bg.yu *
************************************
P.S. Pa pisi ti C na UNIX-u, to niko nece da ti brani (ionako je do pre neki dan
terminal-sala zvrjala prazna)
jezici.32postmast,
From: jovicic@fon (Aleksandar Jovicic)
Subject: Re: vax
Date: Fri, 3 Jun 1994 19:45:43 GMT
Damir Colak (dcolak@sezam.UUCP) wrote:
: Naravno ;) Ali ako tip ima jednu radnju i zeli da vodi poslovanje
: kompjuterom, zasto praviti IS ? :)) Da ne pominjem Video Klubove i
: ostalo..
Pa da, sad ti i informacioni sistemi smetaju (trebalo bi ih uvesti na prvoj
godini da se ne mucis sa Pascalom, pa bi mozda shvatio o cemu covek prica).
Doduse najlakse je maznuti pare ljudima koji veze sa racunarima nemaju
(uglavnom mali privatnici, cast izuzecima), a to sto bi taj softver jednog
dana trebao da omogucava globalni IS nema veze (ko zna da li ce taj dan ikada
doci u ove nase krajeve).
--
A. Jovicic - FON
************************************
* jovicic@fon.fon.uni-bg.yu *
* sys2!jovicic@fon.fon.uni-bg.yu *
* f1jovici@yuearn11.bitnet *
* ejovicic@ubbg.etf.uni-bg.yu *
************************************
jezici.33postmast,
From: smilic@breza (Sasa Milic)
Subject: Re: vax
Date: Sat, 4 Jun 1994 13:16:33 GMT
Damir Colak (dcolak@sezam.UUCP) je napisa-la/o:
: BTW, koristite li clipper ili oracle? Zasto ne clipper? Zasto ne
: ACCES? ;)
Na ( u ) Brezi ISKLJUCIVO Oracle. Zasad 6.0, na SCO Unix-u. clipper
ne koristimo jer je suvise niskog nivoa ( ne mislim da je los, vec se
programira na niskom nivou ). SQL*Forms ti mnoge stvari sam uradi, sam ti
izgenerise kostur aplikacije. Veliki deo toga sto u clipper-u moras da
isprogramiras kod Forms-a odavno radi po default-u.
A sto ne volis SQL ? Pa to ti je osnov za Client/Server arhitekturu.
Sve velike baze ga podrzavaju. Plus sto uopste nije tezak, samo je
drugacija logika resavanja problema.
Access ne koristimo jer nam treba visekorisnicki rad, a da bi to
izveli sa Access-om morali bi da ga koristimo kao klijenta pa preko mreze
da ga vezujemo na Oracle ili neki drugi server. A da bi Access radio treba
ti bar 386 sa 4 Mb ( mislim RADIO, a ne puzio ), plus da korisnike naucis
da rade i sa Windows-om i sa Access-om ( znas li kakav je problem da
knjigovodju naucis da radi sa najobicnijim programom koji radi na
terminalu ? ). Pored toga, ako neka firma vec ima gomilu slabijih racunara
ne mozes traziti od njih da ih bace i nabave jace ( sta kad izadje nova
verzija access-a i windows-a ? Opet da kupuju nove racunare ? ). Najlakse
i najjeftinije je iskoristiti ih kao terminale, a nabaviti jacu masinu koja
ce raditi pod Unix-om ili nekim drugim multiuser OS-om. Kad izadje nova
verzija DBMS-a pojacas samo jednu masinu.
Sasa
jezici.34postmast,
From: smilic@breza (Sasa Milic)
Subject: Re: vax
Date: Sat, 4 Jun 1994 13:19:45 GMT
: > LOGO-u, ali ako je on BRZ, LAKO SE KORISTI i EFIKASAN, nema razloga
: > da se muci sa SQL-om. Shvatas?
SQL nije mucenje. Ako imas neki problem ili ti nije nesto jasno
posalji u mail pa cemo da vidimo.
Sasa
jezici.35postmast,
From: smilic@breza (Sasa Milic)
Subject: Re: vax
Date: Sat, 4 Jun 1994 13:32:29 GMT
Jovan Bulajic (bulaja@sezam.UUCP) je napisa-la/o:
: iole korisnu aplikaciju, ali zato mogu mesecima da teoretisu o tome
: da je taj njihov Super-De-Luxe-SQL-DJ-xBase alat najbolji na svetu i
: da je smesno uopste razgovarati o bilo cemu drugom.
Oracle uopste nije najbolji na svetu ( Najbolji je C++ ). Ali
ako imas prilike pogledaj u nekim stranim novinama za sta su najcesce
trazeni programeri. Za C++ i Oracle.
: So what? NoRMaLno je da izaberu onaj alat koji im vise odgovara i sa
: kojim ce lakse da pisu one aplikacije koje su im potrebni. Argument
Nikad nismo nikome govorili koji alat je bolji. Ali covece sta ti
programiras u clipper-u ? Rad sa maskom ? Pa to SQL*Forms sam radi, ti
samo treba da mu modifikujes to ponasanje ako imas razloga. Sumnjam da
ce neko da me ubedi da se u clipper-u lakse pisu aplikacije neko u
Forms-u.
: "znate ovo je pisano u ORACLE-u a ne tamo nekom Clipper-u" je obicno
: glavni i jedini argument "programerima" koji nisu u stanju da napisu
^^^^^^^^^^^^^^
E, nemoj da se vredjamo !
Sasa
jezici.36postmast,
From: tiho@fon (Tihomir Pelic)
Subject: Re: vax
Date: Sat, 4 Jun 1994 16:26:11 GMT
Damir Colak (dcolak@sezam.UUCP) wrote:
: Ima li neko od vas ko je u laboratorijama od prve godine? Ne? Zasto?
Posto su ti na ostala pitanja ljudi vec odgovorili (detaljno :),
da ti odgovorim i na ovo... Kada sam dosao da radim na Artist-u (CASE alat,
razvija se u Lab. za Informacione Sisteme fon-a, to ti je sala 04B), nisam
znao ni sta je SSA, ni sta je context-diagram, ni sta je entity-relationship
diagram... Sve se to radi u cetvrtoj godini (BTW, pre koliko godina si ti ovo
naucio :))... Bilo bi mi mnogo lakse da sam u cetvrtoj poceo da radim, a ne
da u trecoj to ucim sam... To ti je samo primer... Drugo, kad radis u lab.,
sasvim je normalno da ti profesor kaze "Ja to ne znam da radim, pozabavi se
time pa mi ispricaj ukratko..." Sa tvojim stavom, da se tebi neki profesor
obrati sa slicnim zahtevom, o tome bi odmah znao ceo Beograd (srecom se
konferencije razmenjuju samo lokalno ...) Stos je u tome da u informatici
NIKAD NIKO ne moze da kaze da zna SVE! Nego, ne vredi da tebi o tome pricam,
ti si pre tri godine RASTURIO Unix...
--
Tihomir Pelic Preferred e-mail: in YU: tiho@fon.fon.uni-bg.yu
~~~~~~~~~~~~ foreign: tiho%fon.uucp@moumee.calstatela.edu
[Alternate e-mail: vi: 6 lines deleted ... ]
#! rnews 838
jezici.37mjevta,
-> #33, postmast>> Na ( u ) Brezi ISKLJUCIVO Oracle. Zasad 6.0, na SCO Unix-u.
Interesuju me iskustva:
- minimalan hardver za udoban razvoj aplikacija,
- maksimalan broj terminala koji moze da se prikaci, a
da odziv sistema bude dovoljno brz,
- zahtevi za prostorom na disku
- povezivanje sa C-om (koji kompajler, ima li problema)
Pozdrav,
bjevta
jezici.38goxx,
-> #22, spantic■ Ja se u to ne bih kladio ;) Naime, jedan moj prijatelj, g. Dejan Mirčevski
■ je trenutno na doktorskim studijama u Hjustonu, Teksas i radi u ekipi koja
Drago mi je što je Dejan dogurao tako daleko. Poznajem ga od malih nogu
(iz srednje škole :). Šta još radi u Americi? Pozdravi ga ako si u
kontaktu sa njim.
Goran
jezici.39nbatocanin,
-> #15, maksa> Sa' će neko da skoči, al' to je, čini se, ipak vrsta koja
> odumire. ;) Svi, čak i inžinjeri, se lagano šaltaju na
> objektni pristup, i tako treba da bude. ;)) Reference ? Na
> pr. poruke sa usenet-a koje je djelovic slao u NOVOSTI su
> imale pitanja u stilu: "radim konačne elemente, i imam
> klasu koja ..." i sl. Ako je C++ uspeo da se nametne i u
> ovoj (numerički vrlo zahtevnoj) disciplini (MKE), onda
> verovatno može da se kaže da fortranu (najzad ;) gledamo
> leđa.
Na FORTRAN-u je napisano toliko softvera da mu to osigurava sasvim
pristojnu budućnost. Nove verzije ga sasvim pristojno opremaju za
numeričke obrade, pa izbor nekog drugog jezika nije neophodan. Ako i
postoji migracija (a nisam sasvim siguran u to), mislim da je C++ loš
kandidat za numeričke probleme. Naravno, i na njemu se to može
raditi, ali paskaloidni jezici su daleko čitljiviji i pogodniji za
ljude koji se ne bave profesionalno računarima. Što se tiče
prisutnosti C-a u radovima na tehničkim fakultetima, mislim da je to
dobrim delom (mada ne isključivo!) rezultat svojevrsne "mode":
programi koje sam video iz tih oblasti a napisani su na C-u
mogu se podjednako efikasno pisati i na Basic-u. Znate ono:
x = ... ;
y = ... ;
z = ... ;
jezici.40spantic,
-> #29, maksa> Da, sve ove knjige koje imam o istom. U vatru. ;)
Nemoj, daj ih meni :)
jezici.41zormi,
-> #37, mjevta*>> Na ( u ) Brezi ISKLJUCIVO Oracle. Zasad 6.0, na SCO Unix-u.
*
* Interesuju me iskustva:
* - minimalan hardver za udoban razvoj aplikacija,
* ...
...a mene interesuje: kolika je cena registracije Oracle-a po radnom mestu
kada se gotova aplikacija instalira kupcu?
jezici.42djelovic,
-> #39, nbatocanin> Na FORTRAN-u je napisano toliko softvera da mu to osigurava sasvim
> pristojnu budućnost.
Nisam siguran. Jezik koji se oslanja samo na veliku bazu starog
softvera teško da će biti prihvaćen u novim poduzećima, što mu, s vremenom,
smanjuje udeo ispod kritične vrednosti i onda on propada. Takođe,
"kompatibilnost" sa starim kodom je pod velikim znakom pitanja, jer:
1. Stari kod neophodno izumire kako se uslovi pod kojima se izvršavao
menjaju. Mislim da je Bojt skoro ovde rekao da je većina starih potprograma
napravljena za sisteme sa malom memorijom (64K) i velikim diskom, pa su na
današnjim sistemima nepotrebno spori jer stalno muljaju po disku.
2. Sa dolaskom Windowsa i ostalih "modernih" operativnih sistema
koje nude DLL-ove, pisanje programa pomoću više različitih alatki (Visual
Basic za korisnički interfejs, a potprogrami za izračunavanje pomoću
Fortrana?) postaje realnost. Onda nema razloga zašto da se stari Fortran
potprogrami ne zadrže, a novi da se pišu u nekom modernom jeziku.
> Nove verzije ga sasvim pristojno opremaju za numeričke obrade, pa izbor
> nekog drugog jezika nije neophodan. Ako i postoji migracija (a nisam sasvim
> siguran u to), mislim da je C++ loš kandidat za numeričke probleme.
Pitanje jezika budućnosti za numeričke obrade se po meni svodi na
pitanje koliko će brzo neki "čitljivi" jezik da dobije objekte i
preklapanje operatora. Ukoliko 90% vremena trošiš na računanje, onda ti je
mogućnost da matrice sabereš jednostavnim A = B + C izuzetno bitna.
BTW, pre par meseci sam za jednu firmu napravio biblioteku klasa za
numeričke proračune - matrice, vektori, tačke, prave i ravni, kao i
operatori i funkcije nad njima (A || B - da li je A paralelno sa B). Uz to
sam im održao kurs elementarnog C++-a, dakle samo osnovne konstrukcije bez
pravljenja klasa, i ljudi su više nego zadovoljni. Kažu da pišu programe
mnogo lakše nego ranije na Bejziku, a baška to što su programi i brži.
No da se vratim na temu, ukoliko neki "čitljivi" jezik uskoro ne dobije
objekte i preklapanje operatora, nove generacije inženjera će polako preći
na C++. Taj prelaz se, doduše, neće desiti već sutra - Fortran će biti s
nama bar još deset godina.
jezici.43mjevta,
-> #42, djelovic>> 1. Stari kod neophodno izumire kako se uslovi pod kojima se
>> izvršavao menjaju. Mislim da je Bojt skoro ovde rekao da je
>> većina starih potprograma napravljena za sisteme sa malom
>> memorijom (64K) i velikim diskom, pa su na današnjim sistemima
>> nepotrebno spori jer stalno muljaju po disku.
Vecina starih potprograma pisana je na velikim sistemima
i za njih, a tamo ne vaze bas ista pravila igre kao na
personalcima. BTW, da li postoji i koliko kosta C++ kompajler
za IBM 3090, a takodje koliko kosta izrada (prepravka i
testiranje) svih tih potprograma na C++ (vremena, ljudi,
para...)? (pitanje shvatiti kao ilustraciju problema).
bjevta
jezici.45maksa,
-> #39, nbatocanin Par dana oklevam da pošaljem ovaj odgovor pošto bih da se
poštedim prideva 'napaljen do velikih razmera', al' nek' ide
život. ;))
>> Na FORTRAN-u je napisano toliko softvera da mu to osigurava
>> sasvim pristojnu budućnost.
Normalno je da se nakupilo dosta toga, ipak fortran postoji
već tačno 40 godina (da, da, toliko, a niste ni osetili ;) Da
li je to razlog da vlada još toliko ?
>> Nove verzije ga sasvim pristojno opremaju za numeričke obrade,
>> pa izbor nekog drugog jezika nije neophodan.
Zahtevi korisnika čak i tih numerički orijentisanih programa su
porasli. žak su se i inžinjeri-korisnici razmazili, i vole da imaju
i grafiku, i menije, i završen posao, a sve u to jednom udobnom i
lepo dizajniranom programu. Batch processing je definitivno out, i
niko mu se neće drage volje vratiti.
>> Što se tiče prisutnosti C-a u radovima na tehničkim fakultetima,
>> mislim da je to dobrim delom (mada ne isključivo!) rezultat
>> svojevrsne "mode": programi koje sam video iz tih oblasti a
>> napisani su na C-u mogu se podjednako efikasno pisati i na
>> Basic-u.
Ovo za modu možda i stoji, al' evo šta videh u zadnjih par
meseci:
Jedan vrlo kvalitetan program za, grubo rečeno, proračun
filtracije podzemnih tokova kroz stensku masu (i teren uopšte).
Nepristrasni kažu da je, sa stručne strane, i po obimu i kvalitetu
posla koji obavlja, pri samom vrhu u svetskim okvirima. Verujem
da bi i neko kome je ovo kao struka strano bio zasenjen na prvi
pogled. 3D grafika, senčenje i izohipse u boji ... vrlo, vrlo
lepo i kvalitetno. Povr' svega - konačni elementi, znači teška
numerika. Autori su asistenti GF-a. Oko 600 (čini mi se) Kb
Watcom C++ sorsa.
CAD Forum u Novom Sadu. Videh zbornik tamo prezentovanih
radova (courtesy of corto), i na mnogo mesta piše C++. CAD,
znači suva inžinjerska praksa.
Ovo je najsvežije: Pre otpr. dve nedelje održano je jedno
predavanje na ETF-u. Jedno od onih neobaveznih, što se drže
svakog zadnjeg utorka u mesecu. Možda je bio još neko odavde ?
Predavanje je držao čovek (zaboravih ime :( ) koji je napravio
simulator za golf. Ništa nalik već viđenim video igrama, nego
prâvi, pravcati simulator. Glupo je opisivati, trebalo je doći
i pogledati. žitava mašinerija, tj. vrlo sofisticirana elektronika.
Softverski pogon - oko 100.000 linija C++-a. Program, između
ostalog, u realnom vremenu (!) proračunava putanju, domet
i ostale elemente u zavisnosti od jačine udarca (brzina i do
200 km/h), spina, brzine vetra ... ljudskom rukom (ok, i štapom)
udarene loptice. Iza ovoga sigurno leži teška matematika.
Kuriozitet, na (čini mi se) opšte iznenađenje, prevodilac je
Borland C++ 3.1.
Ima toga još, al' već preterah. ;)
Da podsetim, ovo je odgovor na odgovor na odgovor Cveletu da i
dan-danas građevinski i mašinski inžinjeri žive i rade na fortranu.
Još samo ograda, i neću više, časna reč ;)). Daklem, ograda:
Ne osećam se ni malo kompetentnim da započnem (nastavim ?)
bespredmetnu raspravu 'koji je jezik bolji'. Ono je bila samo moja
mala, lična & beznačajna opservacija iznesena na osnovu nekih
stvari koje sam video i pročitao. A Spanta može da dobije one
knjige kad hoće. :)
jezici.46bojt,
-> #42, djelovic>> >> Na FORTRAN-u je napisano toliko softvera da mu to
>> >> osigurava sasvim pristojnu budućnost.
>> Nisam siguran. Jezik koji se oslanja samo na veliku bazu
>> starog softvera teško da će biti prihvaćen u novim
>> poduzećima, što mu, s vremenom, smanjuje udeo ispod kritične
>> vrednosti i onda on propada.
Ne bih se baš složio sa ovim, zato što su moderni fortrani opremljeni
(bilo preko raznih ekstenzija bilo preko novih standarda) manje-više
sve svime onim što imaju i ostali savremeni viši programski jezici.
>> Takođe, "kompatibilnost" sa starim kodom je pod velikim
>> znakom pitanja, jer:
>> 1. Stari kod neophodno izumire kako se uslovi pod kojima se
>> izvršavao menjaju. Mislim da je Bojt skoro ovde rekao da je
>> većina starih potprograma napravljena za sisteme sa malom
>> memorijom (64K) i velikim diskom, pa su na današnjim sistemima
>> nepotrebno spori jer stalno muljaju po disku.
To se odnosi na period ranih 60-ih godina (btw RAM tadašnjih
main frame-ova je bio obično 8K). Medjutim, pisanje programa u
FORTRAN-u nije prestalo ranih 60-ih, već je, masovnijom pojavom
računara (sa sve više i više RAM-a) u godinama koje su dolazile
nastao ogroman broj veoma kompleksnih softverskih paketa.
Naravno, postoji mnogo stvari koje se jako teško ili nikako ne
mogu uraditi u FORTRAN-u a mogu, na primer, u C-u ili C++. Na
primer kompleksne operacije sa stringovima ili pravljenje
operativnih sistema. Medjutim, tu se postavlja pitanje prirode
programa koje treba napraviti. Kada se radi o numerici, FORTRAN
je, zbog svojih krutih okvira višeg programskog jezika (gde ne
postoji mogućnost za preterano mnogo filozofiranja o tome kako
sve kod može da se ponaša, pa samim tim i daleko manje
raznoraznih provera koje postoje u bibliotečkim fukcijama sa
ciljem da otkriju eventualne run-time greške) veoma pogodan za
efikasne optimizacije na mnogo višem nivou nego što je to slučaj
kod C-a (ili C++-a). Višedecenisjki razvoj algoritama za
optimizaciju u slučaju FORTRAN-a rezultira programima kojima po
pitanju brzine u oblasti "teške numerike" teško mogu da pariraju
identični programi pisani u ostalim programskim jezicima.
jezici.47bojt,
-> #45, maksa>> Zahtevi korisnika čak i tih numerički orijentisanih programa
>> su porasli. žak su se i inžinjeri-korisnici razmazili, i vole
>> da imaju i grafiku, i menije, i završen posao, a sve u to
>> jednom udobnom i lepo dizajniranom programu.
Danas nije nikakav problem imati menije i grafiku u fortranu.
>> Batch processing je definitivno out, i niko mu se neće drage
>> volje vratiti.
Dokle god računari toliko ne uznapreduju da i najmučniji mogući
proračun ne traje duže od sekunde (a i danas to može da traje
satima, danima, nedeljama...) batch processiranje će uvek biti
prihvatljivije zbog veće brzine izvršavanja. Doduše, ako
processing traje više sati, okreni obrni to se svodi na batch,
bez obzira što se za to vreme možda vrti IdleWild po ekranu...
jezici.48vmisev,
-> #43, mjevta > BTW, da li postoji i koliko kosta C++ kompajler za IBM 3090
U RCUB nema C++ kompajlera za VM/ESA (na moj duboki očaj :((( ). Kažu
da ga u dogledno vreme neće ni biti. Ono što ne znam je da li je to zbog to-
ga što ga IBM nije napravio, ili zato što smo u SRJ... E sad, za AIX bi se
možda još i dalo šta namontirati sa GNU C/C++ (oko čega smo već udarili u
blagu kuknjavu, a je se tek spremam ;) ali tu su problemi druge prirode (si-
nhroni terminali npr).
Vladimir
P.S. Da, sad se setih, u *.H se nalazi #ifdef C++ na puno mesta. A C kompa-
jler je relativno svež, pa mi izgleda da su se ovi u plavim odelima
spremali da naprave i C++ ???
jezici.49asterix,
-> #47, bojt>>> su porasli. žak su se i inžinjeri-korisnici razmazili, i vole
>>> da imaju i grafiku, i menije, i završen posao, a sve u to
>>> jednom udobnom i lepo dizajniranom programu.
>
> Danas nije nikakav problem imati menije i grafiku u fortranu.
Hmm... Dinamička alokacija memorije, rekurzija ..?
jezici.50bojt,
-> #49, asterix>> Hmm... Dinamička alokacija memorije, rekurzija ..?
Dinamička alokacija nije problem.
jezici.51asterix,
-> #50, bojt>>> Hmm... Dinamička alokacija memorije, rekurzija ..?
>
> Dinamička alokacija nije problem.
Hoćeš da kažeš da nove generacije FORTRANA podržavaju manipulacije
tipa new/dispose, memalloc/free ili new/delete ? Podržavaju i pointere ?
Jedini način (koji ja znam :) da ostvariš rekurziju na FORTRAN-u je da
napraviš dva identična potprograma koji će se isto i zvati i koji će tako
naizmenično pozivati jedan drugoga - dakle simulacija koja u velikoj meri
zavisi od toga da li će kompajler da 'proguta foru' ili ne...
jezici.52djelovic,
-> #51, asterix> Jedini način (koji ja znam :) da ostvariš rekurziju na FORTRAN-u je da
> napraviš dva identična potprograma koji će se isto i zvati i koji će tako
> naizmenično pozivati jedan drugoga - dakle simulacija koja u velikoj meri
> zavisi od toga da li će kompajler da 'proguta foru' ili ne...
Teško. Ukoliko se ne varam, Fortran lokalne promenjljive ne drži na steku
već zajedno sa ostalim statičkim podacima :(. BTW, to što nema rekurzije je i
po meni jedan od velikih problema Fortrana. Jes' da se rekurzija može
manje-više u većini slučajeva izbeći, ali to često ume da zakomplikuje kod do
besvesti :(.
jezici.53asterix,
-> #52, djelovic> Teško. Ukoliko se ne varam, Fortran lokalne promenjljive ne drži na steku
> već zajedno sa ostalim statičkim podacima :(. BTW, to što nema rekurzije je
Pa dobro, ali zar bi to ometalo simulaciju rekurzije ?
jezici.55bojt,
-> #51, asterix>> Hoćeš da kažeš da nove generacije FORTRANA podržavaju
>> manipulacije tipa new/dispose, memalloc/free ili new/delete ?
>> Podržavaju i pointere ?
U principu da. Postoje razne varijante od kompajlera do
kompajlera. Preferiram one koji imaju mogućnost direktnog
pozivanja C run time funkcija, tako da je, na primer,
moguće usred koda staviti adress=malloc(size) pa onda to preneti
u potprogram sa, na primer call subr(val%(adress),size/4), pa to
primiti kao subroutine subr(a,n) dimension a(n), pa po
obavljenom poslu free(val%(adress)) itd.
jezici.56djelovic,
-> #53, asterix> Pa dobro, ali zar bi to ometalo simulaciju rekurzije ?
Well, uvek se može napisati nerekurzivan kod ekvivalentan onom koji koristi
rekurziju, pitanje je samo uz kolike muke? Ukoliko funkcije nemaju prave
lokalne promenljive već samo statičke lokalne, onda koja je korist od
rekurzivnih poziva? Na taj način svakim pozivom same sebe funkcija praktično
kvari svoje promenljive.
jezici.57nbatocanin,
-> #45, maksa> Par dana oklevam da pošaljem ovaj odgovor pošto bih da se
> poštedim prideva 'napaljen do velikih razmera', al' nek'
> ide život. ;))
Nije valjda da sam tako nezgodan sagovornik? Što se tiče prethodnog
izraza, sad vidim da nisam pronašao baš lep izraz, mada nisam hteo da
kažem nešto ružno. Dakle:
OGNJENE IZVINI!
> Normalno je da se nakupilo dosta toga, ipak fortran
> postoji već tačno 40 godina (da, da, toliko, a niste ni
> osetili ;) Da li je to razlog da vlada još toliko ?
Isto kao kod DOS-a: šta je razlog njegove vladavine, osim programa?
Kvalitet sigurno ne ;)
> Jedan vrlo kvalitetan program za, grubo rečeno, proračun
> filtracije podzemnih tokova kroz stensku masu (i teren
> uopšte).
Naravno, uvek je bilo i biće ovakvih programa, ali to su ozbiljni
projekti i njih ima razmerno malo: razmisli ko ih piše: sveka 1-2%
ukupne mase završenih mašinaca, građevinaca i sl. A otprilike 60% će
imati potrebu da napiše neki programčić da im pripomogne u radu. Onda
će izbor biti ili ono što su radili na fakultetu (FORTRAN) ili ono
što koristi većina kolega (opet FORTRAN). Imam prilično dodira sa
naučnim neračunarskim kadrom i u 90% slučajeva je FORTRAN njihov
izbor, čak i u inostranstvu!
jezici.58dejanr,
-> #56, djelovic>> Well, uvek se može napisati nerekurzivan kod ekvivalentan onom koji
>> koristi rekurziju, pitanje je samo uz kolike muke? Ukoliko funkcije
>> nemaju prave lokalne promenljive već samo statičke lokalne, onda koja
>> je korist od rekurzivnih poziva?
Mislim da je FORTRAN naprosto jezik na kome se ne mogu lako i prirodno
pisati rekurzivni programi. To mu je svakako mana, mada odatle dolaze
i neke prednosti u smislu lakšeg prenošenja parametara itd.
Sa druge strane, rekurzije na papiru jako efektno zvuče, mogu se formulisati
neka rešenja koja deluju magično jednostavno, ali su u praksi često toliko
neracionalne da im se retko pribegava. Meni kod FORTRAN-a (bar onog klasičnog)
mnogo više smeta što nema slogove... bilo kakva simulacija sa COMMON je dosta
traljava.
jezici.59asterix,
-> #55, bojt> pozivanja C run time funkcija, tako da je, na primer,
> moguće usred koda staviti adress=malloc(size) pa onda to preneti
I to je onda ... FORTRAN ?
jezici.60djelovic,
-> #58, dejanr> Sa druge strane, rekurzije na papiru jako efektno zvuče, mogu se
> formulisati neka rešenja koja deluju magično jednostavno, ali su u praksi
> često toliko neracionalne da im se retko pribegava.
To zavisi od klase problema. Jednostavni i efektni primeri rekurzije sa
faktorijelima (gde li sam to samo video, hm? :)) se u praksi pokazuju kao veoma
neracionalni, ali zato svi problemi koji recimo zahtevaju nekakve stablaste
strukture mogu i te kako da imaju koristi od rekurzije.
jezici.61bojt,
-> #59, asterix>> >> pozivanja C run time funkcija
>> I to je onda ... FORTRAN ?
Jeste, to je onda FORTRAN. Biblioteke za razne jezike istog
proizvodjača se tek neznatno razlikuju. Najveći deo LIB-ova
sačinjavaju low level rutine koje su identične, dok se ostalo svodi
na interface prema višim jezicima. Mogućnost da se direktno
pozivaju iz višeg programskog jezika meni lično najviše odgovara.
Pod pretpostavkom da su funkcije u bibliotekama pisane u asembleru
(što, doduše, nije slučaj: obično se pišu u C-u) da li onda bi
moglo da se kaže "I to je onda ... *.*"?
Neke varijante novih FORTRAN kompajlera imaju ALLOCATE naredbe
ili DYNAMIC deklaracije, što je možda bliže predstavi tih
mogućnosti kao sastavnom delu programskog jezika.
Suština je u tome kakav se softver pravi. On je prilično
neprimenjljiv za pisanje operativnih sistema, editora, tekst
porcesora itd. Ako se radi o proračunima, tu je prilično efikasan.
Ako neko voli da koristi slogove, STRUCTURE deklaracije već dosta
dugo podržavaju svi noviji Fortran kompajleri. Ako neko voli da
koristi CASE, ima i to. Grafika takodje nije problem. Ako je
nekome potrebna dinamička alokacija itd, i to je moguće.
Uostalom, zašto ne bi napravili jedan test: napravi ti program
koji rešava neki teži numerički problem u C++, ja ću u fortranu,
pa da vidimo koji brže radi. ;) Recimo za računanje inverzne
matrice... ;))
jezici.62ognjen,
-> #57, nbatocanin)-> OGNJENE IZVINI!
Ok, ok... :) Desi se... :)
jezici.63asterix,
-> #61, bojt> Uostalom, zašto ne bi napravili jedan test: napravi ti program
> koji rešava neki teži numerički problem u C++, ja ću u fortranu,
> pa da vidimo koji brže radi. ;) Recimo za računanje inverzne
> matrice... ;))
:))) OK, ali vodi računa, moj program bi mogao da glasi:
A=B.invert() ;
;)
jezici.64bojt,
-> #63, asterix>> :))) OK, ali vodi računa, moj program bi mogao da glasi:
>> A=B.invert() ;
Moj već glasi CALL INVMAT(A,B,N) no da vidimo koji će biti
brži... ;) Recimo matrica reda 250x250. Ako neko hoće da se
uključi sa WATCOM ili MetaWare High C??-om, može i 1000x1000 ;)
jezici.65dpredovic,
-> #61, bojt>>> I to je onda ... FORTRAN ?
>
> Jeste, to je onda FORTRAN. Biblioteke za razne jezike istog
> proizvodjača se tek neznatno razlikuju. Najveći deo LIB-ova
> sačinjavaju low level rutine koje su identične, dok se ostalo
Low-level rutine kao što su matematičke npr? Ako MS Fortran, MS C,
MS Pascal, MS Cobol, MS ... Imaju isti matematički runtime (a imaju)
gde je onda prednost fortrana?
jezici.66niklaus,
-> #25, spantic(:> Usput, da li je izašao GNUFortran?
Koliko znam, nema ni F2C (Fortran -> C) konvertera koji je izbacio FSF
(aka Free Software Foundation, kome GNU projekat pripada), a kamoli kompajle
ra.
(: Sean :)
jezici.67bojt,
-> #65, dpredovic>> Low-level rutine kao što su matematičke npr? Ako MS Fortran,
>> MS C, MS Pascal, MS Cobol, MS ... Imaju isti matematički
>> runtime (a imaju) gde je onda prednost fortrana?
Kompajler generiše OBJ kombinujući te pozive. Fortran ugradjuje
mnogo manje čekiranja eventualnih run-time grešaka, pošto zbog
"krutosti" fortrana po definiciji postoji daleko manje situacija u
kojima se neke greške mogu dogoditi nego kod, recimo, C-a. Sa druge
strane, kao što sam već jednom napomenuo, "krutost" fortrana
ostavlja mogućnost da kompjaler, pored standardnih, vrši i
opzimizacije koda na mnogo višem nivou nego kod nižih jezika. Kad
se ima u vidu i koliko godina su razvijane te optimizacije, u
konačnom zbiru uštedi se neko vreme.
jezici.68djelovic,
-> #64, bojt> Moj već glasi CALL INVMAT(A,B,N) no da vidimo koji će biti
> brži... ;) Recimo matrica reda 250x250. Ako neko hoće da se
> uključi sa WATCOM ili MetaWare High C??-om, može i 1000x1000 ;)
Iako mislim da je takmičenje u brzini u neinteraktivnim operacijama
potpuni promašaj (?), ajde ipak da napravimo takmičenje Fortran vs. C++.
Neka bude inverzija ili nalaženje determinante matrice, ti samo opiši
algoritam po kome programi treba da rade.
jezici.69bojt,
-> #68, djelovic>> Iako mislim da je takmičenje u brzini u neinteraktivnim
>> operacijama potpuni promašaj (?)
Što?
>> ajde ipak da napravimo takmičenje Fortran vs. C++.
>> Neka bude inverzija ili nalaženje determinante matrice, ti
>> samo opiši algoritam po kome programi treba da rade.
Recimo Gauss-ovom eliminacijom. Svakako da treba obezbediti da
source-ovi budu u algoritamskom smislu identični. Problem
nalaženja determinante je unekoliko jednostavniji, pa je možda
bolje da se zadržimo na njemu. Pošto takve stvari nije zdravo
raditi u običnoj tačnosti, predlažem da se radi u dvostrukoj.
Takodje, treba da se dogovorimo oko nekoliko stvari:
- način formiranja matrice (elementi a(i,j) su neka funkcija (i,j)
ili tako nešto)
- da li da pravimo opšti program za računanje determinatne koji
bi rešavao i slučaj postojanja nule na glavnoj dijagonali (što se
postiže uvodjenjem pivotizacije, čime se takodje može i povećati
tačnost računanja), ili da polaznu matricu uvek izaberemo tako da
sigurno nema nule na gl.dijagonali.
- u slučaju kompajlera koji generišu kod koji radi u realnom
modu treba voditi računa o segmentima, tj mogu da nastanu problemi
ako je matrica veća od 64K. MS Fortran, na primer, korektno
funkcioniše u huge modelu, dok za C++ ne znam. Sa druge strane, ako
matrica bude manja od 64K, može da se desi da proračun traje toliko
kratko da se teško može pouzdano izmeriti vreme izvršavanja. U tom
slučaju neka računa istu determinatnu jedno 10 puta pa da uzmemo
prosek. Ako se odlučimo za protected mode kompajlere, nema tog
problema.
Predlažem sledeći algoritam računanja determinante (pisan u nekoj
vrsti nepostojećeg basic-a, samo da stvari budu jasne)
input n1
n=n1-1
dim double a(n,n)
for i=0 to n
for j=0 to n
a(j,i)=neka_fukcija(i,j)
next
next
t0=timer
det=1
for i=0 to n-1
det=det*a(i,i)
c=1/a(i,i) <--- ovde može da pukne ako ima 0 na dijagonali
for j=i+1 to n
b=-a(i,j)*c
for k=i+1 to n
a(k,j)=a(k,j)+b*a(k,i)
next
next
next
det=det*a(n,n)
print det,timer-t0
end
E sad, opšti program, koji bi rešavao sve slučajeve (plus
poboljšavao tačnost time što bi mu uvek tekući element na
dijagonali - a(i,i) bio najveći po apsolutnoj vrednosti) bi glasio
ovako:
input n1
n=n1-1
dim double a(n,n)
for i=0 to n
for j=0 to n
a(j,i)=neka_fukcija(i,j)
next
next
t0=timer
det=1
for i=0 to n-1
c=a(i,i)
k=-1
for j=i+1 to n
if abs(a(i,j)) > abs(c) then
c=a(i,j)
k=j
endif
next
if k <> -1 then
det=-det
for j=i to n
swap a(j,i),a(j,k)
next
endif
det=det*c
c=1/c <--- e sad ako i ovde pukne onda nema determinante
for j=i+1 to n
b=-a(i,j)*c
for k=i+1 to n
a(k,j)=a(k,j)+b*a(k,i)
next
next
next
det=det*a(n,n)
print det,timer-t0
end
jezici.70mjevta,
-> #42, djelovic>> 1. Stari kod neophodno izumire kako se uslovi pod kojima se
>> izvršavao menjaju. Mislim da je Bojt skoro ovde rekao da je
>> većina starih potprograma napravljena za sisteme sa malom
>> memorijom (64K) i velikim diskom, pa su na današnjim sistemima
>> nepotrebno spori jer stalno muljaju po disku.
Vecina starih potprograma pisana je na velikim sistemima
i za njih, a tamo ne vaze bas ista pravila igre kao na
personalcima. BTW, da li postoji i koliko kosta C++ kompajler
za IBM 3090, a takodje koliko kosta izrada (prepravka i
testiranje) svih tih potprograma na C++ (vremena, ljudi,
para...)? (pitanje shvatiti kao ilustraciju problema).
bjevta
jezici.71djelovic,
-> #70, mjevta> BTW, da li postoji i koliko kosta C++ kompajler
> za IBM 3090, a takodje koliko kosta izrada (prepravka i
> testiranje) svih tih potprograma na C++ (vremena, ljudi,
> para...)?
Za 3090 postoji kompajler (video sam ga!), ali nemam pojma koliko košta.
Što se tiče prelaska na C++, sam proces ne traje mnogo jer se radi automatski.
Međutim, za takav korak se većina firmi odluči tek kada stari Fortran programi
postanu prekomplikovani za održavanje, a onda u igru dolaze razni CASE alati
koji uz konverziju rade i prestrukturiranje, objektizovanje i sl. uz pomoć
ljudi.
P.S. Teoretski limit strukturiranog programiranja je 100,000 linija. Posle toga
programi postaju preskupi za održavanje.
jezici.72djelovic,
-> #69, bojt> >> Iako mislim da je takmičenje u brzini u neinteraktivnim
> >> operacijama potpuni promašaj (?)
>
> Što?
Zato što mislim da se pod uslovom da su oba rešenja približno isto
brza (isti red veličine) i da je program/projekat dovoljno velik,
"brzinskom" optimizacijom algoritama više gubi (na čitljivosti,
jednostavnosti i ponovnoj upotrebljivosti koda) nego što se dobija.
Konkretno, program koji ću napisati za ovo "takmičenje" nije onaj kakav
bi napisao pod normalnim okolnostima.
> Pošto takve stvari nije zdravo raditi u običnoj tačnosti, predlažem da se
> radi u dvostrukoj.
Pojam dvostruke tačnosti je malo širi :(. Koliko bajtova treba da
zauzimaju brojevi? žetri?
> - da li da pravimo opšti program za računanje determinatne koji
> bi rešavao i slučaj postojanja nule na glavnoj dijagonali (što se
> postiže uvodjenjem pivotizacije, čime se takodje može i povećati
> tačnost računanja), ili da polaznu matricu uvek izaberemo tako da
> sigurno nema nule na gl.dijagonali.
Ti odluči s obzirom na to da se više razumeš u te testove brzine više
nego ja. Sa svoje strane glasam da algoritam bude što jednostavniji kako bi
imao manje posla :).
> - u slučaju kompajlera koji generišu kod koji radi u realnom
> modu treba voditi računa o segmentima, tj mogu da nastanu problemi
> ako je matrica veća od 64K.
Tu nema nikakvih problema. Neka budu matrice proizvoljne veličine, samo
da mogu da stanu u memoriju.
P.S. Kuku nama s programima koji pucaju zbog nula na glavnoj dijagonali.
Zar u takvim slučajevima ne pomaže zamena redova ili kolona?
jezici.73bojt,
-> #72, djelovic>> Zato što mislim da se pod uslovom da su oba rešenja približno
>> isto brza (isti red veličine) i da je program/projekat
>> dovoljno velik, "brzinskom" optimizacijom algoritama više
>> gubi (na čitljivosti, jednostavnosti i ponovnoj
>> upotrebljivosti koda) nego što se dobija. Konkretno, program
>> koji ću napisati za ovo "takmičenje" nije onaj kakav bi napisao
>> pod normalnim okolnostima.
Hm, kada sam govorio o optimizaciji mislio sam na algoritme za
optimizaciju (ugradjene u kompajler) a ne optimizaciju algoritma
(tj, ako sam dobro shvatio, da programer sam optimizuje svoj
source kod). Naravno, dobitak u brzini koji se može dobiti
optimizacijom izvornog koda (od strane programera) može biti
neuporedivo veći od (eventualnog) dobitka koji se dobija
kompajlerovom optimizacijom.
>> Pojam dvostruke tačnosti je malo širi :(. Koliko bajtova
>> treba da zauzimaju brojevi? žetri?
Osam.
>> >> da li da pravimo opšti program za računanje determinatne
>> >> koji bi rešavao i slučaj postojanja nule na glavnoj
>> >> dijagonali (što se postiže uvodjenjem pivotizacije...
>> Ti odluči s obzirom na to da se više razumeš u te testove
>> brzine više nego ja. Sa svoje strane glasam da algoritam bude
>> što jednostavniji kako bi imao manje posla :).
>> P.S. Kuku nama s programima koji pucaju zbog nula na glavnoj
>> dijagonali. Zar u takvim slučajevima ne pomaže zamena
>> redova ili kolona?
Pomaže. To je ta "pivotizacija" koju sam pominjao. Tzv
horizontalna pivotizacija (zamena redova) je ugradjena u onaj
drugi (duži) predlog. Onda da pravimo opšti program, jest da ima
malo više posla, ali mislim da je tako bolje, kako bi neko posle
mogao to što uradimo i da iskoristi za nešto korisno. U tom
smislu predlažem da se deo koda koji se odnosi na računanje
determinante prebaci u poseban potprogram, a da sve ostalo
(definisanje matrice, merenje vremena, ispis itd) bude izvan
njega.
>> >> u slučaju kompajlera koji generišu kod koji radi u realnom
>> >> modu treba voditi računa o segmentima, tj mogu da nastanu
>> >> problemi ako je matrica veća od 64K.
>> Tu nema nikakvih problema. Neka budu matrice proizvoljne
>> veličine, samo da mogu da stanu u memoriju.
To se podrazumeva. Jedino se još nismo dogovorili da li ćemo
koristiti real (XT,AT) ili protected (386,486,P5 ;) ) mode
kompajlere? Kao što rekoh, kod ovih drugih moguće je raditi
stvarno velike matrice, tako da će vreme njihovog računanja biti
veće pa samim tim i lakše za izmeriti i uporediti.
jezici.74djelovic,
-> #73, bojt> Hm, kada sam govorio o optimizaciji mislio sam na algoritme za
> optimizaciju (ugradjene u kompajler) a ne optimizaciju algoritma
> (tj, ako sam dobro shvatio, da programer sam optimizuje svoj
> source kod).
U ovom slučaju čak i izbor "brzog" programskog jezika kakvi su Fortran ili
C smatram za nekakvu vrstu ručne optimizacije, jer ti programski jezici
zahtevaju od programera da, u cilju efikasnosti, zaboravi na neke programske
konstrukcije koje doprinose "boljem" kodu. Boljem u smislu čitljivosti,
jednostavnosti i ponovne upotrebljivosti.
> Onda da pravimo opšti program, jest da ima malo više posla, ali mislim da
> je tako bolje, kako bi neko posle mogao to što uradimo i da iskoristi za
> nešto korisno. U tom smislu predlažem da se deo koda koji se odnosi na
> računanje determinante prebaci u poseban potprogram, a da sve ostalo
> (definisanje matrice, merenje vremena, ispis itd) bude izvan njega.
Dogovoreno!
> Jedino se još nismo dogovorili da li ćemo koristiti real (XT,AT) ili
> protected (386,486,P5 ;) ) mode kompajlere?
Za početak real mod jer ja koristim samo Borland C++, mada će sors biti
portabilan pa neće biti problem da se brzine okušaju i na nekom High ili
Metaware C++-u. Nego, algoritam obojca imamo, mislim da možemo da počnemo?
jezici.75bojt,
-> #74, djelovic>> Nego, algoritam obojca imamo, mislim da možemo da počnemo?
Jedino još da se dogovorimo čime ćemo "puniti" matricu.
Ja sam nešto danas probao i računar (DX2/66) je determinantu
matrice 200x200 (to stane u 640K) u realnom modu radio 3.68sec,
a u protected 1.59. To mi deluje suviše malo za uporedjivanje pa
sam pustio 1000x1000 u prot.modu i radio je 256sec. Možda bi mogli da
napravimo petlju za realni mod, u kojoj bi se jedno 10x računala
determinanta iste matrice?
jezici.76djelovic,
-> #75, bojt> Jedino još da se dogovorimo čime ćemo "puniti" matricu.
100*cos (kolona + red*širina) ?
> Možda bi mogli da napravimo petlju za realni mod, u kojoj bi se jedno 10x
> računala determinanta iste matrice?
OK.
jezici.77bojt,
-> #76, djelovic>> 100*cos (kolona + red*širina) ?
ok
jezici.78dpredovic,
-> #67, bojt> Kompajler generiše OBJ kombinujući te pozive. Fortran ugradjuje
> mnogo manje čekiranja eventualnih run-time grešaka, pošto zbog
> "krutosti" fortrana po definiciji postoji daleko manje
> situacija u kojima se neke greške mogu dogoditi nego kod,
> recimo, C-a. Sa druge strane, kao što sam već jednom napomenuo,
> "krutost" fortrana ostavlja mogućnost da kompjaler, pored
> standardnih, vrši i opzimizacije koda na mnogo višem nivou nego
> kod nižih jezika. Kad se ima u vidu i koliko godina su
> razvijane te optimizacije, u konačnom zbiru uštedi se neko
> vreme.
Hmmm, pitanje je da li te optimizacije mogu da se pokažu bitnijim
od low-level optimizacija koje npr. C kompajler verovatno radi
bolje, jer je jezik low-level.
Izgleda da je merenje stvarno jedino rešenje.
Cu, Dejan
jezici.79spantic,
Povodom rasprave Fortran vs. C++ evo FAQ iz grupe comp.lang.fortran
faq_f.zipjezici.80spantic,
Da se Covci ne nađu zapostavljenim, FAQ iz grupe comp.lang.c
-> Doći će i C++ :))
c-faq-li.zipjezici.81bulaja,
-> #80, spantic│Da se Covci ne nađu zapostavljenim, FAQ iz grupe comp.lang.c
└───
Da ja ne moram džabe da proveravam :), da li su ti C/C++ FAQ
oni koje imamo u C direktorijumu ili noviji?
jezici.82spantic,
-> #81, bulaja> Da ja ne moram džabe da proveravam :), da li su ti C/C++ FAQ
> oni koje imamo u C direktorijumu ili noviji?
Stvarno ne znam, pogledaću te iz konferencije. Inače, ovo je FAQ za plain C.
jezici.83maksa,
-> #81, bulaja>> Da ja ne moram džabe da proveravam :), da li su ti C/C++ FAQ
>> oni koje imamo u C direktorijumu ili noviji?
C FAQ je isti, s tim što onaj u dir-u ima i neki abstract,
tj. dajdžest 'velikog' FAQ-a.
jezici.84afilipovic,
-> #74, djelovic>> U ovom slucaju cak i izbor "brzog" programskog jezika
>> kakvi su Fortran ili C smatram za nekakvu vrstu rucne
>> optimizacije, jer ti programski jezici zahtevaju od
>> programera da, u cilju efikasnosti, zaboravi na neke
>> programske konstrukcije koje doprinose "boljem" kodu.
>> Boljem u smislu citljivosti, jednostavnosti i ponovne
>> upotrebljivosti.
Pratim diskusiju koju vodite pa da se ubacim. Konkretno pisem program
na C++ koji resava neki problem iz elektromagnetike i u njemu mi je zatrebala
inverzija matrice. Tu sada dolazi FORTRAN do izrazaja jer sam odmah mogao
da nadjem na VAX - u u IMSL ili SSP biblioteci odgovarajuci program, ali kada
sam se raspitivao za neku biblioteku na C++ koji radi sa matricama situacija
je otprilike sledeca svi su culi da negde postoji ali konkretno niko nije
imao da mi da ;)).
OK uzmem te programe na FORTRAN - u i pomocu F2C ( prevodi FORTRAN u C )
prevedem taj sors. Ali zelim da mi matrice imaju dinamicke dimenzije sto znaci
da negde na sred programa mogu da stavim nesto u stilu:
cin >> n;
TMatrica a(n,n);
e sada dolazi ovaj tvoj tekst "doprinose boljem kodu " dakle ocu da sa
matricama radim na jedan normalan nacin znaci da elementima matrice pristupam
preko:
a(i,j) = a(i,k) * t;
itd. Dakle moja klasa mogla bi da izgleda ovako (indeksi pocinju od 0 ):
class TMatrica {
double *data;
int dimj;
public:
TMatrica(int i, int j);
~TMatrica();
double& operator()(int i, int j);
};
TMatrica::TMatrica(int i, int j) :
dimj(j)
{
data = new double[i*j];
}
TMatrica::~TMatrica()
{
delete data;
}
inline double& TMatrica::operator()(int i, int j)
{
return data[ i + dimj * j ];
}
Kada sada u istom onom fortranskom programu ( prethodno prevedenom u C )
koristim moj tip podataka mislim da C++ program ne moze da bude brzi od
fortranskog jer ovde imamo jedno mnozenje plus sabiranje da bi se pristupilo
elementu matrice. Sada bi trebalo direktno pogledati *.ASM kod i fortranskog
i C++ pristupa matrici da se vidi ko je kako preveo pristup clanu niza
odnosno ko brze radi ( podrazumevam da se koristi Microsoft PowerStation
32 FORTRAN kompajler jer ima mogucnost rada sa dinamickim nizovima ).
Daklem sto se tice tog dela rada sa matricam dozvoljavam da je Fortranski
program brzi ali moj problem iz elektromagnetike radi jos sa par stvari koji
se u C++ preko klasa jako lepo daju apstrahovati a u FORTRAN - skom programu to
ispadne takva krdza da je to nezamislivo.
Ako sada tu ubacimo i neki oblik korisnickog interfejsa onda koristeci
recimo TVision od Borlanda u C++ je to krajnje jednostavno dok za fortran
(netvrdim da nema) nisam video tako mocan alat.
Dakle savremeni programi su izuzetno kompleksni i C++ ( mislim na objektno
programiranje) omogucuje da se mi izborimo sa tom kompleksnoscu. To nikako
neznaci da ce obavezno sve funkcije raditi brze nego one na FORTRAN - u ali
je sigurno da takve kompleksne programe nebi mogli da pisemo u FORTRAN - u
( ili bi mogli da se pisu uz velike ljudske napore i utrosak vremena ). A
da ne govorimo u odrzavanju, prosirivanju ili ponovnoj upotrebi koda koja
je kod C++ neuporedivo veca nego kod FORTRANA.
Pozdrav, Nenad
jezici.85djelovic,
-> #84, afilipovic> Kada sada u istom onom fortranskom programu ( prethodno prevedenom u C )
> koristim moj tip podataka mislim da C++ program ne moze da bude brzi od
> Fortranskog jer ovde imamo jedno mnozenje plus sabiranje da bi se
> pristupilo elementu matrice.
A šta fali konstrukcijama tipa "data = new double [j][i]"? U tom slučaju se
pristup članu niza svodi na korišćenje pointera.
> Tu sada dolazi FORTRAN do izrazaja jer sam odmah mogao da nadjem na VAX -
> u u IMSL ili SSP biblioteci odgovarajuci program, ali kada sam se
> raspitivao za neku biblioteku na C++ koji radi sa matricama situacija je
> otprilike sledeca svi su culi da negde postoji ali konkretno niko nije imao
> da mi da ;)).
Da još uvek imamo pristup 3klu, dobio bi ti Biblioteku za rad sa matricama
u roku od par sati. Ovako, C++ je relativno nov jezik, a još u Jugoslaviju nove
stvari stižu relativno sporo, pa nije ništa čudno što ima više softvera za
Fortran nego za C++.
P.S. "TMatrica"? Prefiks 'T' se koristi za ekranske objekte. Za matematičke
možemo i bez prefiksa, ili, ako si baš navalio :), daj da izaberemo neko
drugo slovo. 'M'?
jezici.86srdjan.j,
-> #85, djelovic==> P.S. "TMatrica"? Prefiks 'T' se koristi za ekranske objekte. Za
==> matematičke možemo i bez prefiksa, ili, ako si baš navalio :), daj
==> da izaberemo neko drugo slovo. 'M'?
A možda je "T" od Type :). Koliko sam ja video sve klase u Borlandovim
hijerahijama počinju sa T, čak i kontejnerske klase, dok kod MS-a je taj
prefiks C ( od Class ).
jezici.87djelovic,
-> #86, srdjan.j> Koliko sam ja video sve klase u Borlandovim
> hijerahijama počinju sa T, čak i kontejnerske klase
Mislim da ovo nije tačno? Klase iz Turbo Visiona i OWL-a počinju sa 'T',
dok NIH klase (kontejnerske i ostale) nemaju neki prefiks. E sad, šablonske
kontejnerske klase opet imaju prefiks, i to bogami dugačak: BI_O i BI_T. Da ne
bude zabune, ono "BI_" stoji za "Borland International" :).
jezici.88bojt,
-> #87, djelovic>> Mislim da ovo nije tačno? Klase iz Turbo Visiona i OWL-a
>> počinju sa 'T', dok NIH klase (kontejnerske i ostale) nemaju
>> neki prefiks. E sad, šablonske kontejnerske klase opet imaju
>> prefiks, i to bogami dugačak: BI_O i BI_T. Da ne bude zabune,
>> ono "BI_" stoji za "Borland International" :).
Dakle sve u svemu vrlo standardizovano... ;)
jezici.89jmilovic,
-> #71, djelovic> Medutim, za takav korak se vecina firmi odluci tek kada stari
> Fortran programi postanu prekomplikovani za odrzavanje, a onda
> u igru dolaze razni CASE alati koji uz konverziju rade i
> prestrukturiranje, objektizovanje i sl. uz pomoc ljudi.
Posto radim u COBOL-u, ( MS COBOL 2.10, 1985 god. ) interesuje me
dali postoje CASE alati koji uz konverziju rade i prestrukturiranje,
objektizovanje ,itd...
Radi se o oko hiljadu programa pisanih za osam aplikacija, koje
obuhvataju kompletno poslovanje firme u kojoj radim.
jezici.90djelovic,
-> #89, jmilovic> Posto radim u COBOL-u, ( MS COBOL 2.10, 1985 god. ) interesuje me
> dali postoje CASE alati koji uz konverziju rade i prestrukturiranje,
> objektizovanje ,itd...
Da, recimo re/NuSys i VANtage koje pravi Scandura Intelligent Systems.
Ovakvi CASE paket su obično malo skupi ($10,000 i više), ali pretpostavljam da
to i nije neka velika para za firme.
jezici.91afilipovic,
-> #85, djelovic>> A sta fali konstrukcijama tipa "data = new double
>> [j][i]"? U tom slucaju se pristup clanu niza svodi na
>> koriscenje pointera.
Pa zar to nije isto ono sto sam ja napisao. Naime u klasi TMatrica
pristupa se clanovima niza preko pointera data, ali da bi mogao izracunati
poziciju nemoze se izbeci sabiranje i mnozenje.
Naime kada se definise matrica sa konstantnim dimenzijama recimo:
double matrica[3][4];
a onda u programu koristi matrica[i][j] kompajler posto zna dimenzije
matrice u vreme kompajliranja (a matrica se posmatra kao pokazivac) generise
kod koji je ekvivalentan sa:
((double *)matrica)[ i * 4 + j ] //smestanje po vrstama !!!
ako zelimo da imamo dinamicku matricu pa probamo nesto kao:
matrica = new double[n][m]; // gde m i n neke promenjive
onda ako koristimo matricu u obliku:
matrica[i][j]
to odgovara kodu:
*(* (matrica+i) + j)
a to nije ono sto smo zeleli dakle nemoze se tako pristupati clanu matrice.
Onda ostaje onaj pristup sa mnozenjem i sabiranjem kao najbrzi nacin da
zadrzavajuci koliko toliko normalnu sintaksu oblika a(i,j) pristupimo clanu
dinamicke matrice. Ako bi se zelelo da se ostane u duhu C - a pa koristi
nesto u obliku matrica[i][j] moze se i to izvesti ali bi bila potrebna dva
poziva operator[](int n) funkcije sto je sporije.
Pozdrav, Nenad
jezici.92djelovic,
-> #91, afilipovic> double matrica[3][4];
>
> a onda u programu koristi matrica[i][j] kompajler posto zna dimenzije
> matrice u vreme kompajliranja (a matrica se posmatra kao pokazivac)
> generise kod koji je ekvivalentan sa:
>
> ((double *)matrica)[ i * 4 + j ] //smestanje po vrstama !!!
Jok. Matrica se definiše kao niz pointera na nizove :), tj. konstrukcija:
double **matrica = new double [Y][X];
grubo gledano je ekvivalentna sa:
double **matrica = new double* [Y];
for (int i = 0; i < Y; i++)
matrica [i] = new double [X];
BTW, to i jeste razlog zašto mislim da će C++ funkcija (čim stignem da
je napišem :( ) biti brža od svog Fortran ekvivalenta:
a) Brže se pristupa elementima matrice,
b) kada treba da, recimo prilikom pivotizacije, zamenim mesta redovima,
ja praktično zamenjujem samo dva pointera, a Bojt zamenjuje mesto svim
članovima.
No, ko' što kažu, we shall see.
jezici.93bojt,
-> #92, djelovic>> BTW, to i jeste razlog zašto mislim da će C++ funkcija (čim
>> stignem da je napišem :( )
Ajde već, pa nije to OCR ;)
>> biti brža od svog Fortran ekvivalenta:
>> a) Brže se pristupa elementima matrice,
Okreni obrni na kraju se pristupanje elementu svodi na
izračunavanje njegove pozicije od početne adrese matrice, tj i*n+j.
Medjutim, fortran optimizator obično ispituje zakonitost po kojoj
se prisutpa elementima matrice u okviru petlji, tako da izračuna
konstante koje treba dodavati nekom registru (u kome je na početku
bila početna adresa matrice) da bi se pristupilo odredjenom
elementu. Dalje, program treba pisati tako da se u okviru poslednje
petlje (one koja se najviše izvršava) praktično pristupa kao
jednodimenzionalnim nizovima. Na primer, ako kompajler matricu
A(N,M) pakuje vrstu po vrstu (tj m puta po n elemenata), petlja
(koja se najviše izvršava)
for k=i+1 to n
a(k,j)=a(k,j)+b*a(k,i)
next
se kodira (otprilike) na sledeći način: neka se u X registru
procesora nalazi adresa elementa a(i+1,i), a u registru Y adresa
elementa a(i+1,j). Neka se u Floating point registru F3 nalazi b.
Elem, to bi izgledalo ovako (napomena: ovo je neki fiktivni
asemblerski algoritam):
(Y)->F1 ; ovo radi rutina koja 8 bajtova prebaci sa
; memorijske lokacije sadržane u Y u FP registar F1,
; posle čega je Y=Y+8
F1=F1*F3
PUSH X
(X)->F2 ; isto kao za Y
F1=F1+F2
POP X
F1->(X) ; posle ovoga X je opet X+8, tj spremno je da
; adresira sledeći element u sledećoj operaciji. To
; isto važi i za Y
LOOP
Da sada ne bi komplikovao, po istom principu rade sve tri petlje
koje su suština Gausove eliminacije. Za elemente A(i,i) koji se
pojvaljuju u prvoj (i) petlji se na registar u kojem je bila
početna adresa matrice dodaje n+1, pa PUSH, POP itd. U j petlji se
na registar koji u početku uzme vrednost i registra dodaje n itd.
>> b) kada treba da, recimo prilikom pivotizacije, zamenim mesta
>> redovima, ja praktično zamenjujem samo dva pointera, a Bojt
>> zamenjuje mesto svim članovima.
Kako onda pamtiš gde ti se koja vrsta nalazi? Za tako nešto moraš
da uvedeš poseban int niz koji bi ti pokazivao koja je (apsolutna)
vrsta na redu za obradu, tj trebalo bi ti više memorije, a nekako
mi se čini da se tu krije i značajna vremenska stativa.
Pivotizacija se ne dešava tako često, a može da se dogodi da ne
dodje ni do jedne pivotizacije. Tim pristupom uvlači se pojam
"vrste za obradu" (čak i uz maksimalnu optimizaciju) u dve od tri
petlje (i i j, a ako je opt. loša onda i u k, tj u sve tri).
Sa druge strane, polazeći od principa optimizacije koje sam gore
opisao, potrebno je samo zameniti deo memorije sa dve različite
memorijske lokacije ( (X)<->(Y) u petlji (n-i) elemenata), što je
brzo kao munja.
>> No, ko' što kažu, we shall see.
Pa let's see. ;)
jezici.94djelovic,
-> #93, bojt> Okreni obrni na kraju se pristupanje elementu svodi na
> izračunavanje njegove pozicije od početne adrese matrice, tj i*n+j.
Nisi svatijo :). C i C++ matrice predstavljaju kao niz pointera na nizove.
Znači, kada se pristupa elementu [4][5] (red četvrti, kolona peta), onda
kompajler uradi sledeće:
Uzme početni adresu niza, i doda joj četiri veličine pointera, dakle
šesnest. Onda tu pročita pointer, koji je efektivno pointer na četvrti red
matrice. Sada uzme vrednost tog pointera plus pet, i eto ti člana. Grubo
gledano, na RISC mašinama ovo se svodi na dva sabiranja i dva dereferenciranja,
dok se na CISC mašinama to pakuje kao dva dereferenciranja sa ofsetom (koje to
beše adresiranje?).
P.S. Ne znam da li sam dobro objasnio, jedan dobar crtež bi rešio sve probleme.
Ovo pamćenje nizova kako to C i C++ rade je ujedno i odgovor na tvoje
pitanje o zameni redova - zamene se dva pointera na redove, i to je to.
jezici.95bojt,
-> #94, djelovic>> >> Okreni obrni na kraju se pristupanje elementu svodi na
>> >> izračunavanje njegove pozicije od početne adrese matrice,
>> >> tj i*n+j. <------------------
>> Nisi svatijo :). C i C++ matrice predstavljaju kao niz
>> pointera na nizove. Znači, kada se pristupa elementu [4][5]
>> (red četvrti, kolona peta), onda kompajler uradi sledeće:
>> Uzme početni adresu niza, i doda joj četiri veličine
>> pointera, dakle šesnest.
4x4=16. Otprilike kao i*n ? ;)
>> Onda tu pročita pointer, koji je efektivno pointer na četvrti
>> red matrice. Sada uzme vrednost tog pointera plus pet, i eto
>> ti člana.
+5. Otprilike kao +j ? ;)
jezici.97djelovic,
-> #95, bojt> 4x4=16. Otprilike kao i*n ? ;)
E mnogo si dosadan :). Nije, nego otprilike kao 4 << 2. Pošto je veličina
pointera unapred poznata, koristi se nekakav ekvivalent pomeranja ulevo.
P.S. Uta-ta, uta-ta :).
jezici.98bojt,
-> #97, djelovic>> E mnogo si dosadan :). Nije, nego otprilike kao 4 << 2. Pošto
>> je veličina pointera unapred poznata, koristi se nekakav
>> ekvivalent pomeranja ulevo.
Ok. A šta se dešava ako radiš sa trodimenzionalnom matricom? Onda
imaš dvodimenzionalni niz pointera (generalno valjda poniterski niz
ima n-1 dimenziju glavnog niza), što može da api pozamašnu količinu
memorije (a kod matrica, zna se, memorije nikad dosta). U slučaju
matrica sa promeljivim dimenzijama to je sasvim ok i omogućava
značajne uštede u memoriji. Medjutim, ako su matrice pune, samo se
džaba arči memorija na poinetrske nizove. Što se tiče brzine
pristupa elementu, ajde slažem se da preko pointerskog niza može
brže da se prisutpi, ali to je samo teorijskom nivou, pod
pretpostavkom da nema optimizacije kompajlera. Praktične uštede u
brzini taj pristup bi mogao dati tek u slučaju da se elementima
matrice pristupa sumanuto po nekom random principu. žim postoji
neka zakonitost, dobar optimizator će pristup tekućem elementu
svesti tek na *jedno* sabiranje, to jest na predhodnu adresu dodaće
na početku definisanu konstantu. A PUSH i POP opreacije (ili
operacije tipa Zreg=Xreg, ako se PUSH i POP izvršavaju u više
ciklusa nego dodeljivanje jednog procesorovog registra drugom, a
ima dovoljno slobodnih registara), su neuporedivo brže nego svaki
put ponovno pristupanje preko pointerskih nizova...
Nego, kad će bre više ta determinanta? To je samo 15-20 linija
koda...
jezici.99smarkov,
-> #74, djelovic> portabilan pa neće biti problem da se brzine okušaju i na nekom High ili
> Metaware C++-u. Nego, algoritam obojca imamo, mislim da možemo da počnemo?
Na Visual ili Microsoft C++-u :)
P.S. HighC je proizvod MetaWare-ta. Nemoj da mi pravite zabunu oko
omiljenog kompilatora :).
jezici.100afilipovic,
-> #92, djelovic>> Jok. Matrica se definise kao niz pointera na nizove :),
>> tj. konstrukcija: ^^^^^^^^^^^
To je tacno i to je upravo ono sto sam ja pricao za konstantne matrice
odnosno za matrice cije se dimenzije znaju u vreme kompajliranja jer onda
kompajler primenjuje sledece pravilo:
Ako je I n - dimenzioni niz ranga ixjx...xk, tada se I, kad se pojavi
u nekom izrazu, pretvori u pokazivac na (n-1)-dimenzioni niz ranga jx..xk
^^^^^^^^^^^^^^^^^^^^^^
u ovome je poenta, jer samo zahvaljujuci
poznatim dimenzijama moze kompajler
kada mu kazes I+broj da to ustvari
pretvori u:
I + sizeof(j*...*k)*broj
Ako se sada operator * primerni na ovaj pokazivac, bilo eksplicitno ili
implicitno kao rezultat indeksiranja, rezultat je pokazani (n-1) dimenzioni
niz, koji se sam odmah pretvori u pokazivac itd.
>> double **matrica = new double [Y][X];
^^^^^^^
E ovo nije ekvivalentno matrici kako se definise u C++ evo probaj
primer (to nece inace ni da prodje kroz kompajler al ajde diskusije radi):
void ispis( int**ulaz)
{
// recimo ispis clanova niza u petlji
}
void main()
{
int matrica[2][3] = { {1,2,3}, {4,5,6} };
ispis(matrica);
}
Kompajler javlja sledecu gresku:
Error : Cannot convert 'int[3] _ss *' to 'int * *'
^
To je ono I koje se odmah pretvori u
pokazivac na niz (n-1) ranga u ovom
slucaju u int[3].
Error : Type mismatch in parameter 'ulaz' in call to 'ispis(int * *)'
Dakle jest da su i jedno i drugo pokazivaci na pokazivace ali se njihovi
tipovi razlikuju u jednom slucaju ti imas niz pokazivaca na int a u drugom
niz nizovaa int[3].
Sve u svemu kompajler je zahvaljujuci poznavanju dimenzija niza sam
formirao formulu i*n+j za pristup clanu niza.
>> double **matrica = new double* [Y];
>> for (int i = 0; i < Y; i++)
>> matrica [i] = new double [X];
E ovo sto si ti uradio je nesto sasvim drugo naime ovde imas X*Y clanova
alocirano + jos Y pokazivaca tako si trampio memoriju za brzi pristup
clanovima niza preko dva sabiranja a to nije ono sto radi kompajler sa
matricama sa konstantnim dimenzijama.
Pozdrav, Nenad
.P.S. Inace ta caka memorija / brzina je zakon odrzanja energije i materije
primenjen na racunare ;)).
jezici.101afilipovic,
-> #95, bojt>> 4x4=16. Otprilike kao i*n ? ;)
>> +5. Otprilike kao +j ? ;)
Jest bas tako ;)))). Pokopa covek sam sebe.
Pozdrav, Nenad
jezici.102djelovic,
-> #100, afilipovic> int matrica[2][3] = { {1,2,3}, {4,5,6} };
> ispis(matrica);
U pravu si! Gledajući adrese članova niza, očigledno je da ih kompajler
slaže red po red u memoriju.
P.S.
> >> Jok. Matrica se definise kao niz pointera na nizove :),
>
> To je tacno i to je upravo ono sto sam ja pricao za konstantne matrice
> odnosno za matrice cije se dimenzije znaju u vreme kompajliranja jer onda
> kompajler primenjuje sledece pravilo:
S obzirom da je moja tvrdnja pogrešna, onda je i ovo gore. Za matrice
čije su dimenzije poznate za vreme komapajliranja, matrica se *ne* definiše
kao niz pointera na nizove.
jezici.103djelovic,
-> #101, afilipovic> Jest bas tako ;)))). Pokopa covek sam sebe.
Ovde već nisi u pravu :). Za matricu čije dimenzije nisu poznate za
vreme kompajliranja, operator [][] je potpuno neupotrebljiv - za
višedimenzionalne nizove kod operatora new svi indeksi osim "najlevljeg"
moraju da budu poznati za vreme kompilacije. Zato je *jedini* način da se
definiše dinamička matrica preko niza pointera na pointere, što onda za
pristup članovima daje moju formulu.
P.S. Proverio sam u knjizi :).