Basicból C/C++

Fórumok

Sziasztok.

Kaptam egy ősi Quickbasic-ban írt programot, amit át kellene írnom, és továbbfejlesztenem C, vagy C++ ban. Az a gáz, hogy nincs Windowsom, így elindítani sem tudom. ha más nem wine+quickbasic, de van valami alternatíva Linux alól fordítani a qbasic kódot?

Hozzászólások

Ez egy nagyon szemét, pepecselős meló. Nekem Pascal programot kellett átírnom valamikor.

Úgy érdemes csinálni, hogy sorról sorra át kell írni először. Aztán ha lefordul akkor kigyomlálni belőle goto-kat. Letisztázni meg úgy, hogy külön függvényeket kell kialakítani.

Basickel az a gond minden fordítónak más elképzelései vannak magáról a nyelvről. QBasices cuccot csak qb-vel tucc fordítani.

--
GPLv3-as hozzászólás.

Ha látnád a kódot. Valami rettenet, szerintem "nyugdíjas állásom" van.
Részlet:

IF i >= 167 AND i <= 188 AND j = 20 THEN GOSUB 600
IF i >= 168 AND i <= 188 AND j = 21 THEN GOSUB 600
IF i >= 169 AND i <= 188 AND j = 22 THEN GOSUB 600
IF i >= 170 AND i <= 188 AND j = 23 THEN GOSUB 600
IF i >= 172 AND i <= 188 AND j = 24 THEN GOSUB 600

IF i >= 132 AND i <= 164 THEN IF j = 19 THEN GOSUB 615
IF i >= 132 AND i <= 165 THEN IF j = 20 THEN GOSUB 615

IF i >= 158 AND i <= 166 THEN IF j = 21 THEN GOSUB 615
IF i >= 162 AND i <= 167 THEN IF j = 22 THEN GOSUB 615
IF i >= 166 AND i <= 168 THEN IF j = 23 THEN GOSUB 615

511 IF fo = -1 THEN ha = h2: hb = h1
512 FOR i = ha TO hb STEP fo
515 FOR j = 0 TO 60
IF i > 188 THEN u(i, j) = 0: GOTO 520
IF j > 30 THEN u(i, j) = u(i, 60 - j): GOTO 520
IF i = 0 OR i = 195 OR j = 0 OR j = 60 THEN u(i, j) = 0: GOTO 520
IF j = 30 THEN u(i, j) = (.5 * (u(i - 1, 30) + u(i + 1, 30)) + 2 * u(i, 29)) / 3: GOTO 516
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Sokkal jobb van. Ismerem az urat aki írta, és segít benne. Mondta is hogy nagyon gáz a program szerkezete, mert együtt tanulta a basic-et a program írásával. Egyébként egy kiváló kutató, csak már idős, és nincs rá energiája hogy C-t is tanuljon.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

nem kell letorni a kezet. anno a basic a valtozok elso ket betujet vette figyelembe a sebesseg miatt. aki ezt irta, még valami 8 bites interpreteren tanult ( C64 Basic vagy Microsoft Level II es tarsai ), vagy ez mar qb-ra is ugy lett 'portolva, hiszen normal esetben a qb-hez ember csak akkor fordult, ha pisztolyt szoritottak a fejehez; letezett mar jol hasznalhato es relative gyors kodot generalo Turbo Pascal meg Microsoft C is...

igy van, bar en szerettem a qb-t, lehetett benne azert muveszekedni:)))
En pl odaig vetemedtem qb-ben hogy 3D engine-t irtam (max 2 lightsource, polygon texture mapping, raytraced shadows).
Igaz, annak ellenere hogy real time engine volt, a gepemen (386sx), legalabb masfel percig generalt egy kepkockat 1024x768-ban;)

Igen. Ez az a részlet. Egyébként irányított ionmozgást szimulál elektromos térben. Egy olyan eszköz modellje amivel nanométer pontosan lehet vékony-réteget felhordani, vagy eltávolítani. Ez utóbbi a gyakoribb.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Azzal az a gond, hogy tempó is kell. Ez a basic kód egy borzasztóan kicsi rácsot dolgoz fel. Emiatt nem is igazán használható hatékonyan a basic kód. Nagyobb rácson visont "űridő" alatt fut le. Ezért inkább hajnalnék az alacsony szintre, mert nagyon sok próbát kell majd vele készítenem.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Persze, Python...

Szokasos kedvenc nyelv beajanlasa helyett meg is lehetne nezni, hogy mi a feladat es ha ugy is a gyorsasag kell valamint nagy adathalmaz van, akkor inkabb azon kene elgondolkozni, hogy CUDA-ra vagy OpenCL-re kene atirni, _ha_ parhuzamosithato.

----------------
Lvl86 Troll

Tekintve, hogy a QB egy halott valami, a hozza kapcsolodo interpreterek, forditok is valoszinuleg a mai rendszerekhez kepest melyen szuboptimalis teljesitmenyt tudnak csak nyujtani.
A "megneznek egy pythont vagy javat" felvetessel arra probaltam utalni, hogy nem feltetlen kell az egesz programot alacsony szintu nyelvre (C, ASM) levinni. En el tudok kepzelni egy olyan rendszert, ahol az effektiv szamitast egy C modul vegzi, de a megjelenitest pl. sima python/java/ruby kod csinalja, mert azt meg abbol egyszeru. Oda nem kell teljesitmeny, az a szamitashoz kell, es valoszinu, hogy inkabb ez lesz a lassu a QB programban, nem pedig az effektiv megjelenites.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ez maga az effektív számítás, amit portolni kéne. kb: "ne meghámozd az almát, hanem süss belőle pitét és abba tegyed az almát." amikor a látóhatáron se volt tészta.

Amúgy meg szerintem a python közösség is megmondja, hogy a python nem differenciálegyenletek párhuzamos megoldására van. (a Java-sok nem, mert ők hazudnak). Teljesen jogos ide az OpenCL felvetés, ha van rá mód, hogy kihasználható legyen. (gondolom lehet előre tudni, milyen gépen fog futni)

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

facepalm.

a melledumat meg ne eroltesd, megint benezted, esz nelkul beboffentettel valamit, aztan annyi.
nem kell kimosakodni.
(c modul + python java ruby modul megjelenitesnek kulon, na persze... osszeileszteni a a kettot nagyobb erofeszitest, mint c-ben megcsinlani a megjelenitest, vagy akkor mar ha mindenkepp keverni akarod a nyelveket, legyen akkor mar inkabb c es c++, ah de minek is koptatom a billentyuzetemet egy mar messzirol oltari baromsagnak kinezo hozzaszolas megvalaszolasara...)

Mar miert lenne nagyobb erofeszites? Ruby-C eseteben szamokat a legkonnyebb dobalni a ket reteg kozott. Ha stringekrol lenne szo, azt mondom igazad van, ott egy kalap minden elofordulhat, de a szamok atvetele az viszonylag egyszeru, meg akkor is, ha float.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A helyzet az, hogy államtitoknak nem államtitok, de szabadalom védi azt a terméket, ami ezzel a szimulációval készül. Egy fentebbi hozzászólásodra annyit, hogy párhuzamosítva lesz, és őszintén szólva én egyszerűen pthread-el gondoltam. Ugyanolyan szálakat kell indítanom más más kezdőfeltétellel. Ugyanis egy csomó ion mozgását írja le, melyeknek az egymásra gyakorolt hatása elhanyagolható, ergo minden mozgás mehet külön szálba. Egyszerű 4.rendű Runge Kutta egyenleteket old meg minden részecskére. Ettől komolyabb thread-elést nem akarok készíteni, ugyanis szerintem nem lenne gyakorlati haszna. A Cuda esetleg jobb lehetne, de ahoz olyan vga-kell....... Nem biztos, hogy mindenkinek van, aki használni fogja....

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

ha kell a teljesitmeny, azert ne vesd el a cuda/opencl verzio lehetoseget.
csak osszehasonlitaskent, most eppen vissza kell(ene) fejtenem egy hasht, a hashcat 3.2Ghz negymagos cpuval 8 szalon tud ~24k/s -t ; amig a mezei hd4350 oclhashcat+ kombo 33k/s ( a kartya kb. 8-9 eft ) hd5570 ( asus silent 15eft ) 320k/s

Persze tiszta sor. Az igazság az, hogy előzetes becslésem szerint egy szimuláció sima C-vel pthread-el max 2-3 perc lesz (az én gépemen), azon felül erre már írtam jópár dolgot, tehát félkész (inkább 90%-ban kész) algoritmusaim vannak, viszont tuti, hogy minden gépen fut. Ha lesz időm megírom az a cuda/opencl-t, de ott tényleg teljesen 0-ról kell írnom.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

nohat, pont ide illik, lesz penteken ez a gpu nap vagy micsoda.
aszondja ez ( http://www.grid.kfki.hu/twiki/bin/view/GPU/Ismerteto )az 'ismerteto' ize hogy :

"Napjainkban ~0.5 M ft-ból egy PC és a benne elhelyezett 4 grafikus kártya segítségével kb ~5-7 Teraflop számítási kapacitast lehet elérni. (Összehasonlításul egy sima PC kb ~30 Gigafloppos teljesítményével ez 130-szor nagyobb kapacitast jelent.) "

mondjuk ha jol szamolom, 5TFlop / 4 = 1.25 Tflop / grafzsuga, még mindig 30-40x teljesitmeny.

És mi lesz, ha még nagyobb lesz a feldolgozandó adatmennyiség?

Nem akarlak mindenáron rábeszéni, mert te látod a konkrét feladatot, de C elég jól portolható CUDA-ra vagy OpenCL-re, ha egy pár dolgot figyelembe veszel az elején az algoritmus tervezésénél.

(szvsz. CUDA-val is be lehet szopni, ha nem akar összeállni az nvcc normálisan az IDE-vel, mint nekem VS2008 alatt - bár OSX+Xcode alatt ment szépen pöccre - szerintem kevésbé szopatod magad -- mondom ezt úgy, hogy egyébként magát az nVidiát és a termékeit rühellem :)

----------------
Lvl86 Troll

update. szereztem tesztre kolcsonbe egy zafir hd5830 cuccot. ( 26Khuf brutto ) 1350k/s
bakker ez 4x gyorsabb, mint az 5570. csak 2 - 2.5x -re szamitottam. mindjart meg is tunningolom, allitolag lazan lehet rajta 100 - 150 Mhz -t tolni.

mondjuk az amd szerint
http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-5000/hd-5…

van benne egyszeres pontossaggal 1.792 TeraFLOPS duplaval meg 358 GigaFLOPS

Nálam megnyerte az obfuscated QBasic contest-et.
Pajtás szerintem te egy Malbolge -> QBasic -> C projekt második szakaszába estél be.

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

Nosztalgikus hangulatom támadt...

Réges-rég én is írtam numerikus modellezést Basic-ben, 8 bites gépen, 2 karakteres változónevekkel és azok első verziója volt hasonló. Aztán gyorsan beszereztem valami Basic bővítést, ami gosub helyett paraméteres függvényhívást tudott és kicsit jobb lett (azt hiszem GR-basic volt C64-en), plusz az if-then szerkezetekben igyekeztem valami átlátható megoldásra jutni. (+ a legbelsőbb részeket átírtam assemblybe később, hogy le is fusson épeszű idő alatt) Láttam azonban ilyen kódot eleget, írtam is át először Pascalra, aztán C-re párat.

A lényeg: ne próbáld portolni, írd újra, ha lehet (azt írod, van erre mód), mert bármilyen értelmes nyelven ha megérted mi van, sokkal hatékonyabb, áttekinthetőbb, javíthatóbb kódod lesz.

Szegény "programozó", aki csak a Basic alapjait tudta, valamit kiizzadt magából (magamra ismerek), örült, hogy működik. Egy következő fejlődési állapot volt (nem mindenki jutott oda), hogy a Basic-et átláthatóbban használja: ez már ott tudott nagyot dobni a hatékonyságon és átláthatóságon. A C-nek az olyan fantasztikus szerkezetei, mint a switch vagy a többsoros if-then-else ágak meg egyenesen megváltást jelentenek.

Ilyen újrakódolásokról az a tapasztalatom, hogy akár fele annyi leütésből, sokkal áttekinthetőbb kód írható, ami még hatékonyabb is, ha az ember már a C lehetőségei ismeretében újrakódol.

+1

És nem is csak magáról a nyelvről van itt szó.

A numerikus modellezésnek könyvtárnyi irodalma van, okos emberek rengeteg munkával kitalálták, hogy az egyes fizikai problémákat hogyan lehet jól lefordítani a numerikus algoritmusok nyelvére (nem mellesleg közben arra is rámutattak, hogy hogyan lehet rosszul csinálni mindezt). Ha valaki most nekiáll hasból, egy harminc éve is rossz szerkezetű kód alapján újraírni egy ilyen feladatot, az szinte biztos, hogy belefut valamelyik zsákutcába.

Tehát a legjobb megoldás az lenne, ha a kérdező megértené a kiinduló problémát, aztán annak ismeretében irodalmazna és írná újra a kódot a tanultak alapján. (Idő- és energiabefektetés szempontjából valószínűleg nem ez a legjobb megoldás, de a végeredmény minősége szempontjából mindenképpen.)

Legtöbb Basic-nek annyira jó volt a parser/tokenizer-e, hogy már azzal fel tudtad gyorsítani, ha kitörölted a szóközöket. Paul Allen én így szeretlek.

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

Ja! Meg ha memória-manipulációval egyesítette az ember a sorokat (a C64 80 karaktereseket tudott bevinni, de 256 karaktereseket tudott kezelni), valamint a sokszor lefutó ciklusokat előre pakolta a kódban, ... az is sokat gyorsított. :-)

Kreatívvá tette az embert, az biztos!

Hmm annó amikor C64-eztem, (mondjuk nekem az a általános/középsulis korszak) volt egy remekt számtek tanárom, aki ecsetelte, hogy a basic miért zsákucca (jó ha 5%-át értettem akkor), és szépen elkezdett asm-re tanítani, mert látta, hogy tetszik, de lelépett az iskolából, mert a menyasszonya külföldi volt...... Így sokra nem haladtam. Nagyon nagyon sajnálom. Ha akkor jól meg tudom tanulni, nagyon sok szívástól kíméltem volna meg magamat.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Szerintem QBasic-rol portolva valamit meg AppleScripttel is fenysebessegeket lehetne elerni

(Diszklemer: az AppleScript egy hihetetlenul lassu, es nagyonis interpreteres nyelv.)

Viszont, amit en tanacsolok neked, az nem ez: en azt mondanam, fogj rahedli sok peldafajlt, es csinalj magadnak egy automatizalt tesztkornyezetet.

Az automatizalt kornyezet viselkedese a kovedkezo:
- fogja a peldafajlt, lefuttatja az uj kodon, tarolja az eredmenyt
- fogja ugyanazt a peldafajlt, elinditja dosemu-val a qbasic-et, betolti ennek a csodanak, tarolja az eredmenyt
- a kettot osszehasonlitja, ha kulonbozik, hibat ir ki.

Elso korben ne probalj olyan imrpovementeket csinalni a kodon amik megvaltoztathatjak a kimeneteket. Az oreg ugyanis nem ma irta ezt a kodot (tippre ez a 80-as 90-es evekben lehetett), es ember legyen a talpan, aki ennyi ido alatt tenyleg emlekszik arra, mit miert csinalt, ha ket betus valtozonevei es gosub-jai voltak csak. Igy marad az, hogy az eredetihez kell ellenorizned, jol csinalod-e.