Tedy pokud jsem to pochopil dobře.
]]> Našel jsem odkaz na LibreOffice - od verze 5.1 podle všeho si Maxima poradí s Texem a MathML. Viz 1.2.7 MathML output WxMaxima manual. Údajně lze zkopírovat schránkou výraz z editoru rovnic a vložit do WxMaxima. Ale je to zřejmě jen jednosměrné zpracování.
Maxima si poradí zřejmě jen s číselným zpracováním výrazů s jedním parametrem. Takže to vypadá, že LO (AOO) je pomocný prostředek pro výpočty k Maximě, což je dobré, ale šlo by to i obráceně jako rozšíření pro LO (AOO). Problém je tam jenom s kompatibilitou licencí. Ale Maxima je také OpenSource - pod licencí Creative Commons. Dle všeho by stačil souhlas autora.
Takové rozšíření by s velkou pravděpodobností překonalo funkcionality tabulkového procesoru GNUMERIC. Což je tabulkový procesor který byl původně zaměřen zejména na statistiku. Ale dnes na tento tabulkový procesor asi žádný jiný - včetně Calcu nemá v mnoha aspektech. Například volba rozsahu listu až 16000 sloupců a 16 milionů řádků (konkrétně 16,777.216 řádků a 16.384 sloupců). Sice také prochází prudkým vývojem a některé funkcionality tam jsou uvedené, ale nefungují dobře, nebo vůbec. Ale celkově velmi příjemné a jednoduché rozhraní, přístupy pro skupiny a jednotlivce, například konsolidace dat lepší nežli naše aj....
Po ukončení programu je volaná druhá funkce "Smazat instanci", která políčko (řádek) opět uvolní. Buňky jsou smazány a mohou být zase použity.
Zatím to pracuje bez kolize. Byl přidán další vnitřní parametr, který uživatel nevidí.
]]>Porovnávám výsledky s Maximou, kterou mám nainstalovanou na svém počítači. Calc, narozdíl od Maximy, která počítá algebraicky, počítá numericky - takže neumí počítat přesně. Jedná se pouhé přibližování k přesné hodnotě, kterou si nastavím posledním parametrem na přesnost, která mi postačuje. Zvýšením přesnosti se výpočet dost prodlužuje, takže se jedná o kompromis.
Například tento integrál musí vyjít přesně 2. Na listu si můžete zkusit, jak hodnota posledního parametru ovlivňuje výsledek (na kolikátém místě se začíná výsledek lišit).
Jak jsem měřil rychlost: Zvolil jsem stejný výraz (složitý) pro integraci a přesnost jsem nastavil na nějakou vysokou hodnotu, třeba 1000. A pak jsem stopkama změřil čas a porovnal, nejprve jednu funkci a pak druhou. Rozdíl byl při opakovaném měření ve vteřinách asi čtyřnásobný.
Pokud tedy říkáte, že Javascript je rychlejší, mohl bych hodit celou integraci do něj a pak by se to volalo jen jednou. Ale moc se mi do toho nechce - byla by rozdílná syntaxe, tím by to použití bylo pro úzký okruh lidí. Takhle je to mnohem použitelnější.
Škoda, že Calc nemá obdobnou funkci, tím by tohle vše odpadlo.
]]> Jiným typem buňky je klikačka která přímo spouští makro. Jinak lze nastavit nepřímo událost. Například událost listu - ale jen LO - AOO toto neumožňuje (dnes jsem se s tím pral - a neuspěl).
Takže makro se přímo buňkou spustit nedá, ale může se spustit díky nějaké inciaci se kterou buňka souvisí, nebo přímo řídí. Nejčastěji se to dělá pomocí objektů. Tedy například ovládacích prvků - ListBox, ComboBox, ... ale i v jednom případě "konsolidace dat".
Já jsem dnes trošku zkoumal tu Vaši práci a celkem je zajímavá ale některé věci mi nějak nedošly. Čím (jak) porovnáváte správnost výsledku - Matlabem? Proč výstupy náhodně bomabardujete do do listu? Nebo proč máte pro JS_integrate a N_integrate jinou přesnost? Nebo další možná zdroj chyby - proč neuděláte pro stejná zadání jednu společnou opravu řetězce? Tam všude bych asi viděl možnost chyby. Je mi jasné že testujete něco konkrétního a tohle je jen orientační. Jde také o zaplnění paměti takže to ovlivní výsledek ve smyslu času.
Uvádíte, že má Basic chybovost ačkoliv je 3x rychlejší - ale podle výsledků je tam jenom 1 chyba na posledním řádku a poslední číslici. Ta chyba může být dána možná i náhodným souběhem okolností. Vím - je to první varianta a budete dál hledat. Další věcí je, že Javascript skriptuje do sešitu a musí se navigovat - jinak by to bylo rychlejší. Já potřebují jen editor ale pak pustím Javasript "na volno" z html do adresáře - a vím že by to mělo být rychlejší.
Samozřejbě webmástr bere JavaSript jako poslední možnost (berličku) když to jinak nejde, ale i to, že je v sešitě 3x pomalejší se mi asi nechce věřit. Já tam ani nevidím měření procesů - nejlépe GetSystemTick, nebo alesponň pomocí TIMER(). Dá se tak najít kde to vázne.
Za hodku pojedu pryč a tam se dostanu jen na desku. Takže se na to podívám aý se svrátím. Teda nevím kdy - mám restů až hanba.