Svet musis digitalizovat, ale nemusis mit staticka data.
Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.
V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.
Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?
Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?