Fura jelenségek BASIC-ben

Elevenítsük fel amit illik tudni a Spectrum 48 BASIC-jéről, BASIC programozásáról...
Avatar
Asimo
Speccyalista
Hozzászólások: 147
Csatlakozott: 2012.01.09. 18:49

Re: Fura jelenségek BASIC-ben

Hozzászólás Szerző: Asimo » 2012.05.13. 20:32

Amúgy, pontosan miért van ez a várakozás?
Most nézem, hogy pont 3.5MHz vs. 4MHz az eltérés. Csak nem ZX Spectrum kompatibilitás miatt került bele? :roll:

Avatar
Zozosoft
Speccyalista
Hozzászólások: 726
Csatlakozott: 2012.01.06. 14:03
Kapcsolat:

Re: Fura jelenségek BASIC-ben

Hozzászólás Szerző: Zozosoft » 2012.05.13. 21:27

Asimo írta:Így pont 2x-es a különbség.
Csak azt nem tudni, hogy ebből mennyi a számolási módszer miatti különbség :oops:
Eleve az IS-BASIC több utasítást ismer, ráadásul bővíthető is, így eleve több munkát végez az utasítás feldolgozás során.
Pluszban ott van az operációs rendszer háttérben végzett műveletei is, az régi EP-s trükk, hogy sokáig tartó BASIC programrészeknél likvidáljuk a megszakításokat egy POKE 56,201-el :D
Amúgy, pontosan miért van ez a várakozás?
Tippem az, hogy akciósan jutottak hozzá döglassú 300 nanos memóriákhoz, amik főleg a korai gépekben fordulnak elő, ezért :oops: mondjuk mivel sok program letiltja a várakozást, ezek a gépek már átestek RAM cserén, ha nem bírták a teljes tempót.
Az igaz, hogy EP64-en ez a várakozás nem kikapcsolható?
Nem igaz, viszont ez a beállítás ott csak a ROM-ban futó programrészekre van hatással. Viszont ott a fő lassúságot az okozza, hogy minden RAM egyben videó RAM, és ott a Nick chipnek van priorítása, ezen nem lehet gyorsítani.

Avatar
Pgyuri
Speccyalista
Hozzászólások: 485
Csatlakozott: 2012.01.06. 13:34

Re: Fura jelenségek BASIC-ben

Hozzászólás Szerző: Pgyuri » 2012.05.16. 10:18

Üdv,

Igazi "Lalá"-s hozzászólás, ezek mindig nagyon tetszenek :) Alaposan körbejárt, átgondolt, ellenőrzött hozzászólás. Bárcsak ilyen lenne mindenki a világban minden témában ....

A valós számmal nem az a probléma, hogy a tárolási elvéből adódóan képtelenség pontosnak lennie (ez korszerű gépeken is csodálatos eredményeket produkál, létezik -0 és még számtalan probléma), hanem az, hogy az egyszerű BASIC nyelvnek meg kellett volna oldania, hogy lekezelje ezt a problémát (mégiscsak Beginners All-purpose Symbolic Instruction Code). Választhattak volna olyan megoldást, ahol az összehasonlítást egy adott belső tizedes hosszig végzik el, de akár más trükkel is, de az, hogy egy sima IF A=1.3 THEN utasításhoz szakmai egyetemi végzettség kelljen, kissé banális.

Zozo, a POKE-ra pedig ne nagyon legyen büszke az Enterprise gép, mert nagyon nagy hasonlóságot mutat a kb. ezerszer butusabb ZX-81 FAST, SLOW dolgához :) Még ha így is van, akkor se büszkélkedjen egy BMW, hogy a Trabantból vették át az indexet :D

Pgyuri

Avatar
Asimo
Speccyalista
Hozzászólások: 147
Csatlakozott: 2012.01.09. 18:49

Re: Fura jelenségek BASIC-ben

Hozzászólás Szerző: Asimo » 2012.05.16. 13:09

Pgyuri írta:ezek mindig nagyon tetszenek
Köszi :)
Pgyuri írta:Választhattak volna olyan megoldást, ahol az összehasonlítást egy adott belső tizedes hosszig végzik el, de akár más trükkel is, de az, hogy egy sima IF A=1.3 THEN utasításhoz szakmai egyetemi végzettség kelljen, kissé banális.
Nekem ez a "tizedesre kerekítés az összehasonlítás előtt" két dolog miatt nem tetszik:
- Kettes számrendszerben van ábrázolva, ezért abban a kerekítés triviális, de tizes számrendszerben már sok átalakítással jár, ami teljesítmény-vesztés.
- Milyen alapon tudná megmondani a nyelv fejlesztője, hogy meddig kerekít, hogy dönti el, az egyes felhasználóknak milyen pontosság a megfelelő. Persze működhetne azon az alapon, ahogy ki is jelzi, de ez is belefut ebbe a két problémába (plusz idő, pontosság).

Ezért én inkább arra hajlok, hogy a BASIC kézikönyvben kellett volna ezeket tisztázni. Mert a megoldás (BASIC nyelven) nem bonyolult, ha értjük mi van mögötte, akkor nem kell elmenni az egyetemi szintig (ábrázolás stb). Ráadásul, ha ezt mondjuk 82-ben már sulykolták volna, akkor okosabbak is lettünk volna. :)

Amúgy tovább bonyolítja a helyzetet az, hogy a 65535-nél nagyobb egész számokat is lebegőpontosan ábrázolja a gép, így nagyon nagy egész számoknál is előjöhet ugyanez a probléma.

Avatar
Pgyuri
Speccyalista
Hozzászólások: 485
Csatlakozott: 2012.01.06. 13:34

Re: Fura jelenségek BASIC-ben

Hozzászólás Szerző: Pgyuri » 2012.05.16. 14:16

Üdv,

A számítástechnika "hőskora" a félmegoldásairól volt híres és ez tulajdonképpen minden téren tapasztalható, hardver és szoftver oldalról, azonban míg a hardver oldal teljesen érthető, mert a fizikai anyagi költségek jelentősen befolyásolták a tervezők döntéseit, addig a szoftver oldalon található kompromisszumok (vagy inkább lustasági, kényelmi megoldások) csak bajt csinálnak.

Milyen logika alapján találta ki a számábrázolás ezen 2 byte-os alkalmazását egész számoknál a programozó ? Természetesen a sebesség miatt, hiszen villámgyorsan lehetett vele számolni. De vajon nem gondolta volna, hogy ha amúgy is 5 byte-ot hagyott egy szám tárolására a képi alakon túl, akkor oda simán befért volna a 4 byte-os egész tárolás is, amely jelentősen növelte volna az egész számok kezelésének pontosságát.

Ha pedig a valós számokkal végzett összehasonlító műveletnél nem volt tisztában a taglalt hibával, akkor szégyellje magát, ha pedig igen, akkor saját magának kellett volna megoldást kínálnia rá, akár külön függvény elkészítésével, ráterelve ezzel a felnövő, okosodó generációt, hogy ezt a problémát bizony így kell megoldani.

Mindenesetre szerintem nem szabadott volna hagyni két valós szám összehasonlítását szintaktikailag így, mert kiszámíthatatlan működést eredményez.

Pgyuri

Avatar
leslie.wss
Speccyalista
Hozzászólások: 75
Csatlakozott: 2012.01.18. 23:36

Re: Fura jelenségek BASIC-ben

Hozzászólás Szerző: leslie.wss » 2012.06.13. 14:27

A lebegőpontos számok összehasonlíthatósága még manapság is problémás. Pl. Java nyelvben sem szabad simán csak ==-val összehasonlítani két ilyen számot (változót), mert igencsak bizonytalan lesz az eredmény.
Mindez persze a szám memóriában való tárolási módjának "tökéletlensége" miatt van, hiszen nem tud pontosan végtelen tizedeseket tárolni. Így a számolások mindig elcsúsznak egy picit, az eredmény a műveletek típusától, sorrendjétől stb. erősen változik.

Természetesen lehetne 2, 4 vagy 8 byte helyett mondjuk 65536 byte-on tárolni a számot, akkor biztosan pontosabb lenne az érték tárolása, de a kezelése meg lényegében lehetetlenné válna.

http://randomascii.wordpress.com/2012/0 ... 2-edition/

Válasz küldése

Ki van itt

Jelenlévő fórumozók: nincs regisztrált felhasználó valamint 1 vendég