Рубрика «сжатие данных»

Парадоксы о сжатии данных - 1 Задача сжатия данных в своей простейшей форме может относиться к числам и их обозначениям. Числа можно обозначать числительными («одиннадцать» для числа 11), математическими выражениями («два в двадцатой» для 1048576), строковыми выражениями («пять девяток» для 99999), именами собственными («число зверя» для 666, «год смерти Тьюринга» для 1954), или произвольными их комбинациями. Годится любое обозначение, по которому собеседник сможет однозначно определить, о каком числе речь. Очевидно, что сообщить собеседнику «факториал восьми» эффективнее, чем эквивалентное обозначение «сорок тысяч триста двадцать». Здесь возникает логичный вопрос: какое обозначение для заданного числа самое короткое?

Философ Бертран Рассел в 1908 опубликовал «парадокс Берри», который затрагивает вопрос обозначений чисел с противоположной стороны: какое самое маленькое число, для обозначения которого недостаточно восьмидесяти букв?
Такое число обязано существовать: из восьмидесяти русских букв и пробелов можно составить всего 3480 обозначений, значит, с использованием восьмидесяти букв можно обозначить не более 3480 чисел. Значит, некое число, не большее чем 3480, обозначить таким образом невозможно.

Значит, этому числу будет соответствовать обозначение «самое маленькое число, для обозначения которого недостаточно восьмидесяти букв», в котором всего 78 букв! С одной стороны, это число обязано существовать; с другой, если это число существует, то его обозначение ему не соответствует. Парадокс!Читать полностью »

Базы данных можно реализовать с помощью Excel, GSheet или при помощи больших ORM систем. В своей практике бизнес-аналитика я сталкивался с разными решениями. А поскольку в бизнес-анализ я пришёл из финансов и аудита, то каждый раз встречая новую систему задавался вопросами — чем все они отличаются друг от друга и какие задачи решают? Некоторые ответы нашёл. В этой статье будет рассмотрено два основных назначения баз данных:

1 — учёт операций,
2 — анализ данных

Читать полностью »

Эта статья может быть интересна тем, кто занимается сжатием данных или хочет написать собственный архиватор.

Энтропийное кодирование rANS или как написать собственный архиватор - 1

Статья написана, в основном, по материалам блога, который ведёт Fabian Giesen.
Читать полностью »

Меня зовут Илья Гольдфарб, я разработчик интерфейсов Яндекса. Мне интересно следить за тем, как развиваются инструменты для сборки фронтенда, поэтому я стараюсь изучать изменения в каждом релизе популярных решений.

В преддверии выхода пятой версии webpack я хочу рассказать о его, казалось бы, минорном релизе 4.26.0 от 19 ноября 2018 года, где неожиданно и без объявления войны изменилась версия минификатора по умолчанию. Раньше это был пакет UglifyJS, теперь же используется Terser, форк UglifyES — ветки UglifyJS, которая может сжимать и ES5, и ES6 код. Terser появился, когда основной майнтейнер отказался поддерживать и развивать UglifyES. Впрочем, UglifyJS тоже прекратил свое развитие с августа 2018 года, когда был выпущен последний релиз. В новом форке исправили некоторые баги и немного отрефакторили код.

API этих минификаторов совместимый, но результат сжатия они выдают разный. Обычно изменения подобного уровня происходят лишь в мажорных, а не минорных обновлениях. Из-за этого многие разработчики могут не обратить внимания на нововведение. Конечно, в большинстве случаев всё будет работать, но никто не хочет стать тем, кто на продакшне своего проекта получит баги из-за системы сборки и минификации.

Вся эта история подвигла меня провести маленькое личное исследование сжатия. Вот вопросы, которые я задал:

  • Что лучше сжимает ES5, Terser или UglifyJS?
  • Что быстрее загружается: сжатая версия ES5 от Terser или от UglifyJS?
  • Какая версия весит больше: ES5 или ES6? И как на это влияет TypeScript?
  • Большая ли разница между настройками по умолчанию и ручной настройкой?
  • А если не webpack? Кто выдаёт сборку меньшего размера, Rollup или webpack?

Читать полностью »

Вступление

В данной статье я расскажу об известном алгоритме Хаффмана, а также о его применении в сжатии данных.

В результате напишем простенький архиватор. Об этом уже была статья на Хабре, но без практической реализации. Теоретический материал текущего поста взят из книги Роберта Лафоре «Data Structures and Algorithms in Java». Итак, все под кат!
Читать полностью »

Рады Вас приветствовать. Прошел почти год с момента публикации последней статьи и мы готовы рассказать, что происходило с самим алгоритмом и как тут замешано дельта-кодирование.

image

Вступление.

После выпуска статьи об улучшениях алгоритма Broo, мы столкнулись с преградой в улучшении уровня компрессии и производительности, а именно нельзя было улучшить уровень компрессии не ухудшив скорость распаковки и наоборот. Сразу сделаю оговорку, улучшения были сделаны без ущерба для других характеристик алгоритма, но эти изменения незначительные, дальше мы напишем об этих изменениях. Так вот, после, мы задумались, где мы можем применить накопленную экспертизу и знания в похожем направлении. И выбор пал на Читать полностью »

Автор электронной книги — Эдди Османи, один из руководителей разработки Google Chrome

tl;dr

Cжатие изображений всегда должно быть автоматизировано

Оптимизацию графики обязательно надо автоматизировать. О ней легко забыть, рекомендации меняются, да и сам контент может легко проскользнуть мимо конвейера сборки. Для автоматизации при сборке используйте imagemin или libvips. Есть и много других.

Большинство CDN (например, Akamai) и сторонних решений вроде Cloudinary, imgix, Fastly Image Optimizer, Instart Logic SmartVision и ImageOptim API предлагают комплексные автоматизированные решения для оптимизации изображений.

На чтение статей и настройку конфигурации вы потратите время, которое дороже оплаты их услуг (у Cloudinary есть бесплатный тариф). Но если всё-таки не хотите отдавать работу на аутсорсинг по соображениям стоимости или из-за дополнительной latency, то выбирайте приведённые выше варианты с открытым исходным кодом. Проекты Imageflow или Thumbor предлагают альтернативу на собственном хостинге.
Читать полностью »

Привет, как вы уже поняли, это продолжение моей истории реверс-инжиниринга и портирования «Нейроманта».

Реверсим «Нейроманта». Часть 4: Звук, анимация, Хаффман, гитхаб - 1

Реверсим «Нейроманта». Часть 1: Спрайты
Реверсим «Нейроманта». Часть 2: Рендерим шрифт
Реверсим «Нейроманта». Часть 3: Добили рендеринг, делаем игру

Сегодня начнём с двух хороших новостей:

  • во-первых, я больше не один — к проекту присоединился и уже успел внести ощутимый вклад пользователь viiri;
  • во-вторых, теперь у нас есть открытый репозиторий на github.

В целом, дела идут очень неплохо и, возможно, скоро мы получим хоть сколько-то играбельный билд. А под катом, как обычно, поговорим о том, чего и каким образом удалось достичь на текущий момент.

Читать полностью »

песочница

Свойства простых чисел редко позволяют работать с ними иначе, чем в виде заранее вычисленного массива — и желательно как можно более объемного. Естественный формат хранения в виде целых чисел той или иной разрядности страдает при этом некоторыми недостатками, которые становятся существенными при росте объема данных.

 

Так, формат 16-разрядных беззнаковых целых при размере такой таблицы около 13 килобайт вмещает всего лишь 6542 простых числа: вслед за числом 65531 идут значения более высокой разрядности. Такая таблица годится разве что в качестве игрушки.

 

Наиболее ходовой в программировании формат 32-разрядных целых выглядит значительно солиднее — он позволяет хранить около 203 млн простых. Но такая таблица занимает уже около 775 мегабайт.

 

Еще больше перспектив у 64-разрядного формата. Однако при теоретической мощности порядка 1e+19 значений, таблица имела бы размер 64 экзабайта.

Читать полностью »

«Цель этого курса — подготовить вас к вашему техническому будущему.»

imageПривет. Помните офигенную статью «Вы и ваша работа» (+219, 2442 в закладки, 394k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Мы ее переводим, ведь мужик дело говорит.

Это книга не просто про ИТ, это книга про стиль мышления невероятно крутых людей. «Это не просто заряд положительного мышления; в ней описаны условия, которые увеличивают шансы сделать великую работу.»

Мы уже перевели 28 (из 30) глав. И ведем работу над изданием «в бумаге».

Теория кодирования — I

Рассмотрев компьютеры и принцип их работы, сейчас мы будем рассматривать вопрос представления информации: как компьютеры представляют информацию, которую мы хотим обработать. Значение любого символа может зависит от способа его обработки, у машины нет никакого определенного смысла у используемого бита. При обсуждении истории программного обеспечения 4 главе мы рассматривали некоторый синтетический язык программирования, в нём код инструкции останова совпадал с кодом других инструкций. Такая ситуация типична для большинства языков, смысл инструкции определяется соответствующей программой.

Для упрощения проблемы представления информации рассмотрим проблему передачи информации от точки к точке. Этот вопрос связан с вопросом сохранения информация. Проблемы передачи информации во времени и в пространстве идентичны. На рисунке 10.1 представлена стандартная модель передачи информации.

image

Рисунок 10.1
Читать полностью »