OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů
Právě je 19 črc 2018, 04:50

Všechny časy jsou v UTC + 1 hodina




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 5 ] 
Autor Zpráva
 Předmět příspěvku: Chyby ROM/BASICu
PříspěvekNapsal: 22 led 2017, 17:50 
Offline
Kecálek

Registrován: 18 říj 2014, 22:10
Příspěvky: 173
Has thanked: 12 times
Been thanked: 41 times
Aby sme ten SAM BASIC len nechválili, tak tu mám jeden príklad, ktorý ukáže hneď dve chyby:
Nepresná nula a taktiež mal cyklus prebehnúť ešte raz pre a=0.5 .
Příloha:
simc0001.png
simc0001.png [ 2.87 KiB | Zobrazeno 1465 krát ]


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Chyby ROM/BASICu
PříspěvekNapsal: 23 led 2017, 09:12 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 11 čer 2013, 14:27
Příspěvky: 1428
Has thanked: 909 times
Been thanked: 242 times
SAM BASIC bohužel vykročil ve šlépějích spectráckého, taky nebyl při uvedení produktu na trh dokončen...

Chyb je více, např.
http://www.worldofsam.org/node/69

Moje zkušenosti:
- systém nezpracuje velký počet (stovku?) LABELů
- obarvované instrukce či názvy procedur (CTRL+I, CTRL+P) občas způsobí různá chybová hlášení

Chyby u basicového kalkulátoru jsou na pováženou, vždyť se autor prý poučil z chyb spectrácké romky
a matematické rutiny jej živily nejen na škole ale také ve firmách (psal grafické a 3D knihovny pro nové herní konzole - PS a spol.)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Chyby ROM/BASICu
PříspěvekNapsal: 24 led 2017, 12:53 
Offline
Pan Štábní

Registrován: 22 kvě 2013, 20:14
Příspěvky: 1882
Bydliště: Bratislava
Has thanked: 208 times
Been thanked: 346 times
Ked chcete mat exaktne presne vysledky, nepouzivajte floating-point format cisel. Floating point vzhladom na svoje kodovanie z principu nevie presne ulozit hodnoty ine ako 2^N (N je cele cislo) a ich sucty. Napriklad hodnota 0.1 predstavuje v dvojkovej sustave nekonecny "dvojtinny" rozvoj, pretoze sa neda vyjadrit suctom konecneho poctu celociselnych mocnin dvojky a tym padom sa ani neda zakodovat exaktne presne. A ked sa pocita s viacerymi nepresnymi hodnotami (napr. 0.1 + 0.1) tak nepresnost narasta.

Ak chcete aby vam aritmeticke rutinky vysledky automaticky zaokruhlovali na (v desiatkovej sustave) najblizsie rozumne cisla, potom sa mozete lahko dozit ineho druhy chyby - napr. vysledok operacie 1.00000001 - 1.00000001 sa zaokruhli na najblizsie "rozumne" cislo, a tym je nula.

Pokial pozadujete desatinne cisla s exaktnou presnostou, treba pouzivat fixed point aritmetiku. Kedze v beznych basicoch (napr. ZX) nieco take nemame, da sa to obist tak, ze vsetky hodnoty na vstupe vynasobime desiatimi (stomi...) tak aby sme nasledne pocitali len s celymi cislami, a na vystupe ich tou istou "bulharskou" konstantou zase vydelime. Presne takto pracuju aj rozne tabulkove programy (Excel...) pri nastaveni typu cisla na "currency" - tento format je urceny napr. na finacne vypocty, kde treba garantovat exaktnu presnost.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Chyby ROM/BASICu
PříspěvekNapsal: 16 čer 2018, 13:58 
Offline
Kecálek

Registrován: 18 říj 2014, 22:10
Příspěvky: 173
Has thanked: 12 times
Been thanked: 41 times
SCjoe píše:
- systém nezpracuje velký počet (stovku?) LABELů
No tak som zrovna na to narazil a LABEL-ov som mal tak do 30.
Nepomohlo ani pridať pamäť pre basic, ale nevzdal som sa a tak som namiesto LABEL-ov vytvoril premenné
(no oni sú to vlastne konštanty) a pred každý LABEL som dopísal REM a ide to.
Pre úplnosť ešte dodám, že si s tým neporadí príkaz RENUM, ale to mi nevadí.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Chyby ROM/BASICu
PříspěvekNapsal: 17 čer 2018, 08:15 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 11 čer 2013, 14:27
Příspěvky: 1428
Has thanked: 909 times
Been thanked: 242 times
Antony/DTA píše:
No tak som zrovna na to narazil a LABEL-ov som mal tak do 30.

Je to různé. Asi záleží na celkovém obsazení paměti procedurama a využívání smyček s WHILE, DO, UNTIL, LOOP a taky na délkách pojmenování.
Kód:
1 PRINT "Generator LABELu..."
2 FOR x=1 TO 111
3 PRINT at 1,0;x
4 KEYIN STR$ (x*2+100)+" LABEL l"+STR$ x+": PRINT "+STR$ x+": STOP"
5 KEYIN STR$ (x*2+101)+" REM xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
6 NEXT x
7 CLS : STOP
8 REM ---------------------------------X

Samík má jen část systémových proměnných definovanou třemi bajty (stránka,offset), zbytek si nese "zátěž" osmibitového systému do max. 65535 a vše důležité cpe do stacku, který vznikl na místě spectrácké obrazovky od 16384 do cca 19000, resp. s buffery až přes 20000.
Lze získat více místa. Mám upravenu ROM s posunutým začátkem basicu, klidně až na 32000. Získá se tím např. dalších pár K pro prográmky, které se dosud cpaly do basicového stacku.
Rozumné je jít ale jen na 27000, aby byly spustitelné i programy, které si ponechaly manýry ze Spectra a nastavují brzký konec basicu a start stroj. kódu kupř. od 30000.
Další krok, posunutí basicových proměnných a bufferů výš přes původní počáteční adresu sam basicu (23755), se mi zatím úplně v ROM zmanipulovat nepovedlo a ještě je velký problém s programy, které nepoužívají systémový přístup s SVAR, ale natvrdo poukují.


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 5 ] 

Všechny časy jsou v UTC + 1 hodina


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 1 návštěvník


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz