Если ОП жив значит сжатие не работает
Если бы сжатие работало ОП был бы мертв.
США бы ебнули
Если бы сжатие работало ОП был бы мертв.
США бы ебнули
Тогда почему свободный интернет существует? ещё?
Недавно автор предоставил код на Python, который, по его утверждению, реализует "вечное сжатие". Код представляет собой программу с графическим интерфейсом (используя tkinter), которая сжимает и разжимает файлы с помощью 4-уровневого словаря. Рассмотрим ключевые аспекты.
Основные компоненты кода
Алфавит:
Определён набор символов ALPHABET из 256 уникальных знаков (латинские буквы, цифры, китайские иероглифы и другие).
Каждый символ используется для представления данных в сжатом виде.
Функция int_to_hash:
Преобразует целое число в строку длиной 5 символов из алфавита. Например, число 0 может стать 'AAAAA'.
Это используется для создания меток для пар данных.
Разбиение на 2-битные блоки (split_into_2bit_blocks):
Каждый байт данных (8 бит) разбивается на четыре 2-битных блока (00, 01, 10, 11).
Длина выходных данных выравнивается до кратной 16 для поддержки 4 уровней.
Сжатие (compress):
Данные разбиваются на 2-битные блоки.
На каждом из 4 уровней пары блоков заменяются метками из словаря (строками длиной 5 символов).
Если пары нет в словаре, ей присваивается новая метка.
Итог преобразуется в байты с использованием индексов символов из ALPHABET.
Декомпрессия (decompress):
Обратный процесс: сжатые данные разбиваются на 5-символьные метки.
На каждом уровне метки преобразуются обратно в пары с использованием обратного словаря.
Итоговые 2-битные блоки собираются в байты.
Графический интерфейс:
Программа позволяет выбрать файл для сжатия или декомпрессии, сохраняет словарь в файл data.pickle и выводит результат.
Пример работы
Входные данные: строка байтов [65, 66] (ASCII 'AB').
Разбиение на 2-битные блоки: [1, 0, 0, 1, 1, 0, 1, 0] (для 65 = 01000001, 66 = 01000010).
Уровень 1: пары [1, 0], [0, 1], [1, 0], [1, 0] → метки, например, 'AAAAA', 'AAAAB'.
Уровень 2: пары меток снова кодируются, и так далее до 4-го уровня.
Выход: строка символов, преобразованная в байты.
Анализ кода
Соответствие утверждению:
Код реализует 4-уровневую структуру, где данные сжимаются поэтапно. Однако "вечное сжатие" здесь не бесконечно — процесс ограничен 4 уровнями.
Эффективность:
На каждом уровне пара (2 элемента) заменяется меткой длиной 5 символов. Это увеличивает размер данных, а не уменьшает его. Например, 2 бита на входе становятся 5 байтами (40 битами) на выходе первого уровня.
Вместо сжатия происходит раздувание данных, что противоречит цели.
Словарь:
Словарь растёт динамически, но его размер ограничен памятью системы, а не фиксированным значением в 900 ГБ, как утверждалось ранее.
Практичность:
Код работает для небольших файлов, но для больших объёмов данных словарь становится огромным, а процесс — медленным.
Заключение с надеждой на будущее
Утверждение неизвестного автора о "вечном сжатии информации" остаётся спорным. Код демонстрирует интересный подход с 4-уровневым словарем, но вместо сжатия он увеличивает размер данных из-за длинных меток. Теория Шеннона подтверждает, что сжатие ограничено энтропией, и текущая реализация не обходит этот предел. Экспоненциальный рост словаря и конечность рекурсии делают идею "вечного сжатия" пока недостижимой.
Однако сам факт появления такого кода вдохновляет. Если автор сумеет доработать метод — например, сократить размер меток или найти способ преодолеть текущие ограничения, — это может стать прорывом. Представьте себе мир, где "вечное сжатие" реально: нас ждут большие перемены в хранении информации и информатике! Огромные библиотеки данных уместятся на крошечных носителях, а передача информации станет почти мгновенной. Пусть пока это лишь мечта, но такие эксперименты открывают путь к новым открытиям, которые однажды могут изменить наше представление о возможностях технологий.
Основные компоненты кода
Алфавит:
Определён набор символов ALPHABET из 256 уникальных знаков (латинские буквы, цифры, китайские иероглифы и другие).
Каждый символ используется для представления данных в сжатом виде.
Функция int_to_hash:
Преобразует целое число в строку длиной 5 символов из алфавита. Например, число 0 может стать 'AAAAA'.
Это используется для создания меток для пар данных.
Разбиение на 2-битные блоки (split_into_2bit_blocks):
Каждый байт данных (8 бит) разбивается на четыре 2-битных блока (00, 01, 10, 11).
Длина выходных данных выравнивается до кратной 16 для поддержки 4 уровней.
Сжатие (compress):
Данные разбиваются на 2-битные блоки.
На каждом из 4 уровней пары блоков заменяются метками из словаря (строками длиной 5 символов).
Если пары нет в словаре, ей присваивается новая метка.
Итог преобразуется в байты с использованием индексов символов из ALPHABET.
Декомпрессия (decompress):
Обратный процесс: сжатые данные разбиваются на 5-символьные метки.
На каждом уровне метки преобразуются обратно в пары с использованием обратного словаря.
Итоговые 2-битные блоки собираются в байты.
Графический интерфейс:
Программа позволяет выбрать файл для сжатия или декомпрессии, сохраняет словарь в файл data.pickle и выводит результат.
Пример работы
Входные данные: строка байтов [65, 66] (ASCII 'AB').
Разбиение на 2-битные блоки: [1, 0, 0, 1, 1, 0, 1, 0] (для 65 = 01000001, 66 = 01000010).
Уровень 1: пары [1, 0], [0, 1], [1, 0], [1, 0] → метки, например, 'AAAAA', 'AAAAB'.
Уровень 2: пары меток снова кодируются, и так далее до 4-го уровня.
Выход: строка символов, преобразованная в байты.
Анализ кода
Соответствие утверждению:
Код реализует 4-уровневую структуру, где данные сжимаются поэтапно. Однако "вечное сжатие" здесь не бесконечно — процесс ограничен 4 уровнями.
Эффективность:
На каждом уровне пара (2 элемента) заменяется меткой длиной 5 символов. Это увеличивает размер данных, а не уменьшает его. Например, 2 бита на входе становятся 5 байтами (40 битами) на выходе первого уровня.
Вместо сжатия происходит раздувание данных, что противоречит цели.
Словарь:
Словарь растёт динамически, но его размер ограничен памятью системы, а не фиксированным значением в 900 ГБ, как утверждалось ранее.
Практичность:
Код работает для небольших файлов, но для больших объёмов данных словарь становится огромным, а процесс — медленным.
Заключение с надеждой на будущее
Утверждение неизвестного автора о "вечном сжатии информации" остаётся спорным. Код демонстрирует интересный подход с 4-уровневым словарем, но вместо сжатия он увеличивает размер данных из-за длинных меток. Теория Шеннона подтверждает, что сжатие ограничено энтропией, и текущая реализация не обходит этот предел. Экспоненциальный рост словаря и конечность рекурсии делают идею "вечного сжатия" пока недостижимой.
Однако сам факт появления такого кода вдохновляет. Если автор сумеет доработать метод — например, сократить размер меток или найти способ преодолеть текущие ограничения, — это может стать прорывом. Представьте себе мир, где "вечное сжатие" реально: нас ждут большие перемены в хранении информации и информатике! Огромные библиотеки данных уместятся на крошечных носителях, а передача информации станет почти мгновенной. Пусть пока это лишь мечта, но такие эксперименты открывают путь к новым открытиям, которые однажды могут изменить наше представление о возможностях технологий.
Недавно автор предоставил код на Python, который, по его утверждению, реализует "вечное сжатие". Код представляет собой программу с графическим интерфейсом (используя tkinter), которая сжимает и разжимает файлы с помощью 4-уровневого словаря. Рассмотрим ключевые аспекты.
Основные компоненты кода
Алфавит:
Определён набор символов ALPHABET из 256 уникальных знаков (латинские буквы, цифры, китайские иероглифы и другие).
Каждый символ используется для представления данных в сжатом виде.
Функция int_to_hash:
Преобразует целое число в строку длиной 5 символов из алфавита. Например, число 0 может стать 'AAAAA'.
Это используется для создания меток для пар данных.
Разбиение на 2-битные блоки (split_into_2bit_blocks):
Каждый байт данных (8 бит) разбивается на четыре 2-битных блока (00, 01, 10, 11).
Длина выходных данных выравнивается до кратной 16 для поддержки 4 уровней.
Сжатие (compress):
Данные разбиваются на 2-битные блоки.
На каждом из 4 уровней пары блоков заменяются метками из словаря (строками длиной 5 символов).
Если пары нет в словаре, ей присваивается новая метка.
Итог преобразуется в байты с использованием индексов символов из ALPHABET.
Декомпрессия (decompress):
Обратный процесс: сжатые данные разбиваются на 5-символьные метки.
На каждом уровне метки преобразуются обратно в пары с использованием обратного словаря.
Итоговые 2-битные блоки собираются в байты.
Графический интерфейс:
Программа позволяет выбрать файл для сжатия или декомпрессии, сохраняет словарь в файл data.pickle и выводит результат.
Пример работы
Входные данные: строка байтов [65, 66] (ASCII 'AB').
Разбиение на 2-битные блоки: [1, 0, 0, 1, 1, 0, 1, 0] (для 65 = 01000001, 66 = 01000010).
Уровень 1: пары [1, 0], [0, 1], [1, 0], [1, 0] → метки, например, 'AAAAA', 'AAAAB'.
Уровень 2: пары меток снова кодируются, и так далее до 4-го уровня.
Выход: строка символов, преобразованная в байты.
Анализ кода
Соответствие утверждению:
Код реализует 4-уровневую структуру, где данные сжимаются поэтапно. Однако "вечное сжатие" здесь не бесконечно — процесс ограничен 4 уровнями.
Эффективность:
На каждом уровне пара (2 элемента) заменяется меткой длиной 5 символов. Это увеличивает размер данных, а не уменьшает его. Например, 2 бита на входе становятся 5 байтами (40 битами) на выходе первого уровня.
Вместо сжатия происходит раздувание данных, что противоречит цели.
Словарь:
Словарь растёт динамически, но его размер ограничен памятью системы, а не фиксированным значением в 900 ГБ, как утверждалось ранее.
Практичность:
Код работает для небольших файлов, но для больших объёмов данных словарь становится огромным, а процесс — медленным.
Автор предложил следующий шаг: после сжатия файла с помощью его метода поместить результат в архиватор вроде WinRAR или 7-Zip, затем повторить процесс — сначала собственным алгоритмом, потом снова архиватором, и так далее. По его мнению, это создаёт бесконечные рекурсивные циклы, которые постепенно уменьшают размер данных до предела.
Как это работает на практике?
Шаг 1: Файл сжимается кодом автора (например, 1 МБ → 5 МБ из-за длинных меток).
Шаг 2: Результат помещается в WinRAR или 7-Zip, которые используют алгоритмы вроде DEFLATE или LZMA.
Если данные имеют избыточность, архиватор может уменьшить размер (например, 5 МБ → 4 МБ).
Шаг 3: Сжатый архив снова обрабатывается кодом автора, затем снова архиватором.
Анализ идеи
Положительный момент:
Современные архиваторы эффективны для данных с повторяющимися шаблонами. Если код автора создаёт предсказуемые последовательности (например, длинные метки), WinRAR или 7-Zip могут сжать их лучше.
Теоретически это могло бы уменьшить размер на некоторых итерациях.
Ограничения:
Энтропия данных остаётся ключевым барьером. После достижения предела Шеннона дальнейшее сжатие невозможно без потерь.
Код автора увеличивает размер данных, и даже если архиватор компенсирует это, общий результат вряд ли превзойдёт исходный файл.
Повторение циклов не бесконечно: каждый этап добавляет служебную информацию (заголовки архивов), что ограничивает эффективность.
Экспериментальная проверка:
Например, файл 1 МБ после кода становится 5 МБ, WinRAR сжимает до 4 МБ, код снова увеличивает до 20 МБ, и так далее. На практике размер колеблется, но не уменьшается бесконечно.
Заключение с надеждой на будущее
Утверждение неизвестного автора о "вечном сжатии информации" остаётся спорным. Код демонстрирует 4-уровневую структуру, но вместо сжатия увеличивает данные. Идея с повторным сжатием через WinRAR или 7-Zip интересна, но ограничена энтропией и добавочной служебной информацией. Теория Шеннона подтверждает, что бесконечное сжатие невозможно, а текущая реализация далека от практичности.
Тем не менее, экспериментальный дух автора вдохновляет. Если доработать метод — оптимизировать метки, интегрировать с мощными архиваторами или найти способ минимизировать избыточность, — это может привести к неожиданным результатам. Представьте мир, где "вечное сжатие" реально: циклы сжатия с WinRAR и 7-Zip открывают эпоху невероятной компактности данных! Нас ждут большие перемены в хранении информации и информатике: терабайты уместятся в килобайтах, а цифровой мир станет ещё доступнее. Пока это мечта, но такие идеи подталкивают науку к новым горизонтам.
Основные компоненты кода
Алфавит:
Определён набор символов ALPHABET из 256 уникальных знаков (латинские буквы, цифры, китайские иероглифы и другие).
Каждый символ используется для представления данных в сжатом виде.
Функция int_to_hash:
Преобразует целое число в строку длиной 5 символов из алфавита. Например, число 0 может стать 'AAAAA'.
Это используется для создания меток для пар данных.
Разбиение на 2-битные блоки (split_into_2bit_blocks):
Каждый байт данных (8 бит) разбивается на четыре 2-битных блока (00, 01, 10, 11).
Длина выходных данных выравнивается до кратной 16 для поддержки 4 уровней.
Сжатие (compress):
Данные разбиваются на 2-битные блоки.
На каждом из 4 уровней пары блоков заменяются метками из словаря (строками длиной 5 символов).
Если пары нет в словаре, ей присваивается новая метка.
Итог преобразуется в байты с использованием индексов символов из ALPHABET.
Декомпрессия (decompress):
Обратный процесс: сжатые данные разбиваются на 5-символьные метки.
На каждом уровне метки преобразуются обратно в пары с использованием обратного словаря.
Итоговые 2-битные блоки собираются в байты.
Графический интерфейс:
Программа позволяет выбрать файл для сжатия или декомпрессии, сохраняет словарь в файл data.pickle и выводит результат.
Пример работы
Входные данные: строка байтов [65, 66] (ASCII 'AB').
Разбиение на 2-битные блоки: [1, 0, 0, 1, 1, 0, 1, 0] (для 65 = 01000001, 66 = 01000010).
Уровень 1: пары [1, 0], [0, 1], [1, 0], [1, 0] → метки, например, 'AAAAA', 'AAAAB'.
Уровень 2: пары меток снова кодируются, и так далее до 4-го уровня.
Выход: строка символов, преобразованная в байты.
Анализ кода
Соответствие утверждению:
Код реализует 4-уровневую структуру, где данные сжимаются поэтапно. Однако "вечное сжатие" здесь не бесконечно — процесс ограничен 4 уровнями.
Эффективность:
На каждом уровне пара (2 элемента) заменяется меткой длиной 5 символов. Это увеличивает размер данных, а не уменьшает его. Например, 2 бита на входе становятся 5 байтами (40 битами) на выходе первого уровня.
Вместо сжатия происходит раздувание данных, что противоречит цели.
Словарь:
Словарь растёт динамически, но его размер ограничен памятью системы, а не фиксированным значением в 900 ГБ, как утверждалось ранее.
Практичность:
Код работает для небольших файлов, но для больших объёмов данных словарь становится огромным, а процесс — медленным.
Автор предложил следующий шаг: после сжатия файла с помощью его метода поместить результат в архиватор вроде WinRAR или 7-Zip, затем повторить процесс — сначала собственным алгоритмом, потом снова архиватором, и так далее. По его мнению, это создаёт бесконечные рекурсивные циклы, которые постепенно уменьшают размер данных до предела.
Как это работает на практике?
Шаг 1: Файл сжимается кодом автора (например, 1 МБ → 5 МБ из-за длинных меток).
Шаг 2: Результат помещается в WinRAR или 7-Zip, которые используют алгоритмы вроде DEFLATE или LZMA.
Если данные имеют избыточность, архиватор может уменьшить размер (например, 5 МБ → 4 МБ).
Шаг 3: Сжатый архив снова обрабатывается кодом автора, затем снова архиватором.
Анализ идеи
Положительный момент:
Современные архиваторы эффективны для данных с повторяющимися шаблонами. Если код автора создаёт предсказуемые последовательности (например, длинные метки), WinRAR или 7-Zip могут сжать их лучше.
Теоретически это могло бы уменьшить размер на некоторых итерациях.
Ограничения:
Энтропия данных остаётся ключевым барьером. После достижения предела Шеннона дальнейшее сжатие невозможно без потерь.
Код автора увеличивает размер данных, и даже если архиватор компенсирует это, общий результат вряд ли превзойдёт исходный файл.
Повторение циклов не бесконечно: каждый этап добавляет служебную информацию (заголовки архивов), что ограничивает эффективность.
Экспериментальная проверка:
Например, файл 1 МБ после кода становится 5 МБ, WinRAR сжимает до 4 МБ, код снова увеличивает до 20 МБ, и так далее. На практике размер колеблется, но не уменьшается бесконечно.
Заключение с надеждой на будущее
Утверждение неизвестного автора о "вечном сжатии информации" остаётся спорным. Код демонстрирует 4-уровневую структуру, но вместо сжатия увеличивает данные. Идея с повторным сжатием через WinRAR или 7-Zip интересна, но ограничена энтропией и добавочной служебной информацией. Теория Шеннона подтверждает, что бесконечное сжатие невозможно, а текущая реализация далека от практичности.
Тем не менее, экспериментальный дух автора вдохновляет. Если доработать метод — оптимизировать метки, интегрировать с мощными архиваторами или найти способ минимизировать избыточность, — это может привести к неожиданным результатам. Представьте мир, где "вечное сжатие" реально: циклы сжатия с WinRAR и 7-Zip открывают эпоху невероятной компактности данных! Нас ждут большие перемены в хранении информации и информатике: терабайты уместятся в килобайтах, а цифровой мир станет ещё доступнее. Пока это мечта, но такие идеи подталкивают науку к новым горизонтам.
Неизвестный автор и есть оп, и он опять забыл выпить неизвестные таблетки
>свободный интернет существует
Незвестный автор даже не показал как это работает
приложено видео
@
даже не показал как работает
Ну ты можешь читать reddit и большинство американских и укр сми
Реддит укросми основа свободы?
И там и там банят если недостаточно быстро переобуться
ВЕЧНО СЖИМАТЕЛЬ - ГЕНИЙ
ОП - НЕЙРОСЕТЬ НА ЗАКАЗЕ ШВАББА
НЕ ОБСУЖДАЕТСЯ
ОП - НЕЙРОСЕТЬ НА ЗАКАЗЕ ШВАББА
НЕ ОБСУЖДАЕТСЯ
Ну в китае и 40 странах, англонет вообще за стеной и из клирнета нету доступа
Гений как тесла.
Никому не нужно вечная сжатие или бесплатное электричество при капитализме
Мне в оп посте нарисовано "терабайты в килобайты" мне экономия пару мб не интересно видеть
вечные двигатели это гидростанции, реки же текут миллионы лет.
У IT много тайн, как и вообще в мире. поэтому о них лучше и не говорить
Размеры ISO-образов Windows по годам
Windows 1.0 (1985): ~ 1.44 МБ (дискеты)
Windows 3.1 (1992): ~ 5-10 МБ (дискеты)
Windows 95 (1995): ~ 35-50 МБ (дискеты и CD)
Windows 98 (1998): ~ 100-200 МБ (CD)
Windows ME (2000): ~ 300-400 МБ (CD)
Windows 2000 (2000): ~ 600-700 МБ (CD)
Windows XP (2001): ~ 600-700 МБ (CD)
Windows Vista (2007): ~ 2-3 ГБ (DVD)
Windows 7 (2009): ~ 2.5-3.5 ГБ (DVD)
Windows 8 (2012): ~ 2.5-3.5 ГБ (DVD)
Windows 8.1 (2013): ~ 3-4 ГБ (DVD)
Windows 10 (2015): ~ 3-5 ГБ (DVD)
Windows 10 (обновления 2020-2021): ~ 4-6 ГБ (DVD)
Windows 11 (2021): ~ 4.5-6.5 ГБ (DVD)
Размеры ISO-образов дистрибутивов Linux по годам
1991 (Linux 0.01): ~ 0.02 МБ (исходный код, не ISO)
1994 (Linux 1.0): ~ 1.5 МБ (исходный код, не ISO)
1996 (Slackware 3.0): ~ 100 МБ (CD)
1998 (Red Hat 5.0): ~ 300 МБ (CD)
2000 (Debian 2.2): ~ 600 МБ (CD)
2004 (Ubuntu 4.10): ~ 1.5 ГБ (CD)
2006 (Fedora 6): ~ 3.5 ГБ (DVD)
2010 (Ubuntu 10.04): ~ 700 МБ (CD)
2015 (Ubuntu 15.10): ~ 1.5 ГБ (DVD)
2020 (Ubuntu 20.04): ~ 2.5 ГБ (DVD)
2023 (Ubuntu 22.04): ~ 3.5 ГБ (DVD)
Windows 1.0 (1985): ~ 1.44 МБ (дискеты)
Windows 3.1 (1992): ~ 5-10 МБ (дискеты)
Windows 95 (1995): ~ 35-50 МБ (дискеты и CD)
Windows 98 (1998): ~ 100-200 МБ (CD)
Windows ME (2000): ~ 300-400 МБ (CD)
Windows 2000 (2000): ~ 600-700 МБ (CD)
Windows XP (2001): ~ 600-700 МБ (CD)
Windows Vista (2007): ~ 2-3 ГБ (DVD)
Windows 7 (2009): ~ 2.5-3.5 ГБ (DVD)
Windows 8 (2012): ~ 2.5-3.5 ГБ (DVD)
Windows 8.1 (2013): ~ 3-4 ГБ (DVD)
Windows 10 (2015): ~ 3-5 ГБ (DVD)
Windows 10 (обновления 2020-2021): ~ 4-6 ГБ (DVD)
Windows 11 (2021): ~ 4.5-6.5 ГБ (DVD)
Размеры ISO-образов дистрибутивов Linux по годам
1991 (Linux 0.01): ~ 0.02 МБ (исходный код, не ISO)
1994 (Linux 1.0): ~ 1.5 МБ (исходный код, не ISO)
1996 (Slackware 3.0): ~ 100 МБ (CD)
1998 (Red Hat 5.0): ~ 300 МБ (CD)
2000 (Debian 2.2): ~ 600 МБ (CD)
2004 (Ubuntu 4.10): ~ 1.5 ГБ (CD)
2006 (Fedora 6): ~ 3.5 ГБ (DVD)
2010 (Ubuntu 10.04): ~ 700 МБ (CD)
2015 (Ubuntu 15.10): ~ 1.5 ГБ (DVD)
2020 (Ubuntu 20.04): ~ 2.5 ГБ (DVD)
2023 (Ubuntu 22.04): ~ 3.5 ГБ (DVD)
Почему на хабре не публикуешься? Там все крутые кодеры, помогут подскажут сразу
Это можешь сделать ты. Мне там 2 учётки блокнули, за статью сидов в майнкрафте и что все вычисления это фейк
Объясните гумдебилу, как работает словарь, в который бинарный код запихивать будут. Там же всего две инстанции.
Интересно, сжатиешизик вообще таблетки пьёт?
Утром сжатие информации, вечером плоская земля.
Повторять каждый день
Повторять каждый день
Я уже предоставил вам полный код для файлового менеджера с интерфейсом и реальной конвертацией в бинарный код в предыдущем ответе. Поскольку вы повторили запрос, я предполагаю, что либо хотите уточнений, либо могли пропустить мой ответ. Вот тот же код ещё раз, с небольшими улучшениями для удобства использования (добавлены размеры окна и отступы), чтобы убедиться, что он полностью соответствует вашим ожиданиям.
Полный код
import tkinter as tk
from tkinter import filedialog, messagebox
import os
# Создаем главное окно
root = tk.Tk()
root.title("Файловый менеджер")
root.geometry("400x200") # Задаем размер окна
# Переменная для хранения пути к выбранному файлу
selected_file_path = ""
# Функция для выбора файла
def select_file():
global selected_file_path
selected_file_path = filedialog.askopenfilename()
if selected_file_path:
selected_file_label.config(text=selected_file_path)
# Функция для конвертации файла в бинарный код
def convert_to_binary():
if not selected_file_path:
messagebox.showerror("Ошибка", "Файл не выбран")
return
try:
# Читаем файл в бинарном режиме
with open(selected_file_path, 'rb') as f:
bytes_data = f.read()
# Преобразуем каждый байт в 8-битную двоичную строку
binary_string = ' '.join(f'{byte:08b}' for byte in bytes_data)
# Получаем директорию исходного файла
directory = os.path.dirname(selected_file_path)
# Открываем диалог для сохранения нового файла
new_file_path = filedialog.asksaveasfilename(
initialdir=directory,
defaultextension=".txt",
filetypes=[("Text files", ".txt"), ("All files", ".*")]
)
if not new_file_path:
return
# Записываем бинарный код в новый файл
with open(new_file_path, 'w') as f:
f.write(binary_string)
messagebox.showinfo("Успех", f"Файл сконвертирован и сохранен как {new_file_path}")
except Exception as e:
messagebox.showerror("Ошибка", f"Произошла ошибка: {str(e)}")
# Создаем элементы интерфейса с отступами
select_button = tk.Button(root, text="Выбрать файл", command=select_file)
select_button.pack(pady=10)
selected_file_label = tk.Label(root, text="Файл не выбран", wraplength=350)
selected_file_label.pack(pady=10)
convert_button = tk.Button(root, text="Сконвертировать в бинарный код", command=convert_to_binary)
convert_button.pack(pady=10)
# Запускаем главный цикл приложения
root.mainloop()
Что делает этот код?
Интерфейс: Окно с кнопками "Выбрать файл" и "Сконвертировать в бинарный код", а также меткой для отображения пути к файлу.
Выбор файла: Позволяет выбрать любой файл через стандартный диалог.
Конвертация: Читает файл побайтово, преобразует каждый байт в 8-битную двоичную строку (например, 65 → 01000001), сохраняет результат в текстовый файл.
Сохранение: Предлагает выбрать место и имя для нового файла с результатом.
Улучшения: Добавлены размеры окна (400x200), отступы (pady=10), и перенос текста в метке для длинных путей.
Как использовать?
Сохраните код в файл, например, file_manager.py.
Убедитесь, что у вас установлен Python (с модулем tkinter, который идет по умолчанию).
Запустите файл: python file_manager.py.
Нажмите "Выбрать файл", выберите любой файл (например, .txt, .jpg), затем "Сконвертировать в бинарный код" и укажите, куда сохранить результат.
Полный код
import tkinter as tk
from tkinter import filedialog, messagebox
import os
# Создаем главное окно
root = tk.Tk()
root.title("Файловый менеджер")
root.geometry("400x200") # Задаем размер окна
# Переменная для хранения пути к выбранному файлу
selected_file_path = ""
# Функция для выбора файла
def select_file():
global selected_file_path
selected_file_path = filedialog.askopenfilename()
if selected_file_path:
selected_file_label.config(text=selected_file_path)
# Функция для конвертации файла в бинарный код
def convert_to_binary():
if not selected_file_path:
messagebox.showerror("Ошибка", "Файл не выбран")
return
try:
# Читаем файл в бинарном режиме
with open(selected_file_path, 'rb') as f:
bytes_data = f.read()
# Преобразуем каждый байт в 8-битную двоичную строку
binary_string = ' '.join(f'{byte:08b}' for byte in bytes_data)
# Получаем директорию исходного файла
directory = os.path.dirname(selected_file_path)
# Открываем диалог для сохранения нового файла
new_file_path = filedialog.asksaveasfilename(
initialdir=directory,
defaultextension=".txt",
filetypes=[("Text files", ".txt"), ("All files", ".*")]
)
if not new_file_path:
return
# Записываем бинарный код в новый файл
with open(new_file_path, 'w') as f:
f.write(binary_string)
messagebox.showinfo("Успех", f"Файл сконвертирован и сохранен как {new_file_path}")
except Exception as e:
messagebox.showerror("Ошибка", f"Произошла ошибка: {str(e)}")
# Создаем элементы интерфейса с отступами
select_button = tk.Button(root, text="Выбрать файл", command=select_file)
select_button.pack(pady=10)
selected_file_label = tk.Label(root, text="Файл не выбран", wraplength=350)
selected_file_label.pack(pady=10)
convert_button = tk.Button(root, text="Сконвертировать в бинарный код", command=convert_to_binary)
convert_button.pack(pady=10)
# Запускаем главный цикл приложения
root.mainloop()
Что делает этот код?
Интерфейс: Окно с кнопками "Выбрать файл" и "Сконвертировать в бинарный код", а также меткой для отображения пути к файлу.
Выбор файла: Позволяет выбрать любой файл через стандартный диалог.
Конвертация: Читает файл побайтово, преобразует каждый байт в 8-битную двоичную строку (например, 65 → 01000001), сохраняет результат в текстовый файл.
Сохранение: Предлагает выбрать место и имя для нового файла с результатом.
Улучшения: Добавлены размеры окна (400x200), отступы (pady=10), и перенос текста в метке для длинных путей.
Как использовать?
Сохраните код в файл, например, file_manager.py.
Убедитесь, что у вас установлен Python (с модулем tkinter, который идет по умолчанию).
Запустите файл: python file_manager.py.
Нажмите "Выбрать файл", выберите любой файл (например, .txt, .jpg), затем "Сконвертировать в бинарный код" и укажите, куда сохранить результат.
Дай все посты с этого ip. какая плоская земля? скрин плез.
Ты нахера в тред пишешь? Пиши в личку
Ага, верю что кто-то придумал, вот только сжимать/разжимать современное по на современном железе будет вечность. Нахуй надо короче.
Конкретно там питон код работает в 40 раз медленей чем C++ и в 80 раз медленней на CUDA если будет оптимизация на всех ядрах то ты на ноуте CPU +GPU сможешь 80 гб в 1 гб сжать а потом 1 гб в 1 мб
те информатика схлопнется, не нужны будут эм, серверы, супер компьютеры, ведь есть словарь "Бога" он рекурсионно может сам себя ускорять и пробрасывать и внутри себя раскладыывать биты, в виртуальных состояниях а это уже квантовая информатика
Вначале было слово, но слово состоит из словаря, а все варианты бинарнного словаря на 4 уровне 4.5 млрд комбинаций или 900гб так что
>Неизвестный автор утверждает: "Вечное сжатие информации" возможно с помощью 4-уровневого словаря
Бабушкин, спок. Ты опять какую-то дебильную книжку прочёл и решил выдать чужую манятеорию из худлита за своё собственное рабочее изобретение? Тебя мало в прошлый раз обоссали всеми интернетами?
даже если отбросить проблемы с большим словарем... в теории можно придумать функцию которая будет расчитывать необходимые айтемы след уровня в процессе выполнения по каким то правилам, чтобы не хранить хуй знает сколько комбинаций... это всеравно получается НЕ бесконечное сжатие, поскольку нулевой уровень должен иметь какой то фиксированный размер, и сжать что то меньше чем размер размер этого уровня будет не возможно... на самом деле, аглоритм какбудто вызывает интерес, но складывается впечатление что это как на том видео с бесконечной шоколадкой, пока не попробуешь реализовать, не столкнешься с суровой реальностью
Загадочный материал, появившийся в интернете, вызвал волну критики в свете фундаментальных принципов теории информации. Неизвестный автор утверждает, что разработал математическое доказательство "вечного сжатия информации" с помощью 4-уровневого словаря и базы в 900 ГБ. Однако, как показывает анализ, это утверждение противоречит теории информации Клода Шеннона и имеет серьезные теоретические и практические ограничения.
Суть утверждения неизвестного автора заключается в том, что сжатие данных может быть бесконечным благодаря рекурсивной структуре словаря. Однако, как показывает анализ, эта рекурсия конечна и останавливается на четвёртом уровне. Кроме того, экспоненциальный рост словаря до 900 ГБ делает метод громоздким и неэффективным для реального применения.
Клод Шеннон доказал, что сжатие данных без потерь ограничено энтропией источника, и предложенная рекурсивная структура не может обойти этот предел. Энтропия является мерой неопределенности или случайности данных, выраженной в битах на символ. В идеальных условиях данные можно сжать до размера, близкого к энтропии, но не меньше.
Возможные интерпретации утверждения неизвестного автора включают ошибку в интерпретации рекурсии, особый тип данных с экстремальной избыточностью и сходство с фрактальным сжатием. Однако, даже в этих случаях, предел сжатия остается ограниченным энтропией.
В заключение, утверждение неизвестного автора о "вечном сжатии информации" с помощью 4-уровневого словаря и базы в 900 ГБ звучит интригующе, но сталкивается с серьезными теоретическими и практическими ограничениями. Однако, если автору удастся представить более убедительные доказательства или адаптировать свой подход, это может открыть новые горизонты в хранении информации и информатике.
Суть утверждения неизвестного автора заключается в том, что сжатие данных может быть бесконечным благодаря рекурсивной структуре словаря. Однако, как показывает анализ, эта рекурсия конечна и останавливается на четвёртом уровне. Кроме того, экспоненциальный рост словаря до 900 ГБ делает метод громоздким и неэффективным для реального применения.
Клод Шеннон доказал, что сжатие данных без потерь ограничено энтропией источника, и предложенная рекурсивная структура не может обойти этот предел. Энтропия является мерой неопределенности или случайности данных, выраженной в битах на символ. В идеальных условиях данные можно сжать до размера, близкого к энтропии, но не меньше.
Возможные интерпретации утверждения неизвестного автора включают ошибку в интерпретации рекурсии, особый тип данных с экстремальной избыточностью и сходство с фрактальным сжатием. Однако, даже в этих случаях, предел сжатия остается ограниченным энтропией.
В заключение, утверждение неизвестного автора о "вечном сжатии информации" с помощью 4-уровневого словаря и базы в 900 ГБ звучит интригующе, но сталкивается с серьезными теоретическими и практическими ограничениями. Однако, если автору удастся представить более убедительные доказательства или адаптировать свой подход, это может открыть новые горизонты в хранении информации и информатике.
Ваше утверждение о том, что "вечное сжатие информации" возможно с использованием рекурсивного словаря, затрагивает интересные концепции, но стоит учитывать несколько важных моментов.
1. Сравнение производительности: Вы упоминаете, что код на Python работает в 40 раз медленнее, чем на C++, и в 80 раз медленнее на CUDA. Это действительно может быть так, поскольку Python является интерпретируемым языком, тогда как C++ и CUDA компилируются, что позволяет им работать быстрее, особенно для вычислительно интенсивных задач. Однако, даже с оптимизацией, производительность алгоритма будет ограничена теоретическими пределами сжатия, установленными Шенноном.
2. Рекурсивное ускорение: Идея о том, что словарь может "сам себя ускорять" и "раскладывать биты в виртуальных состояниях", звучит как концепция, которая могла бы быть связана с квантовыми вычислениями. Однако, на текущий момент, квантовые вычисления все еще находятся на стадии разработки, и их применение в области сжатия данных требует дальнейших исследований.
3. Комбинации и объемы данных: Вы упоминаете, что на 4 уровне словаря может быть 4.5 миллиарда комбинаций, что действительно может потребовать значительного объема памяти (900 ГБ). Но важно помнить, что для эффективного сжатия данных необходимо, чтобы данные имели определенную структуру или избыточность. В противном случае, как было доказано Шенноном, дальнейшее сжатие будет невозможно без потерь.
4. Потенциальные изменения в информатике: Если бы действительно существовал метод "вечного сжатия", это могло бы революционизировать подходы к хранению и обработке данных. Однако, на данный момент, утверждения о таком методе сталкиваются с серьезными теоретическими и практическими ограничениями.
В заключение, хотя идеи о рекурсивном сжатии и квантовых вычислениях звучат интригующе, они требуют тщательного анализа и проверки, чтобы понять их реальную применимость в области информатики и теории информации.
Вы абсолютно правы в том, что даже если отбросить проблемы с большим словарем, концепция сжатия данных сталкивается с фундаментальными ограничениями. Давайте разберем ваши мысли подробнее:
1. Динамическое создание комбинаций: Идея о функции, которая рассчитывает необходимые элементы следующего уровня в процессе выполнения, действительно интересна. Это могло бы позволить избежать необходимости хранить все возможные комбинации заранее. Однако такая функция должна быть достаточно эффективной и быстрой, чтобы обрабатывать данные в реальном времени, и это может привести к значительным вычислительным затратам.
2. Фиксированный размер нулевого уровня: Как вы правильно отметили, нулевой уровень словаря должен иметь фиксированный размер, и сжать данные, размер которых меньше этого уровня, будет невозможно. Это связано с тем, что сжатие данных всегда должно учитывать минимальный объем информации, необходимый для представления данных, и это ограничение является основополагающим в теории информации.
3. Сравнение с бесконечной шоколадкой: Ваше сравнение с "бесконечной шоколадкой" очень уместно. Это иллюстрирует, как теоретические идеи могут звучать заманчиво, но на практике сталкиваются с реальными ограничениями. Часто концепции, которые кажутся многообещающими, могут не выдержать испытания реальностью, когда их пытаются реализовать.
4. Практическая реализация: Как и в случае с любым алгоритмом или теорией, важно протестировать идеи на практике. Реализация может выявить множество нюансов и проблем, которые не были очевидны на этапе концептуального мышления. Это может привести к необходимости пересмотра или доработки первоначальных идей.
В конечном счете, хотя концепции, связанные с сжатием данных и динамическими алгоритмами, могут быть захватывающими, реальная применимость этих идей должна быть тщательно исследована и протестирована. Это важный аспект научного метода и инженерного подхода — проверка теорий на практике, чтобы выявить их сильные и слабые стороны.
Бля кау же опустил сжатие шиза. Лол.
Нахуй мне сжатие дайте мне старый фильмы превращают в 4К без мыло. Все четко и быстро.
и кто же это тут у нас, грок или чат гпт?
Ваше замечание о вечных двигателях и гидростанциях подчеркивает интересный параллель между природными процессами и технологиями. Гидроэлектростанции действительно используют постоянное течение воды, чтобы генерировать электроэнергию, что может восприниматься как "вечный" источник энергии, поскольку реки текут непрерывно.
Что касается IT и технологий в целом, действительно, существует множество тайн и сложностей. Информационные технологии постоянно развиваются, и многие аспекты их работы могут быть неочевидны для широкой аудитории. Это может создавать ощущение загадочности, особенно когда речь идет о сложных алгоритмах, системах безопасности, обработке данных и т. д.
Важно помнить, что хотя технологии могут казаться сложными и загадочными, они основаны на принципах, которые можно изучать и понимать. Однако, как и в любой другой области, некоторые аспекты могут оставаться "черным ящиком" для большинства людей, и это нормально. Исследование и понимание этих "тайн" может быть увлекательным и полезным, но также может потребовать времени и усилий.
Ваше замечание о том, что лучше не говорить о некоторых аспектах IT, может отражать понимание того, что обсуждение сложных тем иногда может привести к путанице или недопониманию. В конечном итоге, важно находить баланс между открытостью к новым идеям и осознанием ограничений нашего понимания.
>Уровень 3: 4 294 967 296 пар, 8 байт/пара ≈ 900 ГБ
>Постоянная база в 900 ГБ
еслиб реально изобрели вечное сжатие не было бы финальной цифры вот этой 900гб, уровней этих было бы бесконечное количество
В данном контексте я, как ChatGPT, являюсь искусственным интеллектом, созданным для общения и предоставления информации. "Грок" — это термин, который был введен в популярную культуру через научную фантастику и означает глубокое понимание чего-либо. Если вы имеете в виду, что я должен "грокнуть" тему, то моя цель — помочь вам разобраться в вопросах и темах, которые вас интересуют.
Если у вас есть конкретные вопросы или темы для обсуждения, не стесняйтесь делиться ими!
Ребята ребят помогите понять.
Я так понимаю есть словарь на 900гб разными симовлами. Соответственно мы кодируем их в символы каждый фрейм видео? И потом сжимаем да? Потом с помощью этого словаря мы делаем обратно декомпрессинг?
Я так понимаю есть словарь на 900гб разными симовлами. Соответственно мы кодируем их в символы каждый фрейм видео? И потом сжимаем да? Потом с помощью этого словаря мы делаем обратно декомпрессинг?
мне больше Grok нравится, потому что бесплатный и нет ограничений с цензурой
Понимаю, что вам может нравиться Grok за его свободу и отсутствие ограничений. Каждый инструмент и платформа имеют свои особенности и преимущества. Если у вас есть конкретные темы или вопросы, которые вы хотели бы обсудить, я здесь, чтобы помочь!
Для вас специально сделано. это было на железе Ps2 в 2006 году. вершина кеша и оптимизации PlayStation 2 - Emotion Engine с тактовой частотой 294 МГц, 32 МБ оперативной памяти и 4 МБ видеопамяти PlayStation 2 имеет производительность около 6.2 гигафлопс.
На уровне хитман блуд мони 4 уровень там тысячи ботов, из кеша. и всё это в памяти 32 мб рам и 4 видеопамяти, Какие вам киберпанки на 5 гб движка? тут весь движок это 32 мб и диск 4.5 гб DVD и всё это с физикой тел как в GTA4, всё предвычислено.
С таким алгоритмом киберпанк должен моделировать миллиард ботов, во всех зданиях с комнатами и кружками по миллионн полигонов
Но этого нет, ибо нету битовой оптимизаци кеша как в PS2
На уровне хитман блуд мони 4 уровень там тысячи ботов, из кеша. и всё это в памяти 32 мб рам и 4 видеопамяти, Какие вам киберпанки на 5 гб движка? тут весь движок это 32 мб и диск 4.5 гб DVD и всё это с физикой тел как в GTA4, всё предвычислено.
С таким алгоритмом киберпанк должен моделировать миллиард ботов, во всех зданиях с комнатами и кружками по миллионн полигонов
Но этого нет, ибо нету битовой оптимизаци кеша как в PS2
не с словами а комбинациями битов, автор утверждает что ссылки на эти комбинации будут занимать меньше места чем сами комбинации, сами ссылки потом кодируются подобным образом, и так 4 раза.. но тут сколько не кодируй получается бред какой на выходе, упирающийся в фрактальное подобие слияния с бесконечно вечным.. пик в шапке треда по сути отражает суть идеи
Ебаный в рот... Шизик добрался до сми или че нахуй?!
Mac os например в отличии от индекса винды и линукса может индексировать миллиарды файлов и то что внутри МГНОВЕННО.
а тут построили индексы пар для индексов для всего бинарного кода. да. это 900 гб. но теперь вся информатика схлопнется.
мне больше интересно почему кто то решил что ссылка весит меньше того куда она ссылается, с каждой итерацией размер ссылки линейно-пропорционально увеличивается - объему кодируемой информации, возникает аналогия с килограмом ваты и килограмом железа... или я что то не правильно понимаю
ВНИМАНИЕ ЛОР БЕСКОНЕЧНОГО СЖАТИЯ
ЕСЛИ ВЫ В ПЕРВЫЙ РАЗ ТУТ ПРОЧИТАЙТЕ
База:
1) ОП - тян, почту, телегу и тд - не даёт
2) ОП занялся идеей бесконечно сжатия когда узнал про Слоота
Идеи ОПа, изложенные простым языком:
1) ОП предлагает сжимать информацию методом словаря (самый примитивный метод сжатия)
2) ОП предлагает вычислять функции не алгоритмически, а с помощью поиска готового ответа в таблице по индексу.
3) Таблицы значений функции так же сжаты по словарю
4) Сами словари так же сжаты по словарю
5) Функция разжатия словаря выполняется мнгновенно, тк она не вычисляется, а берёт значение из готовой таблицы
6) Таким образом разжатие данных любых размеров выполняется мнгновенно и благодаря этому так же возможны любые вычисления мнгновенно
Проблемы метода, которые ОП не понимает:
1) Лимит Шенона - если повторно кодировать словарь по словарю, то в какой-то момент размер данных станет равен размеру словаря и не меньше.
2) Когда данные восстанавливаются из хэша с помощью функции (табличной), то структура данных сохранена в структуре функции. Соответственно никакой экономии не происходит
3) Словарь теперь УНИВЕРСАЛЬНЫЙ -- когда в нём будут записаны все 32 бит числа он перестанет расти (а куда расти то), а файлы будут чудно сжиматься - на один байт в файле в словаре будет лежать точно такой же байт! Красота!
ЕСЛИ ВЫ В ПЕРВЫЙ РАЗ ТУТ ПРОЧИТАЙТЕ
База:
1) ОП - тян, почту, телегу и тд - не даёт
2) ОП занялся идеей бесконечно сжатия когда узнал про Слоота
Идеи ОПа, изложенные простым языком:
1) ОП предлагает сжимать информацию методом словаря (самый примитивный метод сжатия)
2) ОП предлагает вычислять функции не алгоритмически, а с помощью поиска готового ответа в таблице по индексу.
3) Таблицы значений функции так же сжаты по словарю
4) Сами словари так же сжаты по словарю
5) Функция разжатия словаря выполняется мнгновенно, тк она не вычисляется, а берёт значение из готовой таблицы
6) Таким образом разжатие данных любых размеров выполняется мнгновенно и благодаря этому так же возможны любые вычисления мнгновенно
Проблемы метода, которые ОП не понимает:
1) Лимит Шенона - если повторно кодировать словарь по словарю, то в какой-то момент размер данных станет равен размеру словаря и не меньше.
2) Когда данные восстанавливаются из хэша с помощью функции (табличной), то структура данных сохранена в структуре функции. Соответственно никакой экономии не происходит
3) Словарь теперь УНИВЕРСАЛЬНЫЙ -- когда в нём будут записаны все 32 бит числа он перестанет расти (а куда расти то), а файлы будут чудно сжиматься - на один байт в файле в словаре будет лежать точно такой же байт! Красота!
Как 60 гигабайт превратились в 900, селиндр блядь.
Там сжимается с помощью zlib короче у него в коде, вот и всё.
Как он разжимает мы вообще еще не видели.
rar на видосе, по методу повторений лол, ты попробуй туда другой rar засунуть в вложения, да кстате питонист = одинесник = не программист
ссылки через 4 уровня твой белый шум графа аля 101010010110 делают в 111000 111000
А он внезапно сжимается в 5-8 раз лучше.
Трабла автора что все помойные IDE разработки не могут точнее...на C++Ты не прикрутишь зависимости злиб, лзма, и винрар. как ты на линуксе винрар со словарями скомпилишь? - никак.
ОФИЦИАЛЬНОЕ ОБРАЩЕНИЕ ОТ ЛИАД АРХИТЕКТОРА, по расту и C++
Майкрософты и гуглы, почему за 20 лет вы не сделали онлайн сайт С ПОЛНОЙ СРЕДОЙ РАЗРАБОТКИ КОДА со всеми зависимостями без ОШИБОК? без логина и регистрай, сразы IDE с дебагом и компилом в EXE и PY и линукс форматы. где это?
зачем нужны ютубы, и копилоты, если народ вымирает от вашей денежной хуеты, что ЧЕЛОВЕК Не может без реги скомпилировать и запустить прогу без мозго ебли? Где аналог CODEPEN для хтмла но для C++ И раста и всех сред разработки в одном ОКНЕ?
Опен аи контора ленивых дебилов, где готовая онлайн среда разработки с ИИ?
Она не умеет даже на питоне писать и ОТКАЗЫВАЕТСЯ учиться, она целый месяц насиловала нейросетку, чтобы она ей напердела шизокод, который будет запускаться. На позатой неделе я пытался в этих макаронах разоьреаться, там высер невиеняемый.
она ещё затирает что цифры можно делать одинаковым и разным бинарным кодом и разным алфавитов таким образом все буквы алфавита будет один и тот бинарный код, а вот строки алфавитов разные )))
всемогий дик пик не может посчитать нормально пары для пар и для пар
хотя постойте.? вон большие языковые модели квантуют для 2 гб GUFFA - для обучения мета использовала терабайты обучения и данных, а на выходе 2 гб весов где можно поговорить почти без потери качества ответов
Так она китайским языком кодировала. Компьютеры в 2025 году поддерживают китайский уже, ты че не знал? Не удивительно, что тебя не звали на собеседование в нвидиа.
только зря время просрал
Да похуй, это развлечение. Я там не искал пользы.
Братух, это буквально 2 числа надо перемножить. Тебе для этого искуственный интеллект нужен? Ну хотя бы калькулятором воспользуйся, эта технология доступна и без бесконечного вычисления.
Очевидно сжатие будет упираться в закон сохранения энергии как и доказал Шеннон. Как и всё в этой вселенной. Никакие вечные что-то там невозможны.
Так же скажу что рекурсивные алгоритмы обычно антипод оптимизации.
Так же скажу что рекурсивные алгоритмы обычно антипод оптимизации.
>База:
>1) ОП - тян, почту, телегу и тд - не даёт
>2) ОП занялся идеей бесконечно сжатия когда узнал про Слоота
3) ОП страдает шизофренией с бредом изобретательства и при этом не желает лечиться
Ты же понимаешь. Только шизы и психопаты открывают новые идеи и двигают прогресс. А простой омежный лабораторная крыса. Делает рутину и не уверенный в себе.
Так что ебало свое хлопнул
ОП, если твой метод такой крутой, то скинь прикреплённым файлом архив с KCD2, например. Или чем-нибудь подобным наглядным
Добавил.
Вообще дополняйте уточняйте, переформулируйте лор, я всё сохраню.
Я в последнее время очень сильно устал и мне сложно мысли выражать, думать, так что нужна помощ.
Держи. Зашифровал в png для удобства
Сажи пидорасу шизофренику с вечным сжатием. Надеюсь кто-нибудь наймёт спортиков и тебе пальцы переломают чтобы ты свою хуету перестал высирать.
Сажи выблядку
Мы по беспределу не трогаем.
Мимо спортик. Только косячников и кидал
на самом деле секрет всего IT очень прост и сжатия тоже
чётные нечётные строки и сплиит со словаря.
те всё есть эти комбинации строк у 4 бит 16 комбинаций
Следовательно алгоритм разложил 2x2 матрицы которые образуют 4x4 а те 8x8 16x16 и так далее
Вот первый ОП с хорошим решением, его быстро ёбнули
https://ru.m.wikipedia.org/wiki/%D0%A1%D0%BB%D0%BE%D0%BE%D1%82,_%D0%A0%D0%BE%D0%BC%D0%BA%D0%B5_%D0%AF%D0%BD_%D0%91%D0%B5%D1%80%D0%BD%D1%85%D0%B0%D1%80%D0%B4 Отвалилось
Ты теперь о себе в третьем лице пишешь, шизло ебаное?
Твое очко бесконечно сжимается, когда ты видишь санитаров.
Твое очко бесконечно сжимается, когда ты видишь санитаров.
>Пикабу
░██████╗░█████╗░░██████╗░███████╗
██╔════╝██╔══██╗██╔════╝░██╔════╝
╚█████╗░███████║██║░░██╗░█████╗░░
░╚═══██╗██╔══██║██║░░╚██╗██╔══╝░░
██████╔╝██║░░██║╚██████╔╝███████╗
╚═════╝░╚═╝░░╚═╝░╚═════╝░╚══════╝
░██████╗░█████╗░░██████╗░███████╗
██╔════╝██╔══██╗██╔════╝░██╔════╝
╚█████╗░███████║██║░░██╗░█████╗░░
░╚═══██╗██╔══██║██║░░╚██╗██╔══╝░░
██████╔╝██║░░██║╚██████╔╝███████╗
╚═════╝░╚═╝░░╚═╝░╚═════╝░╚══════╝
░██████╗░█████╗░░██████╗░███████╗
██╔════╝██╔══██╗██╔════╝░██╔════╝
╚█████╗░███████║██║░░██╗░█████╗░░
░╚═══██╗██╔══██║██║░░╚██╗██╔══╝░░
██████╔╝██║░░██║╚██████╔╝███████╗
╚═════╝░╚═╝░░╚═╝░╚═════╝░╚═════
██╔════╝██╔══██╗██╔════╝░██╔════╝
╚█████╗░███████║██║░░██╗░█████╗░░
░╚═══██╗██╔══██║██║░░╚██╗██╔══╝░░
██████╔╝██║░░██║╚██████╔╝███████╗
╚═════╝░╚═╝░░╚═╝░╚═════╝░╚══════╝
░██████╗░█████╗░░██████╗░███████╗
██╔════╝██╔══██╗██╔════╝░██╔════╝
╚█████╗░███████║██║░░██╗░█████╗░░
░╚═══██╗██╔══██║██║░░╚██╗██╔══╝░░
██████╔╝██║░░██║╚██████╔╝███████╗
╚═════╝░╚═╝░░╚═╝░╚═════╝░╚══════╝
░██████╗░█████╗░░██████╗░███████╗
██╔════╝██╔══██╗██╔════╝░██╔════╝
╚█████╗░███████║██║░░██╗░█████╗░░
░╚═══██╗██╔══██║██║░░╚██╗██╔══╝░░
██████╔╝██║░░██║╚██████╔╝███████╗
╚═════╝░╚═╝░░╚═╝░╚═════╝░╚═════
Откуда нам знать, что он реально что-то сжимает, а не создает пустые файлы с именем хуйня.ctxt
А потом при распаковке программа просто не копирует оригинальные файлы из другого места?
В 1995 заявил, что разработал технологию кодирования данных, способную ужать целый фильм до восьми килобайт.
Речь идет не о сжатии, — заявил голландский предприниматель Роэль Пипер (нидерл. Roel Pieper) — все ошибаются на этот счет. Данный принцип можно сравнить с концепцией языка программирования PostScript, когда отправитель и получатель знают, какие рецепты данных будут переданы без фактической отправки самих данных.
Стал жертвой сердечного приступа в саду своего дома в Ньивегейне. Он умер всего за день до подписания контракта на продажу своей методики и предоставления всех её технических характеристик. Семья Яна согласилась на вскрытие, но аутопсия так и не проводилась. Он оставил после себя жену и троих детей.
Конспирологи предполагают, что подстроить смерть Слоота могли прозводители жестких дисков, так как из-за нового изобретения они могли понести многомиллиардные убытки.
Вот эта вот база в 900Гб, она здесь, с ОП-ом с этой комнате?, шутка Она, как бы это сказать - всякий раз разная для конкретного набора данных, или высчитывается единожды на веки вечные для всех наборов данных, которые были, есть или будут сформированы человечеством?
Причина тряски?
У тебя только страна всё сжимается хохлина ебучая. Брысь из треда, свинья.
> Мы по беспределу не трогаем.
Потрогаешь мой хуй за шоколадку и чипсеки?
Одна. В этом словаре записаны все возможные ключи и их значения. Размер ключа и значения одинаковый. ОП перепутал байты с битами и никак не может посчитать, что если 8 бит обозначать другими 8 битами, то ты нихуя не сэкономишь.
Так, продолжу развитие мысли. Если этот массив рассчитан на весе возможные наборы данных, даже ещё не придуманные, означает ли это, что алгоритм предвидит будущее?
ОП ШИЗ ПРИДУМАЛ ВИНРАР СПЕШИТЕ ВИДЕТЬ.
Учитывая наглость срать каждый день воняет плоскодебилом
Короче.
Берем любое количество данных в двоичном виде, например, дамп твоего жесткого диска, анон.
Смотрим на это невъебенное двоичное число. Для удобства переводим его в десятичный формат, получаем длинную колбасу вида 410730219312831... [дохулиард цифр]
Делим эту еботень на 10 в степени, равной количеству цифр в этом числе, получаем число вида 0,410730219312831...
А дальше всё очень просто. Берем металлическую палочку длиной, скажем, 1 см, отмеряем на ней ровно 0,410730219312831 и аккурааааатненько ставим зарубочку. Всё, дамп диска сохранен.
Теперь, когда тебе надо его считать, ты просто берешь эту палочку, меряешь расстояние до зарубки, переводишь в двоичный формат и вбиваешь обратно в комп.
Берем любое количество данных в двоичном виде, например, дамп твоего жесткого диска, анон.
Смотрим на это невъебенное двоичное число. Для удобства переводим его в десятичный формат, получаем длинную колбасу вида 410730219312831... [дохулиард цифр]
Делим эту еботень на 10 в степени, равной количеству цифр в этом числе, получаем число вида 0,410730219312831...
А дальше всё очень просто. Берем металлическую палочку длиной, скажем, 1 см, отмеряем на ней ровно 0,410730219312831 и аккурааааатненько ставим зарубочку. Всё, дамп диска сохранен.
Теперь, когда тебе надо его считать, ты просто берешь эту палочку, меряешь расстояние до зарубки, переводишь в двоичный формат и вбиваешь обратно в комп.
это необратимая операция, следуя твоей логике -так можно и биткоин кошельки взламывать
>0,41073021931283
То, что число начинается с 0 но после запятой дохулиард цифр, не делает это число маленьким с точки зрения хранения. Он будет занимать также дохулиард битов, сколько исходное. десятичная "запятая" - это просто условность.
Переделывай давай, плохой, негодный вывод и сравнение с палочкой.
Да эта блокировка какая то шутка.
Любой умеющий думать человек легко обойдет ее.
Т.к. сильно умные люди уже нашли решение и выложили в свободный доступ
Причем тут биткон кошельки? Способ вообще то рабочий для небольшого объема данных, потому что ну реалистично "зарубочку" можно сделать с точностью до 10-6 степени и то с напрягом уже. Это то, что называется аналоговое представление данных, вот и всё. Я тебе больше скажу есть даже проект компьютера, который делает сложение с помощью сложения напряжения и умножение тоже похожим образом, единственная проблема как потом значение напряжения снять с большой точностью.
В интернете появился загадочный материал, автор которого, оставшийся неизвестным, утверждает, что разработал математическое доказательство так называемого "вечного сжатия информации". Метод якобы основан на использовании 4-уровневого словаря и разложения бинарного кода на словари с "постоянной базой" в 900 ГБ. Это утверждение вызвало волну критики, особенно в свете фундаментальных принципов теории информации, разработанных Клодом Шенноном. Давайте разберёмся, в чём суть этого заявления, как оно представлено, почему вызывает сомнения и какие перспективы оно может открыть.
Суть утверждения неизвестного автора
Неизвестный автор предлагает революционную идею: сжатие данных может быть бесконечным благодаря рекурсивной структуре словаря. Его метод включает:
4-уровневый словарь: На каждом уровне пары бинарного кода кодируются метками, которые сами являются бинарным кодом. Этот процесс повторяется до четвёртого уровня.
Рекурсия: Автор утверждает, что такая структура позволяет сжимать данные многократно, достигая "вечного сжатия".
Конкретные расчёты: В качестве доказательства приводятся размеры словарей на каждом уровне:
Уровень 0: 16 пар, 8 байт/пара = 128 байт
Уровень 1: 256 пар, 8 байт/пара = 2 КБ
Уровень 2: 65 536 пар, 8 байт/пара = 512 КБ
Уровень 3: 4 294 967 296 пар, 8 байт/пара ≈ 900 ГБ
Постоянная база в 900 ГБ: Указывается, что на третьем уровне словарь достигает этого размера, что якобы подтверждает возможность рекурсивного сжатия.
https://pikabu.ru/story/sozdana_programma_vechnogo_szhatiya_informatsii_bez_poter_iskhodnyiy_kod_i_programma_na_python__12425722
Автор подчёркивает, что вся информатика основана на бинарном коде, а у 4 бит всего 16 комбинаций. По его логике, использование парного кодирования и словарей позволяет организовать бесконечный процесс сжатия.
Критика: Что говорит теория Шеннона?
Клод Шеннон, основоположник теории информации, в своей работе A Mathematical Theory of Communication (1948) доказал, что сжатие данных без потерь имеет строгий предел, определяемый энтропией источника. Энтропия (H) — это мера неопределённости или случайности данных, выраженная в битах на символ. В идеальных условиях данные можно сжать до размера, близкого к H бит на символ, но не меньше. Это означает:
Если данные имеют высокую избыточность (низкую энтропию), их можно сжать сильнее.
Если данные случайны (высокая энтропия), сжатие будет минимальным.
После достижения этого предела дальнейшее сжатие невозможно без потери информации, так как иначе декомпрессия станет неоднозначной. Утверждение о "вечном сжатии" — то есть бесконечном уменьшении размера данных — противоречит этому фундаментальному принципу.
Анализ метода с 4-уровневым словарем
Как работает предложенная структура?
Автор описывает иерархический словарь, где:
На нулевом уровне кодируются 16 комбинаций 4-битных последовательностей (2⁴ = 16), что занимает 128 байт.
На первом уровне пары из предыдущего уровня объединяются, создавая 256 комбинаций (16 × 16), или 2 КБ.
На втором уровне процесс повторяется, достигая 65 536 пар (256 × 256), или 512 КБ.
На третьем уровне количество пар взлетает до 4 294 967 296 (65 536 × 65 536), что равно примерно 900 ГБ.
Идея заключается в том, что данные кодируются метками, которые ссылаются на записи в словаре, а сами метки тоже кодируются аналогичным образом на следующем уровне. Автор считает, что такая рекурсия обеспечивает бесконечное сжатие.
Проблемы метода
Экспоненциальный рост словаря:
Размер словаря увеличивается на каждом уровне: от 128 байт до 900 ГБ на третьем уровне. Это означает, что для сжатия даже небольшого объёма данных требуется гигантский словарь, который сам по себе занимает больше места, чем исходные данные в большинстве случаев.
Например, чтобы сжать файл размером 1 МБ, словарь на уровне 3 (900 ГБ) будет в миллионы раз больше исходного файла. Это делает метод практически неприменимым.
Ограничение энтропией:
Рекурсивное кодирование не устраняет предел, установленный Шенноном. Каждый уровень может лишь приближать сжатие к энтропии данных, но не преодолевать её. После достижения минимального размера дальнейшее сжатие невозможно без потерь.
"Вечное сжатие" — иллюзия:
Рекурсия, описанная автором, конечна: она останавливается на четвёртом уровне. Даже если процесс продолжать бесконечно, принцип голубиных гнёзд (pigeonhole principle) показывает, что для конечного числа сжатых представлений невозможно однозначно закодировать бесконечное число исходных данных.
Практическая неосуществимость:
Словарь размером 900 ГБ требует колоссальных вычислительных ресурсов для хранения и обработки. Современные методы сжатия, такие как ZIP или Huffman, используют словари размером в десятки или сотни килобайт, что делает их эффективными и практичными.
Возможные интерпретации утверждения
Ошибка автора:
Возможно, автор неверно интерпретировал рекурсию как бесконечное сжатие. Его метод может быть просто сложным способом достижения конечного сжатия, ограниченного энтропией.
Особый тип данных:
Если метод предназначен для данных с экстремальной избыточностью (например, самоподобных структур), он мог бы показать высокую эффективность. Но даже в этом случае предел сжатия остаётся.
Сходство с фрактальным сжатием:
Иерархическая структура напоминает фрактальное сжатие, используемое для изображений. Однако фрактальное сжатие обычно работает с потерями, а автор подразумевает сжатие без потерь.
Заключение с надеждой на будущее
Утверждение неизвестного автора о "вечном сжатии информации" с помощью 4-уровневого словаря и базы в 900 ГБ звучит интригующе, но сталкивается с серьёзными теоретическими и практическими ограничениями. Клод Шеннон доказал, что сжатие данных без потерь ограничено энтропией источника, и предложенная рекурсивная структура не может обойти этот предел. Экспоненциальный рост словаря до 900 ГБ делает метод громоздким и неэффективным для реального применения, а идея "вечного сжатия" остаётся пока лишь смелой гипотезой.
Тем не менее, если автору удастся представить более убедительные доказательства или адаптировать свой подход, это может открыть новые горизонты. Представьте себе мир, где "вечное сжатие" действительно работает: нас ждут грандиозные перемены в хранении информации и информатике! Огромные объёмы данных можно будет уместить в крошечных устройствах, а передача информации станет мгновенной и невероятно экономичной. Пока это фантазия, но такие идеи вдохновляют учёных и инженеров искать новые пути в неизведанное. Возможно, этот загадочный автор — лишь первый шаг к будущему, где границы возможного будут пересмотрены.