Bude budoucnost přenosu dat v replikaci?

27.5.2008 21:27 | Přečteno: 1690× | plky | poslední úprava: 27.5.2008 23:46

Tak si tak sedím a najednou mi hlavou prolétne myšlenka. Říkám si, zda mne nenapadl vynález kola, ale nakonec bych o tom, vzhledem k mým nezkušenostem, pohovořil :)

Cože mi to proletělo hlavou? Nu, říkám si, jak by se daly v budounosti zařídit přenosy dat na velkou vzdálenost. Jak by se čistě teoreticky mohl zajistit monstrózně rychlý a stabilní spoj. Muselo by to dát opravdu hodně námahy něco takového sestrojit a vymyslet. Potřebovalo by to asi hodně energie apod. Pokud jde o přenos vesmírem, tak jak by se zajistilo kolizím s prolétajícími předměty (hodně dat by se muselo posílat víckrát) apod.

Toto jsou ovšem úvahy, které navazují na stávající technologie, což je imho špatně. V budoucnosti by takové technologie možná mohly mít nicotný zdroj energie apod.

Naskytne se ovšem otázka, proč stavět monstrózní spoje, jejichž datový tok je velmi ohromujicí a čistě teoreticky by asi hodně zarušovaly okolí (nebo také ne, viz odstavec výše :)). Co jiného tedy vylepšit, když né spoj jako takový? Co třeba nějak zefektivnit velikost přenášených dat? Ale jak? Jsou dvě možnosti, které mne napadly :

1) První možnost asi napadne každého, není v ní cítit žádná originalita, jednoduše vymyslet nějakou monstrózní kompresy, jejíž dekomprimátor by měl obrovskou databázi a nahrazoval definované řetězce jinými.

2) Druhá možnost mi přijde originálnější. Vzpomněl jsem si na hash, jakožto jedinečný otisk dat. Takový hash, ze kterého by šlo "zničeho" vycucat reverzí data. K tomu už by byl třeba "jen" počítač s vysokým výkonem :). Ve finále by pak stačil poslat relativně malý řetězec, ze kterého by mašinka s obrovským výpočetním výkonem sestrojila data.

Takže toď vše k tomu, co se mi honí hlavou při koukání na prázdnou skleničku :). Otázkou ovšem je, zda jsem úplně mmimo, nebo na tom i něco bude. Rád se nechám poučit odborníky :). Díky všem zúčastněným :)

Zdar Max

UPDADE 23:42 : Abych upřesnil mou teorii. Dost lidí naráží na hash, ano, určitě jsem to špatně formuloval a možná i špatně pojmenoval. Nemyslím žádnou ze stávajích forem hashe. Myslím něco, co je na tomto způsobu založeno a k tomu ještě přibaleno pár věcí, aby šlo ony data vykouzlit, resp. nedocházelo ke kolizím. Jednoduše jde spíše říci, vyvinout nekolizní hashovací funkci. Na tuto otázku ovšem existují dva tábory. jeden tvrdí, že to nelze, druhý, že by takovou funkci šlo teoreticky vymyslet.        

Anketa

Komentáře

[ticcky]

a co kdyz ti z tech hashovanych reverzne udela zrovna ty kterys nechtel? =D

[Max]

Za předpokladu, že ten hash bude originální a nekolizní, tak by k tomu nemělo dojít, ne?
zdar Max

[ticcky]

tomu se pak rika komprimace, ne hash ;)

[vlasta neubauer]

hash je vždy kolizní. je to jeho základní vlastnost. ke každé hodnotě hashe existuje nekonečně mnoho 'řešení'

[kotyz]

Proto by bylo lepsi aby jich bylo nekolik a byly dost dlouhy + vedet presne typ a velikost souboru kterej ma vyjit + mit z nej aspon par kousku (minimalne zacatek kde je hlavicka souboru). Pak by to mozna ciste teoreticky asi i bylo proveditelny. S hodne silnym strojem s hafo pameti.

Trochu mi to pripomina ty napady jak nekdo chtel nahodnym generovanim ziskat treba fotky nebo muziku. Kdyz by se udelalo tech nahodnejch kombinaci jednicek a nul dost, neketery z nich by museli davat smysl. Ale tech kombinaci i pro nakej obrazek 200x200 px pri 256 barvach by bylo tolik ze by to trvalo jednak dlouho a zadruhy by se to vsechno ani neveslo na zadnej dnesni normalni disk. Nekde tady na abcl by se ten blog dal jiste jeste najit.

Zakladni myslenka je porad stejna jako u lamani hesel a sifer hrubou silou - vyzkouset vsechny existujici kombinace az se trefim do toho co potrebuju. A modlit se abych se trefil driv nez umru starim ...

[Bluebear]

a co kdyz ti z tech hashovanych reverzne udela zrovna ty kterys nechtel?

Tak jsi zvolil nevhodnou větev historie; musíš se vrátit a zkusit jinou.

[freshmouse]

A v čem se ve výsledku liší možnosti 1) a 2)?

[qiRzT]

Třeba v tom, že dvojka je ztrátová komprese.

[freshmouse]

[Käyttäjä 11133]

Není ztrátová. Za ztrátovou kompresi bych označil tu, která by z informace aaaaa udělala aaaa a ne takovou, která by z aaaaa udělala bbbbb.

[Ladicek]

Každou kompresi, která neumožňuje rekonstruovat data v původní podobě, bych s klidem nazval ztrátovou. Zde dosahuje ztráta rekordního sta procent

[Max]

Nu, výsledek by měl být vždy stejný, takže v tom by se lišit neměly :). Druhý způsob by měl potřebovat o dost menší datový tok a není dělaný na stylu doplňování dat za něco, ale "domýšlení" dat vzhledem k tomu hashy.
Zdar Max

[tezkatlipoka]

ale mi snad porad jeste rekontruovat puvodni data z hashe neumime, ne? Jenom najit kolizni data, se stejnym hashem. A vzhledem k dane velikosti hashe, a neomeze moznosti zdrojovych dat, bude asi kolizni kazdy hash, a ne jednou.

[freshmouse]

ale mi snad porad jeste rekontruovat puvodni data z hashe neumime, ne?

To je spíš tím, že takovéto hashe nikdo zatím moc nepotřeboval, a tak je ani netvořil, řekl bych (jako naprostý laik).

[Max]

Ano, tak je to teď, to vím, ale nemyslel jsem stávající hashe. Je mi jasné, že podle nich by to nešlo, ale myslel jsem něco, co bude založeno na hashování+nějaký fičurky k tomu.
Zdar Max

[freshmouse]

Ale je vlastně stejný i průběh: je třeba výkonný procesor. V prvním případě to skládáš z nějaké tabulky (nevím o tomto tématu skoro nic, tak mě kdyžtak poučte) a v druhém to odpočítáváš z hashe, ale v čem se vlastně ve své podstatě liší hash a zkomprimovaná data?

[Max]

Zkomprimovaná data by vyžadovala větší datový tok a menší výpočetní výkon. V podstatě se to liší tak, jak si říkal. Zkomprimovaná data lze v podstatě požadovat za ony fyzická data, kdežto případný hash by byl jen jejich otiskem. Data jako taková by se oproti zkomprimovaným vůbec nepřenášela a v tom by mělo být to kouzlo. Data získám, aniž bych je k sobě přenesl.
Zdar Max

[Messa]

Uvědomuješ si, že data se prostě nedají "komprimovat" hashováním? Pro každý hash lze najít víceméně neomezené množství zpráv, které tomuto hashi odpovídají (obecně řečeno; pokud je hash kratší než hledaná zpráva). Musel bys vyvinout sofistikovanější protokol, např. "vezmi zprávu s hashem 123 a aplikuj tento krátký patch" nebo nějakou podobnou šílenost.

[Max]

Už jsem říkal, že nemyslím stávající formu hashe, jak jí známe nyní, ale něco na té bázi. Prostě něco jako píšeš : zpráva, která má hash 123 a k tomu ještě nějaké drobnosti, co by to umožnily.
Zdar Max

[qiRzT]

Jenže co jiného jsou zkomprimovaná data než otisk původních dat? Pokud chceme aby takový přenos měl smysl, tak nutně požadujeme, aby zobrazeni hash - data bylo bijektivní (vzájemně jednoznačné). To co dnes myslíme pojmem hash, to nesplňuje. Každé jiné bijektivní zobrazení, které zmenší velikost původních dat, je komprese. Ovšem uznávám, že by mohlo mít smysl, aby ta komprese byla brutálně nesymetrická vzhledem k časové náročnosti, pokud by se tím získal velký kompresní poměr.

[Jirka P]

Zobrazení kód->text nemusí být bijekce, stačí surjekrivní. (Česky: kompresor nemusí být deterministický, stačí když z dekompresoru vypadne pro všechny možnosti to samý. Sice to znamená určité teoretické zhoršení komprese, ale pokud to umožňuje vytvořit rychlejší/paralelní/randomizovaný/... algoritmus, může to stát za to).

[freshmouse]

Mimochodem, jeden človek mi jednou tvrdil, že zkomprimoval data tak, že zkomprimovaná zabírala cca stokrát méně než původní. Jednalo se o nějakou hru (takže čistý text, obrázky i binárky). Prý to pak asi 8 hodin dekomprimoval. Mělo jít o něco *.kgb. Já nevím, mně tohle téma nic neříká, ale možné to asi je.

[tezkatlipoka]

to se mu to teda dekomprimovalo dlouho, to bych radsi vypalil CD navic, nebo poslal holuba.

[Max]

Dřív jsem měl v ruce hru, která byla zabalená do 100Mbit a po dekomprimaci měla něco přes 1GiB. Na tu dobu, to jsem čuměl, ale je pravda, že záleží na oněh datech.
Zdar Max

[...............23]

asi si vymyslel pigzip

[miro]

Tak ten je brutální

[Chocolate Bear]

Mám chuť se zabít.

[qiRzT]

Tak velkou blbost zas nenapsal.

[Messa]

Od čeho jinýho blogy jsou Furt lepší tohle než blogy o ubytování v Japonsku.

[Chocolate Bear]

Spíš na mě dolehla ta diskuze.

[Chocolate Bear]

Slibme si, že se tu už neukážu, ok? Závislost je sviňa.

[Max]

Slibme si, že si nic slibovat nebudeme :). Závislost je sviňa jen od určité chvíle ... :)
Zdar Max

[Max]

Stále si myslím, že jsem nenapsal blbost a zatím mne nikdo nepřesvědčil o opaku. Jen jsem byl přesvědčen, že se neumím vyjadřovat, nic víc :) ...
Zdar Max

[pc2005]

Taky jsem o tom kdysi uvažoval .

Nicméně to není příliš možné. Řekněme, že je určitý objem dat, třeba 32 bajtů a hash 8 bajtů. Tak pro všechny kombinace bajtů v datech = 256^32 a všechny kombinace bajtů v hashi = 256^8, takže hashem popíšeš jen těch 256^8 zbytek (256^32-256^8) budou kolizní. Leda, že bys dopředu stanovil, že hashovat půjdou jen vybrané kombinace bajtů v datech a zbytek se pošle celý. Ale to už je komprese a navíc poměrně známá (v době uvažování jsem ji neznal ). Nicméně i v kompresních metodách je ještě spousta potenciálu. Třeba lidské oko, taky si dovede "domyslet" obrovskou spoustu dat.

[Kyosuke]

Hele, nestuduješ FEL? A jestli jo, nebrali jste i takovou "teoretickou zbytečnost", jako je Shannonova teorie informace?

[pavlix]

+1

[vlasta neubauer]

hádám, že ten hash bude ve většině případů "42" :]

[Max]

Hehe, teď si to prokoukl ... :D
Zdar Max

[Jan Drábek]

Není k hashi potřeba i velikost souboru, aby se to metodou pokus omyl dalo dopočítat?

[Bluebear]

IMHO velikost přenášených dat není tak závažný problém. Skutečný problém je latence, protože ta je omezená rychlostí světla, které se docela vleče (jak vědí konstruktéři procesorů). Navrhoval bych, abys své tvůrčí síly napřel hlavně do tohoto směru, protože pro komunikaci v kosmu bude tohle to nejdůležitější.

[Käyttäjä 11133]

Už se těším na vakuovaná optická vlákna. Ale dál už asi rychlost šíření informace nepohneme.

[pc2005]

Vsadil bych na červí díry.

[raziel]

Ja na kvantovú "teleportáciu" informácie :)

[petr_p]

Fuj, takový neekologický přístup. Víte co by stála distribuce párových částic a jejich následná likvidace

[kotyz]

A co subprostor a hyperprostor?

[pc2005]

A nebo by se prostě zvýšila rychlost světla jako ve futuramě.

[Nicky726]

Mám za to, že hash je jednosměrná fce, jejímž učelem je snadno přiřadit datům nějaký klíč, s tím, že je velmi nesnadné z toho klíče obnovit původní data. A nesnadnost se definuje jako čas do konce existence vesmíru i při nasazení veškeré výpočetní kapacity v něm.

[Max]

Stávající forma hashe jak jí známe je vysoce kolizní, údajně jednosměrná fce, která spolehá na současný výpočetní výkon strojů. My se ovšem nebavíme o konkrétních stávajících hashí a ani o současném výpočetním výkonu strojů ...
Zdar Max

[Käyttäjä 11133]

Jenže to co navrhuješ je naprostá hovadina. Můžeš třeba zkombinovat 10 různých hashovacích funkcí a tak snížit riziko kolize (tedy situaci kdy uděláš zobrazení aaaaa -> b tak, aby ti z b nevyšlo ccccc) jenže s rostoucím počtem hashovacích funkcí ti narůstá množství přenášené informace a zároveň klesá pravděpodobnost kolize, avšak v okamžiku kdy pravděpodobnost kolize bude 0 si troufám tvrdit, že délka všech hashů bude stejná, nebo delší, než původní zpráva v závislosti na použitých hashovacích funkcích.

[Max]

Ano, přesně tak. Já si myslím, že lze udělat "krátký" nekolizní hash a ty tvrdíš, že nelze, že bude stejný, nebo větší, jak hashovaná data. Oba si to jen myslíme, ale nevíme to :).
Zdar Max

[Ondrej 'SanTiago' Zajicek]

Az na to, ze nemoznost existence takoveho hashe pujde pri presne formulaci podminek snadno dokazat holubnikovym principem. Viz http://en.wikipedia.org/wiki/Pigeonhole_principle .

[Käyttäjä 11133]

Neříká se tomu někde i šuplíkový princip?

[Käyttäjä 11133]

A jo říká, nepodíval jsem se na ten článek do wikiepedie, promiň. :D

[petr_p]

Učeně se tomu říká Dirichletův princip, nicméně v praxi zcela postačuje označení „zdravý rozum“.

[Ladicek]

No, ona ve skutečnosti spoléhá na to, že obrovskou spoustu informace prostě zahodí. Proto k hashovací funkci z principu nemůže existovat funkce inverzní.

Jakmile zachováš veškerou informaci, je to prostě komprese. Celá diskuse pod tímhle zápiskem je víceméně slovíčkaření vzniklé z toho, že termínu hashovací funkce přisuzuješ jiný význam, než jaký běžně má.

[bazil]

a co když ve vesmíru je jiná rasa, která je schopná se svým výpočetním výkonem naše nynější hashe vypočítat na jejich obdobě kancelářské kalkulačky?

[Max]

Tak jim je to k hovnu, protože naše současné hashe jsou kolizní ... :D, proto musíme vymyslet nekolizní hash, což zní jako blbost, ale nevím, jak jinak to pojmenovat :D
Zdar Max

[Käyttäjä 11133]

Nekolizní hash je náhodné orákulum s pamětí, ale to zase dokáže pojmout jen omezené množství vstupních údajů (velikost paměti, která je závislá na délce výstupního hashe). Jakmile tuto hodnotu překročíš, tak musí zákonitě dojít ke kolizi.

[miro]

A co když místo kolizní hashe orákulum prodlouží délku hashe? Jinými slovy - vyplývá přímo z definice hashe, že musí mít konstantní délku?

[Käyttäjä 11133]

Mezi hlavní vlastnosti této funkce patří:

   1. jakékoliv množství vstupních dat poskytuje stejně dlouhý výstup (otisk)
   2. malou změnou vstupních dat dosáhneme velkou změnu na výstupu (tj. výsledný otisk se od původního zásadně na první pohled liší)
   3. vysoká pravděpodobnost, že dvě zprávy se stejným hašem jsou stejné

[miro]

Dobrá, nemějme tedy konstantní velikost toho řetězce a neříkejme mu hash. Tak jako tak je to teoretická debata, protože kdo z nás má k dispozici náhodné orákulum, že. Reálná by snad mohla být jen ta první možnost, kterou Max ve svém blogpostu navrhoval (i když v ní není cítit žádná originalita...)

[Käyttäjä 11133]

Jennže to máš potom úplně normální kompresní algoritmus typu... mám tabulku A a k ní přiřazené informace B

tak, že A -> B ^ B -> A; což uděláš právě tou databází a tu databázi musíš vždycky přenést, takže ano, ty dokážeš 3000GB zkomprimovat na 1b, ale pak musíš přenést 3000GB tabulku :D Můžeš si databázi připravit předem, ale pak je to prostě kompresní algoritmus s velkou databází.

[miro]

Kompresní algoritmus s velkou databází - přesně tak jsem to myslel, a mám pocit, že to tak myslel i Max.

[Käyttäjä 11133]

To asi těžko, kdyby to tak myslel, tak by neměl v článku uvedenu možnost 1

1) První možnost asi napadne každého, není v ní cítit žádná originalita, jednoduše vymyslet nějakou monstrózní kompresy, jejíž dekomprimátor by měl obrovskou databázi a nahrazoval definované řetězce jinými.

a možnost 2

2) Druhá možnost mi přijde originálnější. Vzpomněl jsem si na hash, jakožto jedinečný otisk dat. Takový hash, ze kterého by šlo "zničeho" vycucat reverzí data. K tomu už by byl třeba "jen" počítač s vysokým výkonem :). Ve finále by pak stačil poslat relativně malý řetězec, ze kterého by mašinka s obrovským výpočetním výkonem sestrojila data.

[miro]

Teď mi uniká, jaký je rozdíl mezi "kompresním algoritmem s velkou databází" a mezi "jednoduše vymyslet nějakou monstrózní kompresy, jejíž dekomprimátor by měl obrovskou databázi a nahrazoval definované řetězce jinými". Tedy sice vidím, že o databázi Max hovoří v souvislosti s dekomprimátorem, ale neumím si představit, že by komprese v takto navrhovaném řešení mohla probíhat bez použití téže "obrovské databáze".

[Käyttäjä 11133]

Uniká ti to, že Max zmínil možnost s velkou databází jako možnost číslo 1 a možnost s "nějakou hashovací funkcí" jako možnost dvě, jedná se tedy o dvě oddelená řešení a zatímco řešení číslo 1 má nějaký smysl, tak řešení číslo 2 je naprostá hovadina, což se tady snažím ukázat.

[miro]

Ano, ale já to přesně tak myslel - "Reálná by snad mohla být jen ta první možnost, kterou Max ve svém blogpostu navrhoval (i když v ní není cítit žádná originalita...)". Tak jsem rád, že se to vysvětlilo, díky.

[Käyttäjä 11133]

Ale já říkám, že v době kdy máš náhodné orákulum, kterému postupně narůstá délka výstupu s počtem použití, tak že prakticky převedeš případ 2 na přílad 1. Ale máš pravdu, nechme toho. :)

[miro]

To si právě nemyslím, protože první zprávě, které orákulum obdrží, může přiřadit hash 0, další 1 a tak dál, takže délka neříkejmetomuhashe může teoreticky být log(n)/log(2) (zaokrouhleno na celé číslo nahoru), kde n je počet zpráv, které už v minulosti prošly orákulem. Což bude dávat kompresní poměr, který případ 1 může těžko dosáhnout. Akorát mě teď napadlo, že by se takovému orákulu nedalo říkat "náhodné", ale u kompresní funkce to není na závadu. Na druhou stranu by tenhle model vyžadoval "všudypřítomnost" orákula, protože jinak by byla komprese záporná (data se musí poslat orákulu, zpátky dostanu neříkejmetomuhash, ten pošlu příjemci, příjemce pošle neříkejmetomuhash orákulu, orákulum mu pošle data, takže celkový traffic se zvýší o trojnásobek délky neříkejmetomuhashe). No a teď těch blábolů bylo už doopravdy dost.

[Käyttäjä 11133]

Sranda musí být.

[Käyttäjä 11133]

Tak nám to může být celkem jedno, protože pravděpodobnost, že jejich přirozený jazyk je stejný jako ten náš je velice mizivá. Navíc když by to byla tak vyspělá civilizace asi by nepoužívali číselnou soustavu o základu 2 ve svých počítačích, ale o základu e. No a i kdyby tyhle problémy nestály za řeč, tak je tady pořád ta připomínka, že k čemu jim bude znát heslo k našemu e-bankingu,...

[Max]

Zapomínáš na to, že už se dávno infiltrovali do naší společnosti, naučili se našemu jazyku a běhají okolo se svými "kalkulačkami" kvůli získání hesla k e-bankingu, aby si za získané many mohli koupit pivko, které oni neumí replikovat, protože ten kouzelný mok .... :D
Zdar Max

[Kvakor]

Navíc když by to byla tak vyspělá civilizace asi by nepoužívali číselnou soustavu o základu 2 ve svých počítačích, ale o základu e.

I kdyz je e opravdu optimalni bazi, tak si osobne nedovedu predstavit stroj, ktery by tuto bazi pouzival, leda ze by se pouzil nejaky trik, treba jako ten s bazi zalozenou na zlatem rezu, kde jse mozne reprezentovat cela cisla konecnym poctem nul a jednicek.

Bez konecne reprezentace celych cisel by byla konstrukce pocitacu prinejmensim extremne komplikovana (tedy alespon pocitacu v podobe, jake je dnes zname), pokud ne rovnou nemozna, protoze by se prirozena i racionalni cisla choval stejne jako iracionalni, jedinou vyjimkou je uz zminena baze zalozena na zlatem rezu, a to jen diky sve sobepodobnosti. Vice viz treba tady.

Ale dokazu si predstavi pouzivani takovychto systemu (ve spojeni s "klasickou" ridici jednotkou) pro numericke vypocty, svym zpusobem matematicke koprocesory reprezentuji cisla podobnym zpusobem uz dnes.

[Jirka P]

I kdyz je e opravdu optimalni bazi

To je blbost, a dost nakažlivá. I když, uznávám, sexy.

[Käyttäjä 11133]

Příloha:

• soustava.pdf (26417 bytů)

Udělal jsem někde chybu? Viz přiložené pdf.

[Käyttäjä 11133]

Příloha:

• soustava.pdf (26423 bytů)

Byl bych to já, kdyby tam nebylo alespoň jedno typo? Opraveno.

[Ondrej 'SanTiago' Zajicek]

Proc je E=n*z a ne E=n*log(z) ?

[Jirka P]

Ne, chybu ve výpočtech tam nemáš. (Upřímně: překvpilo mě, že někdo vůbec ví, jak se k tomu došlo; většina to jen papouškuje)

Zásadní problém je ve formulaci té úlohy. Ta předpokládá, že těch "zdrojů" na jednu číslici potřebujeme přesně C*n (C konstanta > 0). To je pravda, pokud číslice přenášíme kódem 1 z n, ale už je to diskutabilní u počtu drátů k digitronu, kde je těch drátů o 1 víc. U BCD nebo 7seg displeje je to už úplně mimo. Kdyby to platilo třeba o abecedách, tak na reprezentaci CJK znaku, kterých je dejme tomu 100x víc než znaků latinky (znalci doplní/upřesní) potřebujeme plochu 100x větší než na znak latinky. To není pravda ani na papíře, ani v počítači.

[Spike]

Spíš nejméně deset tisíckrát víc (nepočítaje několik historických variant). Latinka není zrovna efektivní na využití místa - tím spíš, že popisuje pouhé zvuky, nikoli ideje.

[Spike]

Meh, to jsem přehnal, už ani násobit neumím. "Deset" si odmyslete. :)

[David Jaša]

Latinka není zrovna efektivní na využití místa - tím spíš, že popisuje pouhé zvuky, nikoli ideje.

Na druhou stranu se dá abeceda naučit velmi rychle a neznámé slovo člověk alespoň přečtě (platí pro jazyky, kde psaná podoba slova neztratila vazbu na výslovnost).

[Spike]

A ty myslíš, že neznámý znak nepřečteš (pokud jsi rodilý nebo dost zkušený mluvčí)? Kdybys věděl něco o čínském písmu, tak bys třeba tušil, že zpravidla jedna část určuje významový okruh, druhá výslovnost. Neplatí to samozřejmě vždy, ale třeba v angličtině a jiných jazycích můžeš správnou výslovnost té „fonetické“ latinky taky jen hádat. U čínského znaku tedy tušíš výslovnost, tušíš význam, můžeš popsat tahy… nepřijde mi to o tolik rozdílné, jen trvá déle naučit se ten základ a jsou složitější principy.

[David Jaša]

Neplatí to samozřejmě vždy, ale třeba v angličtině a jiných jazycích můžeš správnou výslovnost té „fonetické“ latinky taky jen hádat. Kdybys věděl něco o čínském písmu, tak bys třeba tušil, že zpravidla jedna část určuje významový okruh, druhá výslovnost. Neplatí to samozřejmě vždy, ale třeba v angličtině a jiných jazycích můžeš správnou výslovnost té „fonetické“ latinky taky jen hádat.

K tomu se vztahovala závorka v předešlém příspěvku. Umím přečíst 3 jazyky psané latinkou (en, de, it) a z nich pouze u jednoho není výslovnost svázaná s psanou podobou (angličtina; a i tam se dá většinou vytušit).

[Jirka P]

myslíš, že neznámý znak nepřečteš (pokud jsi rodilý nebo dost zkušený mluvčí)?

Hlavně myslím, že nemám šanci, pokud jsem cizinec. Navíc jednoduchá abeceda neznamená jen snadné čtení, ale i opisování, zapamatování a psaní/tisk. Kupříkladu jsem jednou jel tramvají s Francoouzi, kteří vyslovovali Palmovka jako Palmokaa [ponechme stranou, že zřejmě nepochopili skvělý systém pražských tramvají, které na tom displeji na každé zastávce ukazují konečnou]. A přestože nevědí, jak se to vyslovuje, nemaj šajn co to může znamenat, dokážou na tu Palmovku dojet (a patrně by se na Palmokaa i doptali). To je nemyslitelné s nějakým obrázkovým písmem.

Celkově myslím, že symboly (jakékoli) by měly být co nejabstraktnější a abstrahovat od významu a tahů je jen dobře.

[bazil]

no tak já sem raději dopíšu, žš to bylo myšleno jako ftip

[hajma]

fraktalova komprese

cili staci prenest rovnici, souradnice a velikost plochy. zbytek si dopocita druha strana

[Käyttäjä 11133]

"stačí" :D Nevím třeba jak by si chtěl fraktálově komprimovat posloupnost náhodných dat třeba z kvantového generátoru náhodné posloupnosti. V tom by se snad už žádný vzorec neměl dát najít.

[pavlix]

Fraktálová komprese bývá pokud vím ztrátová.

[Käyttäjä 11133]

To záleží snad na povaze komprimovaných dat. Pokud budeš pomocí fraktálové komprese komprimovat obrázek nějakého fraktálu po konečném počtu iterací, tak ti nic nebrání přenést rovnici toho fraktálu i počet iterací (v případě, že příjdeš na postup jak určit rovnici fraktálu a množství iterací).

[Ladicek]

Což je ovšem pouhopouhý speciální případ

[pavlix]

Zdá se mi to nebo je to jinými slovy to, co jsem říkal. Tedy že fraktální komprese bývá obvykle ztrátová (neboli fraktální komprese je bezztrátová jen za velmi specifických okolností).

[Hobit]

Mam dojem, ze onen nekolizni hash bude defakto roven mizernemu sifrovani bez uspory prenasenych dat. ;o)

[Zdenek]

Doporucuju vysokou skolu aby sis sam mohl dokazat jakou si napsal blbost

[YYY]

Pro vetsinu lidi by snad na toto ani nemela byt vs potreba ne?

[pavlix]

Na tohle stačí mít domu zavedenej internet a vyhradit nějakej ten čas (třeba ukrojit z doby vyhrazené na psaní nesmyslů do blogů a fór).

Takže +1

[Max]

Děkuji, ale mám jiné cíle :D (ty, z nichž se dělám blbcem opomeňme :D)
Zdar Max

[kotyz]

Presne na to samy sem uz driv myslel taky: mit jen zacatek (kde je hlavicka) a konec souboru a par hashu + by se vedelo co to ma bejt za data a jakou maji presne velikost - a z toho se to snazit zrekonstruovat (kdyby to melo bejt jen jeden hash a nic k tomu, tak by se to asi delalo o dost hur a trvalo by to dyl). Takze treba jeden nekolikagigabajtovej soubor by se dal 'zkompresit' na dejme tomu 30 MB.

Kazdopadne je to dneska asi nerealizovatelny (mozna nakej kratkej textovej soubor by se povedlo z hashe v nakym rozumnejsim case rekonstruovat).

[kotyz]

Zase ale kdyz to bude neco vic nez hash (kdyz tam budou casti originalniho souboru), tak uz je to pak 'obycejna' komprese (at uz ztratova nebo bezztratova) a ne hash.

[pavlix]

Ještě znám jednu velmi kvalitní ztrátovou kompresi. Viděl jsem ji i v úpravě pro kompresi celého adresářového stromu (samozřejmě pod rootem). Kompresní poměr optimální.

A pak jsou ještě fyzický metody... zkoušel jsi vložit harddisk do hydraulickýho lisu? Akorát kompresní poměr bude trochu horší a nenapadá mě síťová alternativa.

[Kyosuke]

"mit jen zacatek (kde je hlavicka) a konec souboru a par hashu + by se vedelo co to ma bejt za data a jakou maji presne velikost - a z toho se to snazit zrekonstruovat"

To mi připomíná Járu Cimrmana..."někdo musel světu ukázat, že vyfukováním tabákového dýmu do vody zlato nevznikne"...

[pavlix]

+1

Ale že má Cimrman nadějné nástupce :D.

[pavlix]

Přesně tak, když vezmeš začátek a konec krátkého souboru... řekněme třeba prvních a posledních 20 bajtů z čtyřicetibajtového souboru, tak ti to bude perfektně fungovat :D.

[kolemjdouci]

Dlouhou dobu jsem nechapal vyznam nekterych prednasek na vysoke skole. Ted uz chapu, ze jejich cilem bylo vzdelat nas alespon minimalne a tim nam zabranit vest takove uvahy jako jsou tady Na druhou strany je treba ocenit kazdeho kdo ma odvahu se se svymi myslenkami prezentovat na internetu a celit kritice anonynmnich "kolemjdoucich".