Portál AbcLinuxu, 7. května 2025 20:10
2.9.2013 01:16
Josef Kufner | skóre: 70
.
). Možných kombinací obsahů souborů je nekonečně mnoho a mají rovnoměrné rozložení, tj. jsou také statisticky náhodné (pokud by nebyly, sbohem steganografie). Takže zapsat offset na náhodnou pozici v π zabere průměrně stejné množství dat jako ta samotná data, která tak ukládáme.
Mimochodem jde o stejný problém, proč komprimační algoritmy nemohou fungovat na všechny soubory a naopak u některých souborů způsobí zvětšení (opět to statisticky konverguje k tomu, že komprimovaná data budou stejně velká jako originální data, prostě ta entropie musí zůstat; důkaz viz †). Na malém množství podobných dat komprimační algoritmy fungují. Jenže fungují díky tomu, že hledají nadbytečná (neetropní) data, která ale určitě nejsou statisticky náhodná. U π, které je statisticky náhodné, budete mít i u těchto souborů stejnou pravděpodobnost, že zápis offsetu do π bude větší než samotná data, jako pravděpodobnost, že bude menší. Statisticky to opět bude konvergovat k tomu, že offsety budou stejně velká jako samotná data. Průměrně tedy místo neušetříte, ale ani neztratíte.
† důkaz, že komprimovaná data statisticky konvergují na stejnou délku jako původní data (on se totiž týká i toho π):
Do k bitů lze uložit 2ᵏ hodnot. Mějme tedy 2ᵏ různých souborů (poznámka: souborem rozumím libovolnou sekvenci dat) a zkusme je zkomprimovat. Komprimací rozumíme zachování nebo zmenšení velikosti souboru. Menších souborů je ale jen 2ᵏ⁻¹, tedy některé soubory zůstanou stejně velké. Teď budeme komprimovat 2ᵏ⁻¹ různých souborů obsahujících k-1 bitů a tak dále. Nakonec zkusíme komprimovat soubory s nula bity. Takový je právě jeden a nejde zmenšit. Tím pádem ale nejde zmenšit ani soubory o jednom bitu, protože by ty zmenšené nebylo možné odlišit od souboru s nula bity. A tak dále až po k. Tedy po úspěšné kompresi budou všechny soubory stejně velké.
2.9.2013 05:43
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Tato hodnota přeteče 19. června 2038Na mém systému je to už o něco dřív. Že on mě Intel zase ošidil o setinu bitu?!
2.9.2013 10:50
Michy | skóre: 11
| Praha
date -d "@$((2*1024*1024*1024-1))" Út led 19 04:14:07 CET 2038Že by záměna anglického Jan/Jun?
2.9.2013 14:31
David Watzke | skóre: 74
| blog: Blog...
| Praha
3.9.2013 10:19
Conscript89
| Brno
On se hlavně ten problém objeví už ve chvíli, kdy bude někdo chtít vyjádřit čas za touto hranicí – ne až po tom, co tuto hranici překročí reálný čas. Jde o různé předplatné, pronájmy nebo události naplánované do budoucna… jasně většinou se to týká aplikačního softwaru a tam se můžou používat jiné datové typy. Ale obecně mi přijde zavádějící psát, že problém roku 2038 se nás týká až za 25 let.
Changes between 0.9.8n and 1.0.0 [29 Mar 2010] New function OPENSSL_gmtime_adj() to add a specific number of days and seconds to a tm structure directly, instead of going through OS specific date routines. This avoids any issues with OS routines such as the year 2038 bug. New *_adj() functions for ASN1 time structures and X509_time_adj_ex() to cover the extended range. The existing X509_time_adj() is still usable and will no longer have any date issues. [Steve Henson]
Jendou z vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně rozprostřenaV článku i jiných zdrojích je, že jde jen o domněnku! Ale popisu toho fs je, že se se vyhledávají jednotlivé byty, takže to ani není potřeba.
2.9.2013 13:47
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
10.9.2013 20:21