Názory k článku Programovací jazyky používané na platformě osmibitových domácích mikropočítačů Atari

Co je to za algoritmus na výpočet pí?

1010 PI=4
1020 FOR J=3 TO N+2 STEP 2
1030 PI=PI*(J-1)/J*(J+1)/J
1040 NEXT J

To je založeno na Wallisově sérii (Wallis product). Většinou se to zapisuje formou sumy, toto je úprava pro iterativní výpočet.

Zrovna nedavno jsem videl moc hezke video kde byla probrana historie vypoctu Pi. Jak L von Ceulen pouzil v podstate Archimedovu metodu bisekce n-uhleniku a jak magor pocital Pi toutou metodou tusim > 20 let svyho zivota aby se dostal k mnohouhelniku s 2^62 stran, coz mu stacilo na pi s presnosti 35desetinych mist.Jeste nekdo potom to spocital na 38 a pak prisel sekac Newton a zadupal von Ceulena do prachu zpomeni ;-) a pi se podle Newtona pocita dodnes. Jinak moc dekuji za tyhle clanky, vraci me to do doby meho mladi s Atari800XE, AtariST a do dob kdy assembler nebylo "sproste" slovo ;-) 6502 a 68000 byly uzasny CPU.

Asi jsem viděl úplně stejné video - někdy prostě algoritmus na Youtube napoví relevantní věci :-)

Bylo tam taky to, že Newton na to přišel, když byl zavřenej doma kvůli lockdownu, protože v Británii byl zrovna mor?

A díky!

já bych byl v klidu, protože kdo říká, že assembler je "sprosté" slovo, tak minimálně nemá v IT pořádný rozhled.

Možná už se "strojově orientované jazyky" neučí? To by minimálně na technicky zaměřených školách (tedy VUT/ČVUT) bylo dost tragické (IMHO).

(btw hele co jsem našel za starožitnosti:
http://www.fit.vutbr.cz/~arnost/vyuka/soj/index.html.cs
http://www.fit.vutbr.cz/~arnost/vyuka/sj2/index.html.cs)

Z tohole clanku mohl byt cely serial. Jestli to teda nebude pokracovat kompilatory a jazyky treba pro ZX. Kdyz vidim ty assemblery a debuggery tak myslim ze takovy Prometheus a DevastAce byly luxusni prostredi.

O Speccym skutečně podobný článek připravuju. Budou to tedy informace především "z druhé ruky" (protože jsem atarista), ale dva jazyky jsem si i na speccym vyzkoušel a vůbec to nebylo špatné!

Velký problém většiny BASICů je v tom, že nedokážou pracovat s lokálními proměnnými. Ono je fajn když basic umí DEF FN (Spectrum) nebo tady PROC, ale to je pořád jen pojmenované "něco", co není izolováno od zbytku programu.

Na Spectru to umí ZX BASIC, ale to je cross compiler, takže tam jsou pochopitelně větší možnosti.

Nojo to je pravda, to je totiž nevýhoda všech těchto malých BASICů, které se musejí vejít do ROM o kapacitě 8 kB a někdy jen 4 kB. Prostě do takto malé kapacity se něco lepšího cpe hodně těžko. Kdo měl k dispozici více ROM, například BBC BASIC pro BBC Micro, to už bylo něco jiného.

Ale zrovna v případě Atárka z toho návrhu úplně čiší to, že jde o mikropočítač postavený na čipech určených pro herní konzoli. Minimálně POKEY a CTIA/GTIA takto byla navržena (náhrada za Atari VCS/2600 s TIA) a když se udála revoluce domácích mikropočítačů, tak k tomu přilepili ANTIC (namísto návrhu zcela nového čipu pro PMG), dodali OS (kupodivu povedený až promakaný - viz práce se zařízeními) a BASIC - a namísto vylepšené herní konzole tady byl pěkný mikropočítač s dobrým poměrem cena/výkon.

Zkráceně - ten BASIC tam dodali, ale nebyl to středobod, okolo kterého se to celé točilo (v porovnání se zmíněným BBC Micro).

jo no, MicroPython by tam asi portovat nešel, co jsem se díval na požadavky, ale čistě teoreticky taková Lua ano, když jede i na malém ESPP.

No to by asi bylo na hraně, ale pro atárka se 128kB nebo s 320kB (RAMdisk) by to asi bylo hratelné. Jazyky, které se používají dneska pro novou tvorbu, jsou však v naprosté většině transpřekladače - buď transassembler (dema, arkády) nebo FastBASIC (dema, kde se počítá délka kódu).

Hmm když o tom přemýšlím, tak aspoň interpret bajtkódu Luy by šel. Jsou tam sice nějaká zvěrstva (tabulky, metatabulky, https://www.root.cz/clanky/pohled-pod-kapotu-jvm-porovnani-bajtkodu-virtualniho-stroje-javy-s-lua-a-pythonem/#k07) ale asi by to šlo. Navrhnu na dalším atari setkání :-)

To pre Atari zacne konecne programovat aj Frantisek Fuka.
;o)

Aha tak pro atari asi taky něco podobného existuje:
https://github.com/dmsc/tbxl-parser/#parameters-and-local-variables-for-proc

Navíc nebyla mantisa uložená binárně, ale používal se kód BCD, ...
... a přesnost ani rozsah hodnot není tak vysoký, jako při použití binárního kódu.
Nebudu rozporovat, ale tehdejší "referenční" výpočet 10,2-10,1 zvládlo Atari spočítat bez chyby na rozdíl od ZX Spectra či PMD-85.

Ano, to je přesně dáno použitím decimálního základu pro exponent a ne základu binárního.

Dneska se všude používá binární základ exponentu (podle IEEE 754), takže atárko je vlastně jeden z mála počítačů, co ten výpočet zvládnou bez chyby. Viz například pokus v Pyhtonu, co počítá s typem double:

>>> 10.2-10.1
0.09999999999999964

PS: takže vlastně z pohledu použití Atárka to byla dobrá volba - byl to počítač pro běžné lidi, ne pro odborníky na numerické výpočty.

Jelikoš běžnej smrtelník je zvyklej na desítkovou soustavu a počítá hlavně prachy, tak asi jo.

Postgres

postgres=# select 10.2-10.1;
┌──────────┐
│ ?column? │
╞══════════╡
│      0.1 │
└──────────┘
(1 row)

to tedy počítá v NUMERIC že?

Ano. Numeric je default pro číselné desetinné konstanty.

Vlastně jsem nebyl přesný, protože typ DECIMAL má i VB. A opět - celkem logicky pro oblast, pro které je tento jazyk určen; ponechme teď stranou, že je to kvůli různým "přílepkům" zvěrstvo.

Já jsem měl VB docela rád - na tlustého klienta pro databáze to bylo docela šikovné. Člověk se ale musel smířit s určitými omezeními a používat určitý styl programování. Nesměl si moc vymýšlet - a některé vynálezy od MS jako inteligentní db komponenty byly peklo.

Na co vzpomínám s hrůzou byl vbscript. Byl to brutálně zkriplenej VB, ale díky němu se dala automatizovat MS Exchange nebo Outlook (bez náhrady). To bylo zvěrstvo. Na Linuxu byl Perl 4 - a Windows měla vbscript. Potom už VBA byl úplně jiný level, ale za krvavé peníze. vb.net už pak byl zdarma.

Já s VB naposledy dělal v VB6, to byla taková stálice (a ve státní správě jsem na něm udělané appky viděl ještě docela nedávno - pořád tam snad řeší, jak instalovat vbrun60.dll do nových windows :-).

Ona tam fakt byly zvěrstva, například přepínač pro volbu, jestli pole číslovat od nuly nebo od jedničky (OPTION BASE ...). A když se sešlo víc programátorů ... my céčkaři číslující od nuly a další zvyklí číslovat od jedničky, nebo někdo řešil komunikaci mezi VB a nativní částí, to už začínalo peklo.

vbscript - souhlas!
Kdysi v jedné firmě, kde jsem dělal, měli napsanej docházkovej systém ve vbscriptu a to nechceš vidět :-)

Vedly se diskuze, jak s float nakládat, ale nakonec to pro ty, kteří to potřebují "přesněji" zůstalo na decimal. Asi pro to, že je to zažité a proti pár metodám floatu má Decimal těch metod přes 50.

Takže:
>>> from decimal import Decimal
>>> Decimal("10.2")-Decimal("10.1")
Decimal('0.1')

Já bych dal decimal všude by default jako to bylo na Atari. Protože jinak:

(10.3 - 10.2) == (10.4 - 10.3)
false


Je to balanc na straně potřeb a náročnosti na zdroje.
Podobně můžete řešit, že znaky by měly být kódované ne přes UTF8, ale přes UTF16 nebo UTF32.

Když to programujete, tak byste měl tato omezení znát, stejně jako je třeba znát omezení Decimalu a dalších datových typů.

8. 4. 2021, 12:51 editováno autorem komentáře