(Добавить комментарий)

	tezzereth57@lj 2013-02-26 13:56 (ссылка)
	Возможно, я чего-то не понимаю, но если размер словаря слишком велик по сравнению с размеров архива, то начинает играть весомую роль время поиска в словаре? (Ответить) (Ветвь дискуссии)

	void_am@lj 2013-02-26 14:59 (ссылка)
	Растет размер слова, подставляемого вместо архивируемого блока байтов. (Ответить) (Уровень выше) (Ветвь дискуссии)

asocio@lj 2013-02-26 15:08 (ссылка)

Но ведь пока слово меньше этого блока - архивация осуществляется. Если это слово - номер внутри блока данных на 1 гб, то максимальный адрес составит не так много знаков: 2 ^ (от 1 до 30) плюс-минус ещё какое-то не очень длинное число для установления точной позиции. То есть номер в принципе можно ужать до десяти, может быть двадцати цифр. Самые частые блоки расставить на выгодные "круглые" места типа 2^5+1 или 2^7-1. Не думаю, что оптимальный объём (объем, при котором архивация имеет смысл) для такого словаря такой уж маленький (Ответить) (Уровень выше) (Ветвь дискуссии)

	jack8merkin@lj 2013-02-27 02:34 (ссылка)
	Есть мнение, что количество универсальных слов, необходимых для такой архивации, растет в геометрической прогрессии по мере удлиннения слова. Теоретически должен быть какой-то предел, после которого рост объема словаря не оправдывается. Но, действительно, было бы интересно это посчитать. Эх, забросил я программирование лет 18 назад, даже жаль иногда... (Ответить) (Уровень выше)

void_am@lj 2013-03-13 21:44 (ссылка)

Если n - длина указателя, то количество адресуемых им слов составит 2^n. Так как длина слова из словаря должна быть не меньше длины указателя, то объем словаря составит не меньше n*2^n. При длине указателя 10 бит объем составит немалые 20 ГБ - уже техническое ограничение. Если кодируются относительно частые длинные слова (длиной m), то такие слова охватывают лишь 1/2^(m-n) возможных вариантов. Если кодируемый текст состоит из необычайно частых повторов - тогда, возможно, есть смысл наращивать длину словаря; если нет - то увы, эффективность архивации падает экспоненциально. Как-то так; я не уверен в аргументах, но то, что смотрел по теме статистики, понял так :( (Ответить) (Уровень выше)

	kuzia_aka_zmey@lj 2013-02-27 05:26 (ссылка)
	не начинает. там логарифм все равно от размера идет. так что это не проблема. Там другие камни могут быть. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tezzereth57@lj 2013-02-27 09:52 (ссылка)
	Правда? Всегда думал, что поиск линеен, и лучше нельзя. (Ответить) (Уровень выше) (Ветвь дискуссии)

	kuzia_aka_zmey@lj 2013-02-27 10:02 (ссылка)
	ну вообще то в архивах строятся деревья "слов" а не списки. Поиск по дереву это как раз логарифм от количества выходящих из узла веток. Линеен поиск к несотсортированном списке в отсортированном (да еще если и индексированном) намного меньше. А словари всегда будут отсортированы. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tezzereth57@lj 2013-02-27 10:04 (ссылка)
	Спасибо. (Ответить) (Уровень выше)

	anonim_legion@lj 2013-02-26 13:57 (ссылка)
	Для передачи http что-то подобное применяется. То есть, словарь на клиенте пополняется с сервера, и не передается каждый раз. (Ответить)

	n0kk@lj 2013-02-26 14:18 (ссылка)
	Анекдот №38! (Ответить) (Ветвь дискуссии)

	asocio@lj 2013-02-26 14:49 (ссылка)
	*осуждающе* мы при программистах таких анекдотов не рассказываем! (Ответить) (Уровень выше) (Ветвь дискуссии)

	n0kk@lj 2013-02-26 15:06 (ссылка)
	Это, походу, у нас словари разные... (Ответить) (Уровень выше)

	kajaleksei@lj 2013-02-26 14:20 (ссылка)
	Насколько я понимаю, наибольшую выгоду такой метод даст при архивации текстовых данных, но они слишком уж "легкие" по сравнению с медиа контентом, например, и архивировать их никакого особого смысла нет. Т.е. идею похоронили техническое совершенство средств передачи данных, большой объем и доступность накопителей. (Ответить) (Ветвь дискуссии)

	asocio@lj 2013-02-26 14:49 (ссылка)
	Это я и так понимаю, люди уже гигабайты за минуты качают, какая уж там архивация (Ответить) (Уровень выше) (Ветвь дискуссии)

	kajaleksei@lj 2013-02-26 14:58 (ссылка)
	Я сам об этом думал:) И понял, почему идея без перспектив. Если только ФИДОшникам ее подбросить, вроде бы они сохранились еще? Если кто и заинтересован в такой системе архивации, то только они. (Ответить) (Уровень выше)

	stealthy_shadow@lj 2013-02-26 15:28 (ссылка)
	Вообще-то обычно эти гигабайты являются медиаданными и уже пожаты гораздо более эффективными "архиваторами" - кодеками. Фактически, передаваемые медиаданные максимально близки к случайному набору данных. (Ответить) (Уровень выше)

	sandblaster@lj 2013-02-26 14:25 (ссылка)
	Сейчас это имело бы смысл для 3/4Ж, там, где надо оптимизировать траффик. И да, у кого нет терабайта, могут идти в жопу (Ответить) (Ветвь дискуссии)

	alex_brab@lj 2013-02-26 14:34 (ссылка)
	такое давно существует для любых IP сетей. (Ответить) (Уровень выше)

stealthy_shadow@lj 2013-02-26 14:49 (ссылка)

3G/4G в основном потребляется мобильными устройствами - у которых и так не очень хорошо с быстродействием и набортным объемом памяти. Загрузить еще и так маломощные процессоры распаковкой (привет, батарея!), а небольшие объемы памяти - словарем на 50 гиг (привет, память!)? Интересная мысль, право! Может это и будет иметь смысл для каких-то узкоспецилизированных применений - но для большинства устройств в настоящее время это нерационально. (Ответить) (Уровень выше) (Ветвь дискуссии)

	alex_brab@lj 2013-02-26 14:51 (ссылка)
	вам слово "кеш" о чем-то говорит? (Ответить) (Уровень выше) (Ветвь дискуссии)

	shark_ru@lj 2013-02-26 14:58 (ссылка)
	Ща, дайте вспомнить... Кэш... Кэш... А! Это такая волшебная штука, которая не требует аппаратуры для реализации и не жрёт энергию при работе. Оно? (Ответить) (Уровень выше) (Ветвь дискуссии)

	alex_brab@lj 2013-02-26 15:01 (ссылка)
	требует, жрет. однако в определенных условиях показывает очень приличные результаты - что окупает все расходы (Ответить) (Уровень выше)

	stealthy_shadow@lj 2013-02-26 15:24 (ссылка)
	Вы понимаете разницу между "кэшированием" и "словарем архиватора"? (Ответить) (Уровень выше)

	alex_brab@lj 2013-02-26 14:34 (ссылка)
	бля. основная информация которая сейчас жрет объёмы винтов - не сжимаема ничем, т.к. уже сжата. Это фото и видео. Вот тебе и ответ. при передачи данных твои "словари" используются, дают "степень сжатия" в 1,5-100 раз :) (Ответить) (Ветвь дискуссии)

	asocio@lj 2013-02-26 14:48 (ссылка)
	Фото и видео сжаты на основании того, какие последовательности есть у них внутри - условный внутренний словарь. Если взять видеотеку в десяток тысяч видео и вытащить из неё статистические закономерности - наверняка можно будет ужать сильнее, разве нет? (Ответить) (Уровень выше) (Ветвь дискуссии)

	alex_brab@lj 2013-02-26 14:49 (ссылка)
	нет. пичалька (Ответить) (Уровень выше) (Ветвь дискуссии)

	ext_698144@lj 2013-02-27 06:36 (ссылка)
	Ну почему же. Процента 3 ужать можно, инфа 146%. (Ответить) (Уровень выше)

	leise_stimme@lj 2013-02-26 15:27 (ссылка)
	Проблема, чисо математическая, в том, что для полного описания уникальных последовательностей нулей и единиц длинной в 10 символов, потребуется число длинной в 10 символов. (Ответить) (Уровень выше)

	ursusrussus@lj 2013-02-27 08:28 (ссылка)
	>Фото и видео сжаты на основании того, какие последовательности есть у них внутри - условный внутренний словарь. Да, и этот словарь называется "кодек" или "формат". Поэтому, например, чёрно-белые чертежи лучше хранить в гифе, а цветные фотографии - в джипеге. (Ответить) (Уровень выше)

werewolf_online@lj 2013-03-02 13:54 (ссылка)

Зачем такие сложности. Если у вас, например 256 фильмов, просто тупо запихиваете их в словарь по порядку(место на диске не проблема), и дальше сжатие делается элементарно - фильм это его номер в словаре. Для 256 фильмов любой из них сжимается в один байт, т.е. больше чем 100500 раз. Если фильмов больше, не проблема - общее количество фильмов созданых человечеством явно меньше чем например число которое можно записать в 10 байтах, даже в таком случает сжатие будет феноменальным. Ну проблема только со словарем он должен быть у всех одинаковым и содержать все эти фильмы :) (Ответить) (Уровень выше)

	kvakosavrus_q@lj 2013-02-26 14:43 (ссылка)
	В общем случае да, чем больше размер словаря, тем лучшее сжатие мы можем получить. Но тем больше нам требуется вычислительная мощность. Работа со словарем "в 10 гигабайт" возможна, но потребуется десятки (если не сотни) гигабайт ОЗУ и 1048576 ядерный процессор :) (Ответить)

stealthy_shadow@lj 2013-02-26 14:47 (ссылка)

Что значит "распяли"? Чувак элементарно не понимает разницу между алгоритмом и форматом. О чем с ним можно говорить, что обсуждать? Касательно идеи в посте. При сверхбольшом словаре теряется смысл архивирования. Грубо говоря - либо указатель на нужные данные в словаре будет больше самих данных, либо сами данные будут встречаться настолько редко, что их замена указателями не будет иметь смысла. Т.е. сжатие малых файлов не будет иметь смысла, а сжатие больших файлов будет невозможно. Сейчас для каждого архива создается уникальный словарь - и это обеспечивает выигрышь в объеме. Если словарь будет "общим для всех", то размер архива вполне может привысить размер оригинального файла. Это если совсем на пальцах. (Ответить) (Ветвь дискуссии)

	tarkhil@lj 2013-02-27 02:31 (ссылка)
	Ну должен же asocio побрюзжать на программистов... (Ответить) (Уровень выше)

shark_ru@lj 2013-02-26 14:48 (ссылка)

> Почему нельзя создать большой словарь? Потому что словарь создаётся для текста с определёнными статистическими характеристиками. В идеале, для каждого текста -- свой словарь. Словарь для некоего сферического в вакууме текста будет не просто большой, а ОЧЕНЬ большой. Для специальных классов текстов (например -- исходников программ) предпосчитанные спецсловари создаются, и неплохо работают. (Ответить) (Ветвь дискуссии)

	asocio@lj 2013-02-26 14:52 (ссылка)
	Я выше написал - если мы возьмём крупную видеотеку или медиатеку и посчитаем статистические последовательности, неужто не будет приличного сжатия? Просто на практике не знаю, насколько там всё плохо внутри видео и картинок. То, что они внутри себя не повторяются - это понятно, но кто сказал, что они не похожи друг на друга? (Ответить) (Уровень выше) (Ветвь дискуссии)

shark_ru@lj 2013-02-26 15:06 (ссылка)

Статистические характеристики крупной медиатеки будут близки к таковым у белого шума. Словарь для потока с такой статистической характеристикой вам потребуется чуть менее, чем бесконечный. Я ж говорю, для специфических классов текстов это может проканать. Например, для всех диснеевских мультиков, оцифрованных в векторе и сохранённых в специальном объектном формате с семантической разметкой (т.е., грубо говоря, с пометками "волк", "мальчик", "глаза принцессы", "ухмылка злодея"). Тем более, что они, похоже, и лепятся-таки из библиотечных объектов. А вот как только вы к такой выборке добавите "Терминатор-3", тут-то вам боглах и нарисуется. (Ответить) (Уровень выше) (Ветвь дискуссии)

	asocio@lj 2013-02-26 15:12 (ссылка)
	Мы все эти фильмы видим по-разному, а для вселенной это белый шум. И правда - пичалька. (Ответить) (Уровень выше) (Ветвь дискуссии)

	n0kk@lj 2013-02-26 15:34 (ссылка)
	Пичалька на самом деле чуть больше, чем кажется. В её состав можно смело включить - инфраструктуру - производственно-технологический уровень - уровень развития и степень внедрения фундаментальных наук - наличие прикладных задач. Давным-давно ещё в советском МГУ был разработан ПК "Ириша". На химическом, между прочим, факультете. (Ответить) (Уровень выше)

	rbs_vader@lj 2013-02-26 21:35 (ссылка)
	Создатели облачных хранилищ похожими средствами уже пользуются. Т.е., не хранят сотни раз один и тот же файл, пусть с разными именами. Думаю, методика будет развиваться и дальше, благо, на таких масштабах она и выигрыш даёт. (Ответить) (Уровень выше) (Ветвь дискуссии)

	gubern@lj 2013-02-27 01:45 (ссылка)
	Вместо файла в документ подставляется хэш содержимого, однозначно указывающий на место в хранилище, да. Словарь хранится в некоем одном месте и кочует куда надо необходимыми частями. Проблема возникает как только выходим за пределы хранилища. (Ответить) (Уровень выше) (Ветвь дискуссии)

	rbs_vader@lj 2013-02-27 09:27 (ссылка)
	Ну, аналогия с Большим Всепланетным Информаторием. Причём, конечно, таким, чтобы хранимые данные нельзя было удалить "по требованию властей". (Ответить) (Уровень выше)

marcuscrassius@lj 2013-02-27 02:45 (ссылка)

Там это называется "дедупликация", и в зависимости от реализации может быть как весьма похожей на обсуждаемый алгоритм, так и не очень. Например, "не хранят сотни раз" не просто файл, а некоторую последовательность блоков, которыми файл представляется в используемой системе хранения данных. Т.е., если блок (или несколько) встречается в нескольких разных файлах (всевозможные заголовки, структуры, просто случайные совпадения) — физически он будет хранится только один раз, в остальных местах будет жить только ссылка на этот физически хранимый блок. И вот тут, да, можно однажды упереться в ту же проблему: чем больше данных — тем больше размер ссылки. (Ответить) (Уровень выше) (Ветвь дискуссии)

	rbs_vader@lj 2013-02-27 09:29 (ссылка)
	Дада, я именно про это. (Ответить) (Уровень выше)

	silly_sad@lj 2013-02-27 05:02 (ссылка)
	> Словарь для некоего сферического в вакууме текста будет не просто большой, а ОЧЕНЬ большой. он не будет ОЧЕНЬ большой. он будет равен самому тексту. (Ответить) (Уровень выше)

	pssshik@lj 2013-02-26 14:50 (ссылка)
	Есть старый добрый алгоритм, где словарь генерится на лету из потока байтов - гзип по-моему им балуется. Но даже для файла на 2 гб, заполненном одними нолями, эффективность сжатия определяется размером словаря, который считается "как-то так". А вообще умные погромисты знают, что сжатие ниже энтропии в принципе нвзмжне. (Ответить)

(Комментарий удалён)

	asocio@lj 2013-02-26 14:56 (ссылка)
	(Ответить) (Уровень выше) (Ветвь дискуссии)

	shark_ru@lj 2013-02-26 15:13 (ссылка)
	В каждой шутке есть доля шутки. Вот у вас есть кодовый поток. Каждое слово потока -- индекс в словаре. Теперь вам надо для этого индекса получить значение исходного текста. "Улавливаешь?"(Ц) (Ответить) (Уровень выше) (Ветвь дискуссии)

	asocio@lj 2013-02-26 15:15 (ссылка)
	Вот так как-то http://asocio.livejournal.com/910140.html?thread=18976572#t18976572 (Ответить) (Уровень выше)

(Комментарий удалён)

	asocio@lj 2013-02-26 15:17 (ссылка)
	Дооо, а вот для музыки есть идеальный архиватор mid. Лет пятнадцать назад на Yamaha это звучало даже круто (или мне казалось, конечно). Жаль, что голос там не эмулировался, а то можно было и песни тогой-т... (Ответить) (Уровень выше) (Ветвь дискуссии)

	stealthy_shadow@lj 2013-02-26 15:31 (ссылка)
	Бугагашечка! Посмотрите на рутрекере размеры библиотек под синтезаторы! (Ответить) (Уровень выше)

	shark_ru@lj 2013-02-26 15:34 (ссылка)
	Не, а чо, а чо? Голос-то, теоретически, тоже раскладывается на фонемы. Есть нюансы для разных языков, но это пофиг. Так что миди для голоса -- дело техники. А совмещение миди для музыки с миди для голоса и с миди для мультиков -- дело недалёкого будущего (http://youtu.be/DTXO7KGHtjI). (Ответить) (Уровень выше)

osidorkin@lj 2013-02-26 15:07 (ссылка)

Словарь (то есть пары "ключ - значение") как раз создается для определенного рода данных. Если вероятность встретить одну определенную последовательность больше, чем другую - то мы можем сопоставить более частым значениям более короткий ключ, а более редким - более длинным и иметь с этого некоторую выгоду. При этом вероятности встретить разные последовательности выравниваются, то есть до бесконечности сжимать нельзя - только до определенного вполне известного предела (иначе потом нельзя будет гарантированно разжать). В вузах есть предмет "Теория информации", где вся математика изложена - учебники можно найти. Словарь для полностью случайных данных будет иметь ключ равный по длине значению - и выигрыша не будет ("слов" будет так много, что номер слова будет иметь такую же длину как и само слово). Такой подход применяется в интернет протоколах (ключом выступает URL) и в большинстве архиваторов, но он далеко не универсален. (Ответить) (Ветвь дискуссии)

	asocio@lj 2013-02-26 15:14 (ссылка)
	Я как раз пытаюсь выразить надежду, что смысловые единицы типа "Фильм", "Изображение", "Звук" не являются в полной мере абсолютно случайными данными - хотя мне вот здесь говорят, что таки-да. (Ответить) (Уровень выше) (Ветвь дискуссии)

	shark_ru@lj 2013-02-26 15:19 (ссылка)
	Вы изобрели кодирование Хаффмана. Это добрый знак ;) (Ответить) (Уровень выше) (Ветвь дискуссии)

	asocio@lj 2013-02-26 15:20 (ссылка)
	"Одному лень искать ответ - и он находит его в книге. Другому лень искать книги - и он находит ответ" © :) (Ответить) (Уровень выше) (Ветвь дискуссии)

	osidorkin@lj 2013-02-26 15:35 (ссылка)
	Есть и обратная сторона: перед тем, как "осчастливить" своим открытием мир, задумайтесь, почему эта идея не пришла кому-то из людей раньше вас. (Ответить) (Уровень выше)

	stealthy_shadow@lj 2013-02-26 15:33 (ссылка)
	Случайными (с т.з. теории информации) данными являются изображения, звук или фильм, уже пожатые кодеками (ака "архиваторами с потерей качества"). Дальше там сжимать некуда. (Ответить) (Уровень выше) (Ветвь дискуссии)

	ext_698144@lj 2013-02-27 06:58 (ссылка)
	На самом деле, можно, но не сильно, и что самое главное, никому это в общем не нужно. Индустрии выгоднее продавать новые, более ёмкие хранилища. (Ответить) (Уровень выше)

osidorkin@lj 2013-02-26 15:33 (ссылка)

Да, и IMDB (как база фильмов), и ISBN вполне себе существуют, "сжимая" фильмы и книги до набора цифр. Но чтобы "разжать" надо скачать все фильмы (или книги), составляющие базу. Базы музыки тоже существуют. Все написанные книги - да, можно сохранить на вполне современный жесткий диск (но копирайт). С фильмами и музыкой - сложнее, а в свете распространения фотоаппаратов, "словарь" изображений очень быстро будет устаревать. (Ответить) (Уровень выше) (Ветвь дискуссии)

	shark_ru@lj 2013-02-26 15:38 (ссылка)
	> а в свете распространения фотоаппаратов, "словарь" изображений очень быстро будет устаревать. Актуальным станет строительство заводов по сжиганию фотографов. (Ответить) (Уровень выше) (Ветвь дискуссии)

	ext_698144@lj 2013-02-27 07:00 (ссылка)
	Обеспечить население заводами по сжиганию фотографов - задача посложнее написания суперархиватора. (Ответить) (Уровень выше)

	ex_tranceri@lj 2013-02-26 15:51 (ссылка)
	погуглите "компрессор на змеинном масле". (http://old.computerra.ru/focus/272593/) (Ответить)

	_stilgar@lj 2013-02-26 15:56 (ссылка)
	А как по-вашему, гугль хранит весь интернет в кэшах? (Ответить)

	sleeping_death@lj 2013-02-26 16:13 (ссылка)
	отличная идея! для твоих постов надо создать словарь, они-то точно будут до нескольких байт ужиматься, бгг. (Ответить) (Ветвь дискуссии)

	prilezhny@lj 2013-02-26 16:56 (ссылка)
	Aaaaaaaaa (Ответить) (Уровень выше)

	anonim_legion@lj 2013-02-26 17:07 (ссылка)
	Вы долларовый миллионер? (Ответить) (Уровень выше) (Ветвь дискуссии)

	ex_tranceri@lj 2013-02-27 00:40 (ссылка)
	идет к успеху (Ответить) (Уровень выше)

abbot@lj 2013-02-26 17:37 (ссылка)

Есть еще один момент, алгоритмический. Разжать-то по такому словарю получится условно быстро. А вот сжать... Очень уж сложно найти правильные совпадения в таком словаре. Вон, похожие по объему вычислений идеи бродят уже много лет без практически пригодной реализации - почитайте про фрактальное сжатие изображений, genetic-algorithm based image compression, ну и еще вот это советую послушать: http://countercomplex.blogspot.co.uk/2011/10/algorithmic-symphonies-from-one-line-of.html. Именно что "весь фильм во много гигабайт в несколько килобайт". Найти бы еще эти несколько килобайт. (Ответить)

	her_shadow@lj 2013-02-26 17:50 (ссылка)
	Оно ведь как - то, для чего большой словарь был бы полезен, и так более чем хорошо сжимается. Например, текст. То, что не очень хорошо сжимается - там увеличение словаря вряд ли сколь-нибудь существенно поможет. (Ответить)

ultimaguardian@lj 2013-02-26 17:58 (ссылка)

Нужно чтобы Бабушкин закончил свой арихватор ему нужно обратиться в сколково там как раз не хватает таких иноваций о жадных воробуржуях бизнесмен Александр Лебедев (№89 в российском рейтинге Forbes, состояние $1,1 млрд) выдвинул в совет директоров авиакомпании своего годовалого сына Егора Хорошо еще не домашних животных)) а то сидели бы в совете кот, собака и хомяк, боженька убей их всех.... (Ответить) (Ветвь дискуссии)

	silly_sad@lj 2013-02-27 05:18 (ссылка)
	конь в сенате уже был (Ответить) (Уровень выше)

	_iga@lj 2013-02-26 19:02 (ссылка)
	Такой архиватор давным-давно изобрёл поручик Ржевский ("анекдот номер 21"). (Ответить)

	vlkamov@lj 2013-02-27 01:39 (ссылка)
	Коэффициент сжатия около 3-х, что хуже, чем у обычных архиваторов. (Ответить)

	humpty_dumpty@lj 2013-02-27 02:03 (ссылка)
	Эффективность словарного алгоритма определяется соотношением размера медианной ссылки на элемент словаря к размеру этого самого элемента. Поэтому большие словари не имеют смысла. Хотя для библиотек и справочных систем реально применить нечто подобное заменив наиболее часто встречающиеся слова. (Ответить)

	northas@lj 2013-02-27 07:14 (ссылка)
	Упрётся в доступ к диску. (Ответить)

ultimaguardian@lj 2013-02-27 15:05 (ссылка)

Уважаемый Асоцио немного новостей Хозяева жизни и государства не мог не написать о рашкованских колобках "К стойке бизнес-класса подошла компания из двух мужчин и двух женщин. Один из мужчин был одет в красную куртку с крупной надписью "Россия" и гербом государства, при этом он находился в алкогольном опьянении. Женщина, которая находилась с ним, боясь, чтобы он не потерялся, громко звала его: "Мой хомячок!". А он в ответ громко матерился", - описал Куземин "Известиям" те события. По словам адвоката, он сделал мужчине замечание, указав на то, что вокруг полно женщин и детей, но сквернослов в ответ набросился на него. "Бил, кричал, что прилетишь в Москву, я тебя убью, голову тебе оторву" www. newsru.com/russia/27feb2013/avia.html или вот еще новость слаще этой депутата подкараулили, нападавший был в маске. Он жестоко избил Цедилкина, применил электрошокер, а затем столкнул в подвал, где продолжил избивать. Пострадавшего на «скорой» доставили в больницу.)))) Боженьке слава (Ответить)

	jee_aka_ajiko@lj 2013-02-28 16:02 (ссылка)
	Не дай конечно бог подать идею очередному гениальному петрикошкольнику, но мне по сабжу вспомнилось мое студенческое увлечение алгоритмами фрактального сжатия изображений. Если б удалось реализовать - три порядка сжатия возможно были бы вполне достижимы. Вот только воробуржуи и тут мешают - алгоритмов еще нет, а патенты уже есть. Воробуржуи не наши, зарубежные. (Ответить)