Ukladanie Int64, double, TDateTime do spoločného priestoru

[Miroslav Baláž]

Stejne tyhle potreby nechapu: i kdybych mel milion polozek cehosi, tak jestli mi to dneska zabere v pameti 9 MB (8+1 na chybejici diskriminator) nebo 16 MB pri pouziti variantu mi nestoji vubec za pozornost. Naopak, kdyz to udelam s variantem a zitra si vzpomenu, ze tam budu strkat neco dalsiho, tak v podstate nebudu muset zmenit na stavajicim kodu ani radek, protoze mam obecny pytlik na data.

Dáta budú obmedzené veľkosťou pamäte RAM. Sú len prenášané, inak ich nepotrebujem.
Rýchlosť je dôležitá.

[Miroslav Baláž]

..
Me se moc libil projekt TAnyValue. Tusim ze byl i rychlejsi nez TOmniValue. Variant ani TValue osobne nepouzivam.

Nemôžem sa k TAnyValue dostať. Všetky Downloads hlásia problém.
TanyValue je teraz Cromis.AnyValue. Napr : http://www.cromis.net/blog/2013/09/library-and-site-updates/
Inak je tam poznámka, ktorá ma zneisťuje, v zmysle možnej nestability pod x64. Možno to len zle chápem.
Aj tak sa ku kódu TAnyValue neviem dostať.

Je tu ešte ten TOmniValue. Primož Gabrijelčič, autor knihy "Delphi High Performance", intenzívne používa TOmniValue. Pozrel som namátkovo kódy ku knihe. . Už dávnejšie som tú knihu kúpil. Len nemám na ňu čas..
Tá kniha tu bola nedávno spomínaná:

..

[Delfin]

TanyValue je teraz Cromis.AnyValue.

TAnyValue je porad TAnyValue. Cromis.AnyValue je nazev modulu.

Nemôžem sa k TAnyValue dostať. Všetky Downloads hlásia problém.

Ten web byl dlouho mimo provoz. Zda se byt znovu nazivu, nicmene ma rozhazene odkazy. Tady je Cromis AnyValue Version 2.3.0 (12.09.2013).

[Miroslav Baláž]

Ďakujem TAnyValue je veľmi pôsobivé. Študoval som Demo.
Pre moje aktuálne potreby však plne stačí aj toto (s miernym prídavkom):
https://forum.delphi.cz/index.php/topic,16242.msg100675.html#msg100675
Rozmýšľal som aj o využití textu (do 10 bytov, pretože základ je Extended), ale to zrejme zariadim cez Dictionary, pričom odkaz pridám do TMyType.

[vandrovnik]

U toho typu extended hrozí nekompatibilita v 64bitovém prostředí, tam mají totiž Delphi nastaveno, že extended = double, tj. jen 8 bajtů (a z toho vyplývající menší rozsah a přesnost).

[Miroslav Baláž]

U toho typu extended hrozí nekompatibilita v 64bitovém prostředí, tam mají totiž Delphi nastaveno, že extended = double, tj. jen 8 bajtů (a z toho vyplývající menší rozsah a přesnost).

To je potenciálny problém. Keď robím debug, tak vidím rovnaký počet číslic pre Extended aj Double. Na konci nastupuje zaokrúhľovanie.
Keď preskúšam výsledky funkcou FloatToText, tak tá pri type Extended vráti o dva znaky viac ako Double.
Zdalo sa mi, že by to nemuselo byť s kostolným poriadkom.. Skúmal som aj TBCD. Myslím, že aj pri prevode z TBCD, sa používa funkcia, ktorá vráti len double.. Hoci samotné BCD má kapacitu až obrovskú. Teda voči Double..

Extended je aktuálne v prípade TMyType najexpanzívnejší typ. Ostatné sú menšie. Takže z programového hľadiska sa nič extra neudeje.
Smola je, že podklad mám v rozsahu Extended. Čo ma teda škrie, že sa stratí presnosť.
Človek by nečakal, že v 64 bit sa znížia schopnosti rozlíšenia..

[vandrovnik]

Pro práci s přesnějšími čísly se asi dá použít Data.FmtBcd.TBcd, ale nikdy jsem ho ještě nepotřeboval, tak nevím, jak moc dobře funguje a jaké operace jsou vlastně implementované.

[vandrovnik]

Ještě stojí za zmínku System.TExtended80Rec (pro načítání/ukládání extended v těch 64bitových verzích).

[Miroslav Baláž]

Ještě stojí za zmínku System.TExtended80Rec (pro načítání/ukládání extended v těch 64bitových verzích).

Tak som to študoval a veru neviem. Priveľmi zložité.
Vidím, že FireDAC daný typ používa..

Optimálne by som potreboval typ, ktorý spĺňa toto:
- nahradí klasický Extended (ten 32 bitový, nie ten double, čo je v 64 bit)
- má presnosť 80 bitov, resp. 10 bytov ( alebo viac )
- vie prečítať svoj obsah zo stringu (textu). Resp. dá sa naplniť priamo zo stringu.
- dá sa vzájomne sčítavať
- dá sa násobiť
- dá sa zapísať do databázy
- dá sa prečítať z databázy (v SQLite som pozeral, že napr. TBCD by bolo najlepšie uložiť do BLOBu , aby neprišlo k nejakej konverzii pri premene z textu)
- a operácie  SUM, AVG, MAX MIN - na to by som už vedel zrejme spraviť UDF (funkcie)

Riešením by zrejme bolo to BCD. Ak s tým má niekto skúsenosť, tak dajte vedieť.
BCD vidím napríklad vo FireDAC.Phys.SQLiteWrapper.pas

[pf1957]

Skúmal som aj TBCD. Myslím, že aj pri prevode z TBCD, sa používa funkcia, ktorá vráti len double.. Hoci samotné BCD má kapacitu až obrovskú. Teda voči Double..

TBCD je to, cemu se jinde ve svete rika decimal tj. nedochazi ke konverzim mezi desitkovou a binarni soustavou a cislice se ukladaji jako nibbles do pole bytu s tim, ze se pamatuje, kolik jich je a kde je desetinna tecka. Vsechny operace pak pracuji nad timto polem viz unit Data.FmtBcd. Pro konverzi se pouzivaji funkce (Try)StrToBcd, stejne jako se pocita primo v desitkove soustave vcetne desitkoveho doplnku atd.

Človek by nečakal, že v 64 bit sa znížia schopnosti rozlíšenia..

Taky me to zaskocilo, kdyz jsem na to narazil. Souvisi to s tim, ze puvodne se pouzival mat. koprocesor, ktery ma 80 bitu, ale se zavedenim instrukci SSE nekoho napadlo, ze staticky nejvice pouzivanym typem je double, takze se na typ extended vykaslou a operace s double zrychli implementaci pomoci SSE instrukci. 

[Miroslav Baláž]

Áno o BCD a FmtBcd som vedel. Len som mal obavy, že to nebude jednoduché v praxi.
Teraz som to vyskúšal. Zdá sa to byť jednoduchšie..
Ale predsa len chybička.. založím nové vlákno SQLite a TBCD prakticky + problém