Výpočet plochy pláště válce

Úvod

Ukázka výpočtu plochy pláště válcového tělesa si v žádném případě neklade za cíl poučit potenciálního čtenáře těchto řádků o vybraných kapitolách prostorové geometrie. Slouží výhradně k demonstraci převahy systému RPN nad systémem algebraickým (bez ohledu na to, zda jej různí výrobci označují zkratkami AOS, AOL, ALG, nebo i jinak). Převahou v předchozí větě je především myšlena efektivita s důrazem na minimální nároky na paměť a vlastně i rychlost provádění. Efektivní využití možností RPN stacku ve spolupráci s registrem LASTx rozhodně neučiní program přehlednějším. To však nemůže být prvoplánovým cílem žádného autora jakéhokoliv programu. Přehlednost a srozumitelnost je věcí dokumentace, ne strojového kódu. Prováděný kód musí v maximální míře jít na ruku sekvenčnímu automatu, který ho provádí. Je lhostejno, je-li tím automatem počítač, kalkulátor, nebo nějaký jednoduchý řadič.


Zadání

Ukázkový program (ve dvou variantách řešení) vypočítá plochu pláště válce použitím vzorce

S  =  2 π r²  +  2 π r h

kde

r  je poloměr základny,
h  je výška tělesa.


Řešení 1

Na stránkách 126 až 128 manuálu kalkulátoru HP-41C (k nahlédnutí zde) je v sekci "Program Editing" (která následuje bezprostředně po "Simple Programming") pro ukázku použit právě tento matematický příklad. Program je tam - pro názornost - řešen opisným stylem: jednotlivé kroky programu přesně kopírující matematický zápis, pouze transponovaný do RPN. Maximální názornost je obětí za úspornost řešení - větší počet programových kroků doplněný potřebou paměťového registru pro uchování hodnoty poloměru základny.

Následující tabulka obsahuje výpis programu, který lze takřka beze změn provozovat na všech kalkulátorech obdařených RPN logikou. Čím by se jednotlivé implementace mohly mezi sebou lišit je pouze definice návěští (zde LBL TAREA) a instrukcí konce podprogramu (zde END). Ke každému programovému kroku (řádce programu) je znázorněn obsah registrů RPN stacku pro snadné pochopení činnosti již tak extrémně jednoduchého programu.

ADDRCODEXYZT
01 LBL TAREA r h    
02 STO 01 r h    
03 X↑2 r² h    
04 PI π r² h  
05 × π r² h    
06 2 2 π r² h  
07 × 2 π r² h    
08 X<>Y h 2 π r²    
09 RCL 01 r h 2 π r²  
10 × r h 2 π r²    
11 PI π r h 2 π r²  
12 × π r h 2 π r²    
13 2 2 π r h 2 π r²  
14 × 2 π r h2 π r²    
15 + S      
16 END S      

Použití programu je následující:
50_ výška tělesa...
ENTER ...do Y-registru
11_ poloměr základny v X-registru
XEQ TAREA spuštění programu
4216.0173  zobrazený výsledek


Řešení 2

Kromě v úvodu zmíněných triků nabízených technologií RPN jsou v tomto řešení užity ještě dvě finesy, které již tak směšně jednoduchý výpočet dále zjednoduší:

  1. Oba součiny (které v součtu dají výsledek) obsahují výraz 2 π r. Počítat tento mezivýsledek pouze jednou se přímo nabízí.
  2. Výraz 2 π r je převeden na tvar π (r + r).
Upravený vzorec má tedy tuto podobu:

S  =  π (r + r) (r + h)

Výpis programu pro Řešení 2 zachycuje tabulka na následujících řádcích. Platí zde vše co platilo v případě Řešení 1. Pro větší rozmanitost je zde použita notace kalkulátoru HP-35s. Pozornému čtenáři však neujde, že to přínáší pouze změny formální až kosmetické: rozdíl je pouze v instrukcích začátku a konce podprogramu (LBL C a RTN) a stylu číslování řádků programu.

ADDRCODEXYZT
C001 LBL C r h    
C002 + r + h      
C003 LASTx r r + h    
C004 ENTER r r r + h  
C005 + 2 r r + h    
C006 × 2 r (r + h)      
C007 π π 2 r (r + h)    
C008 × S      
C009 RTN S      

Použití programu je pochopitelně stejné jako v případě Řešení 1. Pouze sekvence spuštění programu XEQ TAREA se mění na XEQ C.

Pozn.: K předloženému řešení lze vznést námitku: "Proč se hodnota 2 r počítá formou (r + r)?" Popravdě řečeno, důvod k tomu žádný není. Snad jedině ohled na HP-35s by mohl tento postup ospravedlnit. Konstanta v programu je u tohoto kalkulátoru ukládána v ASCII tvaru a v průběhu provádění programu je pokaždé převáděna do binární formy. Konstrukce použitá v ukázce tuto drobnou nevýhodu eliminuje. Naopak v případě modelu HP-32sII je to zcela jedno: konstanty jsou v programu uloženy v binárním tvaru (ty v rozsahu 0 až 254 dokonce v délce 1.5 byte jako prostá instrukce, ostatní zaberou 9 byte). Do podoby textové (tvar ASCII) jsou převáděny pouze pro potřeby uživatele při listování programem. Inkriminované řádky tedy klidně mohou mít tuto podobu:

ADDRCODEXYZT
C04 2 2 r r + h  
C05 × 2 r r + h    

Řešení 3

Navzdory tvrzení z kapitoly Zadání, že nabízené varianty řešení jsou dvě, následující tabulka s instrukcemi ukazuje program pro kalkulátor TI-57, tedy stroj používající AOS. Byl záměrně upřednostněn před TI-58/59 z důvodu sdružování stisků kláves do jednotlivých kroků programu (Instrukce LBL 0 i STO/RCL 5 zabírají vždy pouze jeden programový krok, vyšší modely kalkulátorů na to spotřebují kroky dva).

ADDRCODECOMMENT
00  86 0 Lbl 0  
01  43 ( Zamezení uzavření započaté aritmetické operace
02  32 5 STO 5 Uložení r do pracovního registru
03  55 ×  
04  02 2  
05  55 ×  
06  30 π  
07  55 × Mezivýsledek (zobrazuje display): 2 π r
08  43 (  
09  33 5 RCL 5 Vyzvednutí r z pracovního registru
10  75 +  
11  81 R/S Pozastavení programu pro vstup hodnoty h
12  44 ) Mezivýsledek (zobrazuje display): (r + h)
13  44 ) Výsledek (zobrazuje display)
14 -61 INV SBR  

Použití programu je následující:
11 poloměr základny
SBR 0 spuštění programu
50 výška tělesa
R/S pokračování běhu programu
4216.0173  zobrazený výsledek


Slovo závěrem

Co říci? Krom toho, že převaha RPN nad AOS byla odhalena v celé své nahotě, snad není co dodat. Pravděpodobnost, že efektivnější kód by mohl být napsán pro algebraický systém je prakticky nulová. I při použití zjednodušeného vzorce z Řešení 2 bude sled programových kroků vždy dramaticky vyšší a použití paměťového registru pro uložení mezivýsledku je nezbytné.

Dá se očekávat, že zastánci AOS nebudou ochotni uznat "zdrcující porážku", kterou jejich oblíbenému systému nadělil systém RPN. Argumentem jim bude námitka: "Co dokazuje úspora těch několika málo instrukcí při výpočtu jednoduchého vzorce?". Že je takový argument nutno brát vážně, je zcela mimo diskuzi. Nabízí se však ještě jeden úhel pohledu: "Když je použitím RPN výpočet triviálního vzorečku zkrácen na polovinu, co to teprv musí udělat s rozsáhlým programem?"...