Home


Aktualizováno 18.11.12 09:55:52
*******************************
********************
17.11.2012
Doplněno číslo verze pro Win 8 a to číslo 15. Zároveň upozorňuji na
obecnější ".test $os", které nepodléhá časové erozi.
********************
13.02.2012
Problém s goniometrickými funkcemi jsem nakonec odhalil. Prekročení
1 pro acos nastal někdy pouze v případě, že souřadnice zeměpisné
délky a šířky u dvou různých objektů byly totožné. Po vyloučení
těchto případů z obecného výpočtu vzdálenosti problémy zmizely.

Původní nezaokrouhlování ve wr571 při přechodu od double real čísel
k DD formátu vedlo k tomu, že vypočtená vzdálenost totožných souřadnic
byla kolem 10-15 metrů místo 0 metrů.

Nicméně od WR71 jsem zvýšil přesnost sin a cos z 10 míst na 15 míst
(výsledek v API double real byl a je na cca 16 míst) a zjemnil
počet desetinných míst při přechodu od double real k DD z původních
10-6-0 na 16-14-12-10-8-6-0. A ještě dojde k zaokrouhlení.
********************
08.02.2012
Dnes jsem si pro srovnání vygeneroval WinXP 64 bit a testoval na úloze
z ČHMÚ. Pod wr58 64 bit to trvalo 12 minut, na WinXP 32 bit a WR58 32 bit
to jelo 15 minut (vypnul jsem cool and quiet). Na 64 bitovém systému
WR571 32 bit jela stejně jako na WinXP 32 bit a 20 minut.
*******************
07.02.2012
Dnes jsem hledal příčinu odchylných výsledků mezi WR571 a WR58 v oblasti
goniometrických funkcí. Chod pod WR571 proběhl "tiše", chod pod WR58
14x vypsal, že parametr acos není v intervalu -1,1. Po jisté době
jsem zjistil, že sin(x) pro jité x dává na konci 5 pro WR571 a 6 pro WR58.
Pak jsem dospěl k místu, kdy vypočtenou hodnotu z API ve tvaru real,
převádím do integer a do WR. Zjistil jsem, že xxxxxx5.9 se převede na 5
a ne na 6 jak je tomu ve wr58. U převodu tedy chybí zaokrouhlení.
Po úpravě wr571 byly výsledky totožné a wr571 též neběžela "tiše".

Na návrh ing. Jirsy, jsem od wr571 doplnil překročení hodnoty 1 nebo
podkročení -1 převodem na 1 resp. -1 s výpisem původní hodnoty. Tak
lze rozlišit zaokrouhlovací chyby - zde např. 1.0000000001000 a eventuálně
logické chyby - třeba 35.00000000000.

Rovněž jsem zpřesnil koeficienty pro převod stupňů na radiany a zpět
na 17 cifer - přesnost goniometrických funkcí. Suma sumárum, nemusí
být tedy výsledky po úpravě zcela totožné jak v původní WR571.
*******************
Po reorganizaci adresářů přestalo být cca před 14 dny demo WR58 funkční.
To jsem dnes napravil.
*******************
Po napsaní předchozího příspěvku jsem zjistil, že init5w pro wr571
mám nastaveno A8. Protože procházelo AR ve WR58 s 19 ciframi, nastavil
jsem A5 a znovu výpočet projel. Výsledek je 23.5 minuty. Takže
úspora A5 (na 20 cifer) a A8 (na 32 cifer) je cca 0.5 minuty. To je
dáno tím, že násobení a dělení se automaticky provádí s ohledem
na počet platných cifer, takže operace se příliš neprodlouží.
******************
04.02.2012
Na základě složitého výpočtu se statisíci aritmetickými operacemi
s vysokým počtem platných cifer včetně záporných a kladných čísel
a funkcí jsem doladil aritmetiku C2 - největší problémy a D2
minimum zásahů. Konečně mohu konstatovat, že cca dvouměsíční
práce na přelomu roku 2010/2011 se projevila v rychlosti výpočtu.

Ve wr571 musila být nasazena přesnost AR->A6 a chod trval 24 minut.
Ve wr58 vystačím s AR (C2 aritmetika) a chod trvá 17 minut.
Ve WR58 AR->A6 počítá 22 minut.

Příklad dodal RNDr. Květoň z ČHMÚ.
******************
15.01.2012
Podařilo se protlačit syntézu XML. Vše i příklady viz

www.redap.cz/wr58dok.zip
*******************
10.01.2012
Vzhledem k poměrně náročnému konci roku z pohledu wr571 - dostal
jsem na stůl celou řadu problémů dřímajících ve WR i řadu verzí,
jsem nedokončil syntézu RDA do XML.

Přesněji, při psaní dokumentace a tvorbě příkladů jsem narazil na
řadu věcí, které buď "uhnily" nebo nikdy nefungovaly. Proto již
v rámci dekompozice jsem musil provést řadu doplňků a úprav.

Souhrný popis nové aritmetiky a dekompozice XML najdete na
www.redap.cz/wr58dok.zip

Syntéza RDA do XML tak zůstala v rámci WR58 nedokončena. Do konce
1. kvartálu bude WR58 jako plné demo - WR58D.ZIP a v případě
zájmu od majitelů paušálu WR 2011, zašlu WRSET58.EXE.

V průběhu roku 2012, doufám, syntézu dokončím ve formě WR581.
*******************
Nyní se budu snažit to co jsem spáchal ve WR58 také solidněji
popsat pomocí příkladů.
*******************
30.11.2011
Do instrukce XML doplněn druhý parametr se jménem výstupního souboru
- dosud natrvro xml.rda. Např.

%xml
!
book.xml
book.rda
%
inf book
pip book.rda/df

a režim rs - vystupni soubor obsahuje RSD a df - výstupní soubor
obsahuje RDF.
*******************
19.10.2011
V dynamické definici je též možno za úvodní závorku umístit &
jako příznak rozlišování velkých a malých písmen identifikátorů.
*******************
Rozchozeno založení tabulky s jednou prázdnou větou s hierarchickou
strukturou:

_openw xml <jméno.RDF>
_write xml 0
_close xml
***************
18.10.2011
Protože XML je tzv. "case sensitive" pro jména tagů, bylo třeba
zavést příznak & v RSD, vypínající pro konkrétní tabulku převod
identifikátorů na první velké a další malé písmeno. Např.

sh.rda!&
DPHSHV
VetaD
d_poddp^ re 10 0
mesic^ re 2 0
dokument^ re 3 0
k_uladis^ re 3 0
pln_poc_celk^ re 3 0
poc_radku^ re 2 0
poc_stran^ re 1 0
rok^ re 4 0
shvies_forma^ re 1 0
suma_pln^ re 7 0
$
***************
17.10.2011
Platnost dema WR58 prodloužena do 31.12.2011.
***************
18.09.2011
Po dlouhém úsilí se podařilo protlačit rozklad XML struktury
na jednotlivé RDA relačního typu a pak opačný proces,
z dekomponovaných RDA vytvořit XML.RDA a pak XML strukturu
totožnou s původní strukturou. Příkládek je na
www.redap.cz/xmlrdaxml.zip
******************
Podařilo se udělat instrukci EML, konvertující stromové
RDA do XML.

_mode di:50.
del xml.rda
%xml
!
i002.xml
%
%eml
!
xml.rda
pom.xml
%
edi pom.xml

Příklad viz www.redap.cz/eml.zip
********************
14.07.2011
Dost dlouho jsem se trápil s obecnou analýzou XML a automatickou
tvorbou "RDF" a "RDA". Snad se to konečně podařilo. Zkuste na nějakém
svém XML spustit buď:

_mode di:50.
del xml.rda
%xml
q5:81.
c:\tmp\xml\<Název>.xml
%
inf xml

Dstanete celé XML jako jednu větu nebo

_mode di:50.
del xml.rda
%xml
sk,q5:81.
c:\tmp\xml\<Název>.xml
<identifikátor skupiny>
%
pip xml.rda/df
inf xml

Dostanete tolik vět, kolikrát se v XML skupina
vyskytuje.

Všechny položky se zatím detekují do "RDF" jako RE.
********************
02.07.2011
Pokouším se přímo strukturu XML převést do stromového RDA. Narazil jsem
na licenci, kdy nejen list, ale i uzel nese hodnotu, což je v rozporu
s mou koncepcí. Konkrétně

<key numb="5">123456</key>

V tomto případě jsem byl nucen opatřit hodnotu formálně identifikátorem
Ghod a převést na

key
numb:"5"
Ghod:"123456"
*******************
Další instrukcí je TRS - třídění skupin ve větě.

%trs
uziv
fakt.
\kcs-.
%

Ve struktuře uziv máme u uživatelů všechny jejich faktury v podskupinách
fakt, které se ve větě konkrétního uživatele vyskytuje obecně vícekrát.
My si přejeme, aby jako první skupina (faktura) se uváděla ta, která má
nejvyšší fakturační cenu. Třídící klíč musí být ze skupiny fakt!!!

%tri
uziv
fakt\kcs-.
%

Tohle pak srovná věty podle prvního výskytu hodnoty kcs ve větě,
takže první bude zákazník, který někdy zaplatil nejvyšší hodnotu kcs.
****************
11.06.2011
Jednak protlačena úprava ZUZ. Přepínačem ex a uvedením jména skupiny
můžete udělat opačnou operaci k INS - např. jste přidali k uživatelům
všechny faktury, které kdy zaplatili a pomocí ZUZ+EX zase faktury
vyjmete a uložíte je samostatně:

%tri
\e\uziv
pc.
\e\prodej
pc,cfak.
%
cpo uziv <*XML struktura Uziv+Prodej *>
%zuz
\e\uziv
uziv.rdf uziv <* uziv jiz XML *>
;
//
%
%ins
sk.
uziv
\e\prodej
uziv u
pc. <* Podle PC. *>
fakt. <* Přidávej faktury do skupiny FAKT. *>
//
%

Inverzní operace:

%zuz
ex.
uziv
\e\prodej p
fakt. <* Při parametru EX se uvádí skupina, která se má exportovat*>
;
//
%
*****************
02.06.2011
Podařilo se navrhnout a syntakticky i sémanticky protlačit tiskový blok
na "HTML" - první RSD druhé tbn.cmd

ZAM!
ZAM
reldp
yer re 4 0
typ re 2 0
client
bno re 10 0
name
sur re 10 0
fir re 9 0
adr
cit re 9 0
str re 10 0
num re 4 0
$

%tbn
skol\zam
tt:1.
Nazdar!
0 72
1 0 1
!
$
.bpr
.pr(
xt "Reldp:";zam\reldp\yer;\typ r;
zam\reldp\client(
.se(\adr\cit "Hodonín" )
xt "Číslo:";\bno m 10;\name\fir m 0;\sur m 0;xt "Bytem:";\adr\cit m 0;\str m 0;\num m 0;xz r;)
xt "Reldp:";zam\reldp\yer;\typ r;
)
.epr
$
%

SOFTWARE-REDAP WR58 02.06.11 13:32:39 List 0001

Nazdar

Reldp: 2005 01
Číslo: 6961154299 Drahomíra Ševčíková Bytem: Hodonín Očovská 28
Číslo: 5761141859 Eva Kašná Bytem: Hodonín Konečná 3
Číslo: 5761141859 Eva Kašná Bytem: Hodonín Konečná 3
Číslo: 7257291646 Petra Špačková Bytem: Hodonín 1 Brandlova 135
Číslo: 486102415 Zdenka Brennerová Bytem: Hodonín Muchova 9
Reldp: 2005 01


přitom client je ve větě několikrát, ale my budeme tisknout pouze ty, kteří
mají v adrese město Hodonín. Ten tisk ze skupiny zam\reldp\client je vyjádřen
závorkami a za závorkou může být uvedena podmínka.

Pokud bychom závorky nepoužili, vytisknuly by se pouze údaje prvního
clienta ve větě.
****************
20.05.2011
Na školení v Plzni se dohodlo postupné zdokonalování stávající WR57,
tj. odstraňování problémů a nesymetrií, které vznikly i před mnoha
lety a zachování funkčnosti i na novém hardware a operačních systémech.
Toto považovala většina účastníků za klíčové - nikoliv doplňování
dalších funkcí.

Proto jsem dnes do stávající WR57 provedl formalní změny ve shodě
s WR58, abych snížil diference mezi těmito verzemi.

Na základě těchto dnešních zdrojů jsem sestavil znovu WR57 a dále bude
z nich vznikat i WR571, jako samostatná verze.
***************
Ing. Mašek dává k nahlédnutí svoje dílko pro vytvoření dvoustránkového
přiznání k DPH do PDF souboru. Původně to měl řešeno jako dvě sestavy
pro každou stránku a pak zjistil, že tudy cesta do PDF nevede. Viz
www.redap.cz/dph11.zip

Pokud totiž PIPem slepíte dvě sestavy s obrázky a LST to budete
chtít vytisknout, tak to nedopadne dobře, protože v souboru je absolutní
bajtová adresace obrázku v souboru. Slepením se tak pravděpodobně
odkaz na druhý obrázek posune někam do první strany.
***************
Protlačeno pip *.rda/df a TRI pro stromovou strukturu.

uu!
klic bc 4 0
klic1 bc 4 0
text1 re 10 0
urov2
__text2 re 10 0
$

%tri
uu
urov2\text2.
%

Obrácené lomítko ukazuje na list text2 v uzlu
urov2.

Pokud je v uu urov2 vícekrát, třídí se podle text2
z první urov2. Podle uzlů přirozeně nelze třídit.
Mohlo by se ale třídění zobecnit na třídění stejnojmenných
uzlů podle nějakého listu v uzlech.
***************
Povedlo se protlačit první podmínku v příkladu xmlzam.zip a to:

%inf
zamdp
dite\kj "Tomáš" \rc 1 his_plat\da>1.2.93 \pd>1000 ;
%

K úplnému fungování podmínky je ještě dost daleko.
***************
Přemýšlím, jak s odkazy na položky stromu v podmínce. Dospěl jsem k syntaxi:

(Zam.adresa\stala\mesto "praha" || \prechodna\mesto "praha") zam.nar>1.1.1956

viz návrh struktury zam výše. Zam. je nepovinné, pokud se např. nejedná
o virtuální relaci. Pokud identifikátor nezačíná lomítkem, hledá se od
kořene stromu, pokud ano, hledá se pozpátku nejprve v poslední dosažené úrovni,
pak o jednu úroveň výše atd. až se najde úvodní jméno položky.

Takto by to mohlo být nejméně ukecané. Obrácené lomítko máme pouze v cestách
souborů, takže by to nemělo vadit ani v aritmetice - proto jsem zavrhnul
z hlediska psaní dostupnější znak na klávesnici /.
***************
V xmlzam.zip je prográmek demonstrující syntézu jednotlivých RDA do
stromové struktury. Slouží k tomu zobecněné ZUZ z RDA->XML a pak
nová instrukce INS vkládající do uzlu stromu věty z relace. V příkládku
do základu zaměstnance vložíme postupně jeho děti a jeho platovou historii.

Zobecněný přepis RDA->XML má nyní vlastnost, že všechny prázdné řetězce
a všechna nulová čísla a datumy se do stromu neukládají.
***************
V xrda.zip je prográmek demonstrující rodící se stromovou strukturu.
K cíli je ještě daleká cesta. Nic jiného, než je demonstrováno v CMD
to zatím neumí!
***************
Při práci s permanentní keší je nutno, aby úplné jméno souboru souhlasilo
s odkazem na soubor z konkrétní stanice. Tak např. z jedné stanice máme

z:\sklad\data\prijem.rda

a ze druhé stanice je to

k:\data\prijem.rda

Protože na serveru máme ještě zpřístupněn adresář d:\sklad

Proto globální substituce cesty může selhat a terminálový provoz se bude
hroutit, pokud všechny stanice nebudou mít soubor prijem.rda zařazen
v permanentní keši. Proto je lepší použít odkaz

\\<server\d\sklad\data\prijem.rda

kdy při správném globálním nastavení jména serveru nemůže dojít v aplikacích
pouze k nahodilému spuštění keše na různých stanicích.

Pro ověření funkčnosti keše je nyní možno pomocí

.showopenfile

si zviditelnit i latentní soubory v keši (shodné s _listc) a již aktivní
keše pro některé soubory (běžící aplikace musí soubor alespoň jednou
otevřít). Tím se dá ověřit, že odkazy skutečně fungují. Např.

.enable cache
.disable quiet
_openc "\\c2d\c\e\uziv.rda"
;Seznam souboru v keši:
_listc
;Otevřené soubory před INF
.showopenfile
inf \\c2d\c\e\uziv
;Otevřené soubory po INF
.showopenfile

V tomto případě .openfile vypisuje pro uziv.rda před INF "latentní"
a po INF "Aktivní" keš. Pokud by byl odkaz nesprávný, bude uziv.rda
i po INF "latentní".
***************
Udělána první verze překladu "XML", čtení dat, uložení do souboru s volnou
délkou věty a INF - pouhé zobrazení.

Z toho vyplynulo, že vypočtené položky nelze použít, RV se převádí na RE,
protože texty se vždy ukládají pouze ve skutečně zadaném počtu znaků
textové položky v té které větě.

Pro představu: Následující dvě věty se ukládájí v délce 137 a 89 bajtů.
Položky, které v definici uvedeme, ale v konkrétní větě nejsou zadány, nemají
vliv na délku uložení věty!

adresa prechodna ulice "Letohradská" mesto "Praha" prechodna ulice "Kamenická" mesto "Praha" rc 27 jmeno "Nikola Šuhaj Loupežník" ;
adresa stala ulice "Letohradská" mesto "Praha" rc 25 jmeno "Nikola Šuhaj" ;

Protože na předchozí otázku nikdo nereagoval, kloním se k názoru, že nahodile
zadané údaje uspořádám podle definice.
**************
Pro hierarchii jsem zvoli jakési zobecněné RSD, kde počet
úvodních mezer vytváří hierarchii položek:

zam
osc c2 5 0
jmeno rv 30 0
nar nd 10 0
adresa
stala
ulice rv 30 0
psc bc 5 0
mesto rv 20 0
prechodna
ulice rv 30 0
psc bc 5 0
mesto rv 20 0
dite
kjm rv 20 0
nar nd 10 0
vek vc 2 0 ro(xb)-ro(nar)
plat c2 6 0
plhist
od nd 10 0
plat c2 6 0
podnik rv 30 0
rc bc 10 4
$

V podstatě se jedná o podstatně méně ukecanou definici XML.

Rozchodil jsem analyzátor věty pro VSD např. zam.dat

zam
adresa stala ulice "Letohradská" mesto "Praha" rc 25 jmeno "Nikola Šuhaj" ;

a

%vsd
zam.dat
nt.
%

Věta bude mít vždy proměnnou délku věty. Položky se budou moci libovolně
opakovat a být v nahodilém pořadí a uvedeme pouze ty, které známe. Proto
je bezpodmínečně nutno uvádět údaje jejich identifikátory, kdy navíc
je třeba zachovat hierarchii nadřízených a podřízených položek. Proto
je nutno "adresa stala ulice", ale v rámci úrovně již stačí pouze "mesto"
i když by mělo být "adresa stala mesto". Ještě bude třeba dodat jakýsi příznak
"Nutno vyplnit" a "Pouze jednou ve větě".

Nabízí se otázka, zda takto zadané údaje srovnat v pořadí daném RSD
nebo je ponechat v pořadí jak byly zadány.
**************
Zaháji jsem práce na hierarchické větě v REDAPu ala XML.
**************
Ještě dodatek k Semptron 140 a desce původního boardu Gigabate.
Dočetl jsem se, že pokud se udělá upgrade BIOSu, pak ten procesor stará deska
zvládne. Ovšem pokud by Vám odešel totálně procesor, tak není co řešit.
Znamená to tedy, že by člověk měl průběžně testovat upgrady BIOS a ihned
si je na desku napálit.
***************
Zaveden příkaz

_mode ca:1. ekvivalentní .enable cache

_mode ca:2. .enable cache, ale jen pro soubory vyjmenované
v _openc - tj. permanentní cache.
******************
Vytvořil jsem novou instrukci CSV na čtení tzv. CSV struktur z Excelu ap.
Je to poměrně náročný úkol, vzhledem k nejrůznějším přístupům různých
autorů k této problematice.

CSV funguje jako ZUZ, s tím, že na vstupu má soubor CSV. Ten je několika
průchody analyzován. Hledají se čísla a datumy ve sloupcích. Potom se
stanoví nejčetnější počet sloupců CSV (může v tom být také uložena
normální sestava!) a řádky s jiným počtem se vynechají. Sloupce s
datumy a čísly se deklarují v pomocné RDF jako DD a ND, ostatní jako
RV. U čísel nevadí desetinná čárka, účetní formát i s měkkými mezerami.
U datumů nevadí různé oddělovače. Akceptuje se DDxMMxRRRR a MMxxDDxRRRR
a RRRRxMMxDD.

Identifikátory se berou z úvodního řádku (obecně nemusí být první) a to
v maximální délce dle _mode di:x. (implicitně 12). Kódová stránka se
určuje přepínačem q5:xy. Pokud je struktura divočejší, lze pomocí přepínače
pr:n přeskočit prvních n-1 řádků, s tím, ze hlavička je na n-tém řádku.
Pokud jsou texty identifikátorů nesmyslné nebo úplně chybí, lze pomocí
přepínače ai zapnout automatickou generaci názvů sloupců ve tvaru Sxxx,
xxx je číslo 001, 002, ...

V případě AI+PR:n se předpokládá, že na n-tém řádku je přímo hlavička!

Např.

_mode di:20.
%csv
q5:61,ai,pr:6.
c:\tmp\apsoft\money2~1.csv
(=) pokus
;
//
%
inf pokus

a soubor začíná

ObratovÁ p=edvaha;;;;;;;;
;;;;;;ŽÜetnÖ rok:;2010;


;;PoÜÁteÜnÖ stav;;Obraty za obdobÖ;;ZÝstatek;;
žÜet;St=edisko;MD;D;MD;D;MD;D;
013000;;11 558,00;0,00;0,00;0,00;11 558,00;0,00;
01300x;;11 558,00;0,00;0,00;0,00;11 558,00;0,00;
0130xx;;11 558,00;0,00;0,00;0,00;11 558,00;0,00;
...

Zkuste, a pokud dostanete někde špatný výsledek, pošlete vzorek CSV.
******************
Nestěstí nechodí po horách ale po lidech! Sotva jsem se vyhrabal z odchodu
HDD, začal mně v neděli zlobit procesor AMD (jak HDD tak procesor v provozu
26 měsíců). Abych to lokalizoval, vygeneroval jsem na HDD XP na jiném PC
a zjistil, že se stejným HDD i daty problémy zmizely.

Takže koupit nový procesor - jenže po 2 letech s paticí AM2 nebo
AM2+ je problém. V Alze měli jakýsi Semptron deklarovaný i pro AM2+ i AM2.
Po vložení na board byl ale schopen spustit pouze zdroj. Takže znovu a k němu
board - zase dost problém, protože Semptron byl starý. Jeden jsem na webu našel,
donesl domů smomtoval a jelo to. Jenže HDD mně začal hlásit nečitelné clustery!
Takže asi chyba boardu. Znovu na druhé PC a kontrola adresářů - hodilo to 15 kB
vad na disku. Popřekládal jsem pár věcí a znovu test - zase chyby a 150 kB
vad na disku. Pustil jsem v nástrojích kontrolu s vyhledáním o opravou vadných
sektorů - po 4 hodinách 550 kB vad na disku.

Takže nový disk. Rozdělit kopírovat. Nakopíroval jsem dvě zálohy systému
holý na D, procovní na E. Dodal MBR a na D s mně pěkně spustil na E zatuhnul.
Dal jsem při generaci opravit E a po restartu to odmítlo vůbec cokoliv
dělat.

Nakonec jsem začal od nuly, všechno vymazal a pod generátorem XP rozdělil
a zformátoval, vygeneroval holé XP na D a E - pěkně to fungovalo - na E
znovu kopii systému a zase to vytuhlo. Takže problém je v nepřenosnosti
XP z jednoho typu disku na druhý - zanevřel jsem totiž na Seagate a koupil
WD Green Line 1 TB.

Takže znovu na E holý systém a celý den práce přede mnou - kopírování,
generování různých překladačů, Office, pošta, WiFi a Bůh ví čeho všeho.
******************
Protože změna +-M3 na +-X3 (kvůli antiviru) vyřadila jak vyprázdnění keše
Windows, tak vynucenou změnu v adresáři pro soubor a vyprázdnění keše
antivirům nevadí, je nadáe možno použít i slabší +-Y3. Nebo

_mode an:1. jako +-Y3
_mode an:2. jako +-X3

Platí pro wr56 a výše.
******************
Pokud máte Vy nebo vaši zákazníci 64 bitový systém, můžete zkusit 64 bitový
REDAP - www.redap.cz/wr58_x64.zip
POZOR!! Běží pouze pod 64 bitovým OS, zatímco 32 bitový WR běží na 32 a
64 bitových Windows.
******************
Ještě výsledek na na AMD a Win7 32 bitové - prázdná aritmetika 0.50 minuty:

Wr58 1.21
Wr57 1.97

pod XP na stejném PC viz výše to dalo

WR58 0.73
WR57 1.43

takže "odlehčený" systém srovnatelný s XP ztrácí 0.5 minuty oproti XP a
64 bitový Win7 se zdá rychlejší než 32 bitový.
******************
Zkusil jsem u WR58 x64 optimalizaci na rychlost a čas klesl na 0.87 minuty
z původních 1.14 minuty.

Stejná optimalizace u WR58 x86 vedla k nárustu EXE o 200 kB, ale čas naopak
oproti optimalizaci na velikost paradoxně mírně narostl.
*****************
Porovnání předchozí úlohou 64 bitových Win7 a 32 bitových WinXp na Core 2 Duo
2.51 GHz:

Prázdná arimetika na XP 0.26 na Win7 0.53!

XP WR57 0.91 a WR58 0.61
Win7 x64 WR57 1.34 a WR58 0.98 32 bitů
WR58 1.14 64 bitů

Zklamalo mne, že x64 WR58 jede pomaleji na Win7 x64 nez x86 WR58 - 1.14
oproti 0.98 - údaje v desetinném vyjádření minut.
*****************
Při výpočtu vzájemných vzdáleností 2500 objektů počítá se základní přesností
WR57 1.43 min a WR58 0.73 min. Jedná se o SPO s parametrem CY a provádí se výpočty
pro cca 6 milionů vzájemných vzdáleností. Z toho je vidět, že C2 aritmetika
zde dělá zrychlení o 50%. Pokud zakomentuji výpočet, běží SPO 0.24 min, takže
skutečné zrychlení aritmetiky je 1.19 min vůči 0.49 min což je zrychlení o 60%.
*****************
Ve WR58 dokončuji testování D2 a C2 aritmetiky. C2 aritmetika je 19 ciferná
a odpovídá nastavení +AR, D2 aritmetika je alespoň 27 ciferná a odpovídá
nastavení +A6 a více. Největší porce práce spočívala v přepracování násobení
a dělení a nyní úprava a ověřování 110! funkcí ve WR. Dělení i násobení
je nyní několikanásobně rychlejší, zejména v C2 aritmetice. V některých
případech pro udržení přesnosti přechází C2 aritmetika do D2 aritmetiky,
která např. násobení může počítat v základní přesnosti +AR až na 36 cifer.
*****************
Pracoval jsem 11 a 12.2. na automatickém přepnutí základní aritmetiky pro
přesnost AR tj. DD 16 cifer na 64 bitovou aritmetiku s přesností na 19
cifer, když moje úsilí zhatila tragická událost s umrtím mého drahého
HDD. Takže ty dva dny práce musím znovu zopakovat + 1.5 dne obnova funkčnosti
celého operačního systému.
*****************
Zaveden numerický datový typ C2 ukládaný do RDA "Bajtově". Jedná se o binární
reprezentaci čísla maximálně +-2**63 což dává prakticky 19 platných cifer.
Není to 99999... ale maximálně 921..... Doplňující údaje C2 jsou počet míst
před a počet míst za desetinnou tečkou. Na základě těchto doplňujících údajů
REDAP rozhodne, kolik bajtů stačí na uložení takového čísla. Orientačně:

1 bajt maximálně 2 cifry
2 bajty maximálně 4 cifry
3 bajty maximálně 6 cifer
4 bajty maximálně 9 cifer
5 bajtů maximálně 11 cifer
6 bajtů maximálně 14 cifer
7 bajtů maximálně 16 cifer
8 bajtů maximálně 19 cifer

Může se hodit pro ukládání čísle v polích, kde může ušetřit oproti typu DD
místo (DD minimálně 2 bajty 4 cifry a pak vždy +2 bajty a 4 cifry navíc).
*****************
POZOR! Od jakživa nechodilo v aritmetice napr.

a=1*cos(90-45)

presneji, jakmile funkce mela v parametrech nejaký výpocet, musila být ve výrazu
na levé strane první. Takže

a=cos(90-45)*1 fungovalo

a=cos(90-30)*cos(90-45) nefungovalo

a=cos(90-30)
a=cos(90-45)*a fungovalo

Ve WR58 se mne to podarilo snad napravit, ale vzhledem k tomu, že to nikomu
dosud nevadilo a protože se jedná o dost choulostivý zásah, nedávám opravu
do nižších verzí.
*****************
Tiskový blok muže mít maximálne 65000 bajtu. Kolega Novák mne poslal príklad,
ve kterém bylo v jediném .pr() témer 4000 rádku vždy s xy na pixly + tisk položky.
To hodilo 200000 bajtu a tiskový stroj se zadrel. Udelal jsem ve WR57 a WR58
jakýsi ošmek, že nyní tiskový blok muže mít 16*65000 bajtu. Doufám, že tato hranice
alespon mesíc vydrží.
*****************
Funkce PrintScreen v základním winmenu neuměla uložit bitmapu tiskového
preview z TT:2. To nyní již lze - obsah PSCRxxx.jpg je pak mapa v "životní"
velikosti, jako po stisku numerického +.
******************
Ve .winmenu vadily čárky v příkazech .call, .gosub a @, které je zde možno
uvádět místo zkratek. Proto je možno nadále celý příkaz uzavřít do
dolních uvozovek. Např.

.winmenu pp
"MENU",PT0,sf0,r1|dv|mx
"INIT2",AAA,,r1|dv
"Tiskárna",BBB,,r1,"Nastavit","Esc-zpět"
"Dialogová volba"
"Výběr ze standardních typů",".call vyp("Prvni","Druhy")"
...

Zároveň je třeba konstatovat, že deklarované hotkey ve winmenu jsou nesmysl,
protože menu Windows je nezpracovává. Reaguje pouze na dominantní znaky a to
pouze v konkrétní aktivní roletce menu.
*****************
Zavedeny příkazy:

.nextnl

a

.nextdl

syntakticky shodné s .nextn a .nextd - liší se pouze tím, že v proměnné
příkazu bude dlouhé jméno (dosud pouze v lname).

Dále pomocí funkce <lname>=lnm(<8.3>) můžete převést krátkou cestu na
dlouhou cestu - pozor! soubor esp. adresář musí fyzicky na disku existovat!
*****************
Nová funkce UPLO(<ret>) - v řetězci se zvětší první písmeno a pak každé
po mezeře. U ostatních písmen se velikost písmene zachová. Zároveň
opraveno kažení <ret> při provádění UP(<ret>) a LO(<ret>), kdy se
akce provedla přímo na <ret>, takže

<ret1>:=up(<ret2>)

převedlo na velká písmena <ret2> a pak <ret2> byl přesunut do <ret1>.
Protož e většinou bylo <ret1> a <ret2> totožné, nikomu to nevadilo.
*****************
Na základě skutečnosti, že interní přesnost 18 cifer - cca 64 bitová
reprezentace - vyhovuje pro většinu dělení ve vašich aplikacích,
byl před původní algoritmus předřazen test na vhodnost užití
hardwareového 64 bitového dělení. Pokud je kladný, provede se dělení
tímto způsobem, čímž s dosáhne vícenásobného výkonu oproti původnímu
algoritmu.
Přepracována celá aritmetika a typ dd nahražen interně typem d2.
Typ DD má interně 4 cifry v soustavě 10000 a typ D2 má dvě cifry
v soustavě 1000000000. Základní přesnost je tedy 18 cifer, zatímco
DD má 16 cifer. Přirozeně pomocí AR6 můžete zvýšit přesnost na 27
cifer a pomocí AR8 na 36 cifer a pomocí AR9 na 45 cifer.

Bylo tím zasaženo cca 200 modulů z 550, takže pokud budete mít
náladu, pak na kopii! dat zkuste, zda se to chová rozumně na
vašich aplikacích.

Na webu je časově omezená WR58 do 31.10.2011 v síťovém provedení.