СОЗДАНА ПРОГРАММА ВЕЧНОГО СЖАТИЯ ИНФОРМАЦИИ БЕЗ ПОТЕРЬ. Исходный код + программа на python https://

СОЗДАНА ПРОГРАММА ВЕЧНОГО СЖАТИЯ ИНФОРМАЦИИ БЕЗ ПОТЕРЬ.
Исходный код + программа на python

https://drive.google.com/file/d/1sX42t-4tt6j31gyXFuwgrRFmRaD0KOEg/view

Линукс. Исходный код и компил программа.

https://drive.google.com/file/d/1asTnrpCHiOixksRU9AjyT1bkZ3-JmL_x/view

64 ГБ СЛОВАРЯ ХВАТИТ ВСЕМ!

Шеннон доказал, что существует предел, до которого можно сжать данные без потерь. Этот предел определяется энтропией источника. В идеальных условиях, если данные имеют энтропию ( H ), то их можно сжать до размера, близкого к ( H ) бит на символ.

Но Шеннон не предполагал что можно создать словарь 4 уровня, где пары бинарного кода кодируются метками бинарного кода, а сами метки тоже бинарным кодом и так до 4 уровня.
Таким образом достигается вечное сжатие в рекурсии!

Уровень 0: 16 пар 8 байт/пара = 128 байт

Уровень 1: 256 пар 8 байт/пара = 2 КБ

Уровень 2: 65 536 пар 8 байт/пара = 512 КБ

Уровень 3: 4 294 967 296 пар 8 байт/пара = ~ 34 ГБ

34 гб описывают бесконечную рекурсию информации! Следовательно информацию и вычисления можно бесконечно сжимать и снова раскладывать без потерь!

Код создан с нуля ИИ, по подсказкам метода Яна Слоота.
Он работает медленно, любая попытка ИИ его улучить ломает код и работу программы
Что нужно сделать:
1) переписать на С++ или CUDA
2) переписать логику что бы не ел 34 ГБ RАМ постоянного словаря а ток с SSD
3) Добавить рекурсию после сжатия для нового сжатия

Принцип Работы, файл сжимается, размер его сохраняется но это теперь файл это ссылки на 34 гб словарь. Магия в том, что если поместить сжатый файл в ZIP и RAR то его размер в 10-20 раз МЕНЬШЕ ОРИГИНАЛА, И его можно восстановить из ОБЩЕГО СЛОВАРЯ. который постоянный 34 гб!

код и метод выложен на общее обозрение в Open source - вы можете редактировать и изменять его, но уважайте себя и научное сообщество, метод даёт возможным сингулярность и AGI

Получив бесконечные вычислительные мощности и память что будете делать с этим?

>Получив бесконечные вычислительные мощности и память что будете делать с этим?

скачаю всю порнуху с порнолаба и буду на диване дрочить до остановки сердца

https://replit.com

Функция AUTOMATIC DEVELOPER - пишет полностью прогу, исправляет все ошибки, проводит все тесты, всё силами ИИ, эменно этот ИИ написал для линукса сжималку по ТЗ
минусы
стоит 15 $

>>316643974
А эта программа может написать программу которая выводит текущую цену биткоина?

>>316644039
Да, пишет код и полностью его тестирует покуда ТЗ не будет выполнено. за 3 минуты выполнит любое ТЗ в 1000 строк.
Если больше 1 часа не может сделать ( проект на сотню стеков ) то пишет где траблы и в чём проблемы, но таких событий ток 1% в 99% твоё ТЗ выполнит за 3 минуты

в твоём случае он создаст хтмл ява скрипт с апи отпрктым ценой криптобиржи

>Шеннон доказал, что существует предел, до которого можно сжать данные без потерь. Этот предел определяется энтропией источника.
Ты сам себе противоречишь, шизофреник, когда говоришь, что будешь бесконечно сжимать данные и опираешься буквально на теорию, которая противоречит твоей задумке. Не важно сколько уровней в твоём сжатии, теория универсальна и говорит про то, что ты не можешь сжимать данные меньше, чем их энтропия.
>сингулярность и AGI
И как добивочка, кинул модных словечек на которые только дебилы поведутся.

>>316643851 (OP)
То есть чтобы разжать твой архив надо предварительно скачать 34гб словаря? Ты ебанутый?

>>316643851 (OP)
Покажи сжатие наглядно. На видео.

Прошлый тред развалил компанию на 2

С помощью моего метода можно уже делать память в 16 раз больше
было 1 ТБ стало 16 ТБ

15 февраля · 15:21

Отделившаяся от Western Digital компания SanDisk представила то, что должно позволить ей откусить кусочек от горячего рынка ИИ. Речь о новом типе памяти.

Компания показала новую архитектуру памяти, которую называет флэш-памятью с высокой пропускной способностью. Она фактически объединяет огромную емкость хранения 3D NAND с пропускной способностью HBM.
фото SanDisk

Речь тут идёт о сложении 16 слоев новейших кристаллов 3D NAND, используя крошечные конвейеры данных, называемые сквозными кремниевыми переходами. Также есть специальный логический слой, который может параллельно записывать данные в отдельные подмассивы NAND и из них. Это приводит к тому, что HBF упаковывает в 8–16 раз больше емкости на стек, чем сегодняшние реализации HBM.

В частности, компания в виде примера показала систему с восемью стеками HBF, которая может обеспечить колоссальную емкость в 4 ТБ, что недостижимо для современной HBM. Впрочем, одно из основных ограничений NAND относительно HBM у новой памяти тоже остаётся — это заметно более высокие задержки. Но для задач ИИ это и не особо важно, а для потребительских игровых решений такую память всё равно использовать не будут.

>>316644323

>>316643851 (OP)
а можешь переписать это на PHP??

>>316643851 (OP)
Баян. Это уже давно известно

>>316644252
Словарь создаётся динамически по ходу дела и после 34 гб перестаёт расти.

словарь рекурсивный по типу те пары вечно себя сжимают на два. всегда.

01 = 1
10 = 0

те решена главная проблема информатики.

1000 строчный С++ скрипт делает любую память бесконечной с помощью словаря 40 гб. под скрипт можно собрать FPGA или нейронный процессор который сможет себя рекурсивно ускорять индексируя индексы индексируя индексы. В РЕКУРСИИ

>>316644243
Схема программы.

>меньше, чем их энтропия.

Можно создать словарь где 16 бит ссылки будут вести на 64 бит блоки.

Как? много уровненный словарь где пары маркируются и пары индексов тоже маркируются до 4 уровня.

Хуйня. Разбвдите когда раздолбанное очко научитесь сжимать

>>316644836
>16 бит ссылки будут вести на 64 бит блоки
А то, что 16 бит недостаточно, чтобы адресовать все уникальные 64-битные комбинации, тебя не волнует? Также каждый уровень добавляет лишь адресацию, но не уменьшает энтропию исходных данных.

>>316644243
>теория универсальна и говорит про то, что ты не можешь сжимать данные

теория рудиментарна и устарела.

простой пример. метод словаря

1=10
10=1

сжатие в 10 раз )))

метод словаря строки
1=123456789 - сжатие в миллионы раз
2=987654321

В проге из поста проблема такая, что нужно создать алгоритм который обратимо 2 числа конвертирует в одно и обратно обратимо и детерминировано. с 3 уровень по 4

тогда вместо 60 гб словарей . будет 5 мб.

>>316645038
>А то, что 16 бит недостаточно,

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

словарь 1

А = 111000

Словарь 2

А = 111000

и так дальше.

И так получилось что это весит меньше десятикратно при 1 цикле

>>316643851 (OP)
Как же охуенно! Сжал ReadMe.txt и довольный как слон храню сжатый файл в словаре на 1 терабайт.

У меня друзь в ФСБ, да такая хуйня реально существует. Именно поэтому сейчас все видео ютуба копируются на рутуб, по фильтру - фильтр ии смотрит каждое видео на законы роскомнадзора - и добавляет. Когда ютуб скопируется - заблочат навсегда ютуб, но новые видео станут также появляться через фильтра

>>316645459
>бесконечное количество словарей
Чтобы добраться до 64 в итоге. Не наебешь, лох.

>>316643851 (OP)
Если это правда, то изи деньги.
http://prize.hutter1.net/
Тут платят если сжать их файл короче установленного на данный момент мирового рекорда. 1 Гб - 110 Мб. Словарь любой величины вроде допускается.

АНОНЫ, ДАЙТЕ КРАТКУЮ СВОДКУ

Вижу треды этого шиза уже год и интересно, его пост и действия несут смысл? В этой хуйне не шарю, просто инетерсно

>>316646437
двачую

>>316646437
Он прост ебанутый. Смысл вообще сжатия инфы в том что после остаётся только сжатое, а у него сжатое + левый словарь на 100500 гигов. Охуенно сжал, чё. Просто чел больной, очень больной на голову.

>>316643851 (OP)
> можно восстановить из ОБЩЕГО СЛОВАРЯ. который постоянный!
Долабёб, ты заебал срать своим говном. Где словарь-то хранить? У дяди? Что делать если словарь наебнётся? Вообщем, завязывай с веществами, дебил.

Файл действительно он сжал в 2 раза меньше исходного .exe
Чем 7zip и winrar

Вот только это наёбывало он создает нпу папку где блядь словарь весит больше чем сам исходны файл.

/thread

Скрипт проигрывает обычным архиваторам

Сжатия файла имеет отрицательный характер. Жду ответа OPа

>>316646225
Смотри исходный код, это сингулярность и квантовый словарь.

если вначале прогнать 60 гигов то во всём мире его структура будет одинаковой

впрочем, не прикол ли что бы написать простую прогу нужно 25 гб библиотек и зависимостей?

>>316643851 (OP)
Этого убьём.
SanDisk

>>316646855
Уровень 0: 16 пар 8 байт/пара = 128 байт

Уровень 1: 256 пар 8 байт/пара = 2 КБ

Уровень 2: 65 536 пар 8 байт/пара = 512 КБ

Уровень 3: 4 294 967 296 пар 8 байт/пара = ~ 34 ГБ

те больше 40 гигов не будет но при этом ты сможешь бесконечно сжимать в рекурсии

>>316647021
>сжимать в рекурсии
Шизло, ты так и не показал сжатие больших файлов. Сожми своей шизохуйнёй файлы реально больших размеров (от терабайта), а там посмотрим.

>>316646437
тебе новости ни о чём не говорят?

Пеки, ИИ и программы смогут ускорять свои вычисления и память рекурсивно бесконечно, точнее вся информатика это 40 гб словарей. и всё.

Гиф 3 можно смотреть бесконечно

на первых этапах, 40 гб регистра ускорят компьютеры в 500 раз. сжатие в 500 раз
те то что щас 1 тб будет 500 тб. но рекурсию можно повторять

>>316647021
К чему твой высер, даже если NPY и твой файл запокавать в архив с максимальным сжатием то общий вес будет файлу который не заархивирован.
Я не собираюсь 10 часов сжимать 50гб файл чтобы тебя опровергнуть, иначе бы давно это бы изобрели. Сейчас попробую сжимать от репакеров

>>316647077
лол. ты научишься рисовать в художке или может научишься рисовать аниме??

сложную прогу нельзя написать без дара. поэтому прошу помощи.

>>316647130
Так в этом и смысл что бы потом в зип и рар и по новой.

Что нужно сделать:
1) переписать на С++ или CUDA
2) переписать логику что бы не ел 34 ГБ RАМ постоянного словаря а ток с SSD
3) Добавить рекурсию после сжатия для нового сжатия

Принцип Работы, файл сжимается, размер его сохраняется но это теперь файл это ссылки на 34 гб словарь. Магия в том, что если поместить сжатый файл в ZIP и RAR то его размер в 10-20 раз МЕНЬШЕ ОРИГИНАЛА, И его можно восстановить из ОБЩЕГО СЛОВАРЯ. который постоянный 34 гб!

>>316647021
Какая нахуй рекурсия, долбаёб. Жпег практически несжимаемый, нахуй. Каждая фотка - уникальный пиздец из цветовых байтов. У меня своих фоток на 2 терабайта, нахуй. А ты продолжаешь пиздеть что сожмёшь их до килобайта? Лол ваще. Иди проспись, болезный.

>>316647189
То есть дальше шизотеории, которая противоречит логике и теоремам, ты не ушёл, верно?

>>316647219
>БЩЕГО СЛОВАРЯ. который постоянный 34 гб!
Схуяли он общий? Предлагаешь мне словарь заидь файлами на 40гб чтобы твой бред работал?, зип и рар тут не причем щас спрошу у нейросетки бред у тебя или нет

>>316647219
Какая магия, дебил? Мне надо сжать 100 фоток и отдать по сети, блять, ты предлагаешь мне отдавать ещё и словарь на 40 гигов? Пидорас твоя фамилия, блять.

>>316647256
>
>Схуяли он общий? Предлагаешь мне

Общий для кодирования и декодирования всех файлов где 16 бит ссылки на 64 бит и обратно ссылок по 4 словарям 256 символов

на всех компьютерах он одинаков.

>>316647407
дегенерат пойми нейросеть не может создать такой алгоритм, нейросеть понятие не имеет что это такое, архиваторы уже сделали лучше в 90-х годов с тех пор особо далеко не двинулись

>>316647304
Ты дебил? Данный метод только для локального сжатия. бесконечного. можно сделать и для сети, всеобщем это код сингулярности, мне порядка 10 нобелевок должны дать. да ток, я как тян не готова к такой популярности, это какое то безумие. На планете обезьян.

поляки делают AAA екшены в то время как 99% населения в говне

вот вы рофлите над сжатошизом
а прикиньте через несколько лет просто каждое устройство с завода будет иметь словарь этот ебучий, и будем в 4к прон смотреть с 3г интернета

>>316647407
> на всех компьютерах он одинаков.
То есть теперь 40 гигов достаточно чтобы оцифровать всю инфу на земле? А гугол то не знает, блять. Иди расскажи им, а то они долбаёбы, постоянно новые ссд закупают с жестяками. Скажи, кто тебе насрал в голову и когда?

>>316647233
>
> Жпег практически несжимаемый

сверху исходный код и рабочая прога.

все файлы состоят из 1 и 0
те 1 млн бит это 500 тысяч 1 и 0 вперемешку,

Метод словаря, раскладывает на все возможные комбинации и ссылки.

Я бы могла сама по тихому обогащатся да ток у меня всё есть, и благо цивилизации для меня важней чем неск монополистов.

ЩАС РАССКАЖУ ВОТ ЧТО.

>>316647487
> мне порядка 10 нобелевок должны дать.
--->
>>316647535

>>316643851 (OP)
алсо, сжатошиз, попробуй claude, говорят лучше гпт иногда пишет код

>>316647479
>дегенерат пойми нейросеть не может создать такой алгоритм, нейросеть понятие

Дело в том, что код мне скодил genini - DEEPMIND на серверах гугла за миллиарды.

https://aistudio.google.com/app/prompts/new_chat

программу удалось завершить только месяц назад.

Математическое доказательство ещё летом. Ты хочешь нобелевку?

Хорошо, вот окончательный ответ, объединяющий анализ треда, видео и скрипта, как вы и просили:

Окончательный ответ: "Вечное сжатие" - это обман и заблуждение.

Коротко и ясно: Программа из треда не создает "вечное сжатие". Это иллюзия сжатия, основанная на трюке с огромным внешним словарем. Автор треда, ОP, заблуждается (или намеренно вводит в заблуждение) относительно эффективности и практической ценности своего "метода".

Как это работает на самом деле (и почему это не "сжатие"):

* Суть "сжатия" в скрипте: Программа берет ваш файл и заменяет повторяющиеся 2-битные блоки на короткие "коды". Эти "коды" - это просто указатели на записи в огромном словаре (папка `dictionaries_npy`). Сам словарь (который весит десятки гигабайт) не сжимается и не включается в "сжатый" файл.
* "Сжатый" файл - это просто "ссылки": Файл, который вы получаете на выходе (`.ctxt`), становится маленьким, потому что он содержит только ссылки (коды-указатели) на словарь. Сами данные никуда не исчезают - они просто переносятся в словарь.
* Огромный словарь - главная проблема: Чтобы *распаковать* файл, вам нужен тот же самый словарь на десятки гигабайт. Это делает метод непрактичным. Представьте, что вы "сжали" файл до 1 МБ, но вам нужно передать вместе с ним папку словаря на 100 МБ (а в реальности словарь может быть и больше, чем исходные данные!). Общий размер данных только увеличивается, а не уменьшается.
* 40 ГБ - это не предел, а ограничение кэша: Утверждение, что словарь "не будет расти после 40 ГБ" - неправда. В коде есть ограничение на *кэш в памяти* (1 ГБ в коде, но в треде упоминаются другие цифры). Но сам словарь на диске (который хранится в папке `dictionaries_npy`) **может расти бесконечно**, особенно если вы будете сжимать разнообразные файлы. Ограничение кэша просто замедлит работу, но не остановит рост словаря.

**Анализ скрипта (кратко):**

* **Многоуровневые словари (4 уровня):** Идея многоуровневости сама по себе не нова, но реализация в скрипте ведет к созданию **огромных, неэффективных словарей**.
* **2-битное блочное разбиение:** Разбиение данных на такие маленькие блоки **неэффективно** и увеличивает накладные расходы на словарь.
* **Python и медленная работа:** Реализация на Python делает программу **медленной**.

**Видео для понимания (аналогия):**

Представьте себе **огромную библиотеку (словарь)**, где хранятся все возможные комбинации 2-битных блоков и их "коды".

* **"Сжатие" по методу ОPа:** Вы берете книгу (файл), и вместо того, чтобы хранить саму книгу, вы оставляете себе только **каталожные номера** (коды) страниц, которые есть в вашей книге, и выбрасываете саму книгу. Размер "каталога" (сжатый файл) маленький, но чтобы прочитать книгу, вам нужно идти в **огромную библиотеку** и искать страницы по каталожным номерам. **Размер библиотеки (словаря) может быть больше, чем все книги, которые вы "сжали" таким образом.**

* **Реальное сжатие (WinRAR, 7-Zip и т.д.):** Архиваторы, как WinRAR, **не создают внешних библиотек**. Они ищут повторяющиеся фрагменты *внутри самого файла* и заменяют их короткими ссылками. **Вся информация, необходимая для распаковки, находится внутри самого архива.** Архив получается меньше, и для распаковки не нужен никакой внешний "словарь".

**Вывод:**

Не верьте заявлениям ОPа о "вечном сжатии". Это **псевдонаучная чушь**. Скрипт не является эффективным или практичным методом сжатия данных. Используйте стандартные архиваторы, которые работают гораздо лучше и честнее.

>>316643851 (OP)
Виндовс 7 ностальгия

>>316647601
>Математическое доказательство ещё летом. Ты хочешь нобелевку?
Петух, у тебя ничего не работает нету никакого сжатия даже лучше винрара, как покажешь так приходи умник хуев

>>316647522
>а прикиньте через несколько лет просто каждое устройство с завода будет иметь словарь этот ебучий,

Я подсчитала что телефоны будут в 50 тысяч раз быстрее, как и RAM И место. дальше уже предел шины, проводников, инфа кодироваться будет 50 гб в сек. туда и обратно. место бесконечное.

процессор, ram и ssd раскладывается в этот 50 гб словарь.

если подключить квантовую пеку, то боюсь даже представить что будет. СИМУЛЯЦИЯ вселенной и всех вариантов будущего, реал тайм. со взломом любого шифрования

>>316647219
>>316647407
Сообщение ОPа 1: "Так в этом и смысл, чтобы потом в ZIP и RAR и по новой."

Анализ: ОP предлагает после "сжатия" своей программой, дополнительно сжимать полученный файл .ctxt архиваторами ZIP и RAR. Он ожидает, что это приведет к еще большему сжатию.

Почему это не работает (или работает не так, как он думает):

.ctxt - уже zlib-сжат: Важно помнить, что программа ОPа уже использует zlib для сжатия строки хэшей (последний этап функции compress). Поэтому файл .ctxt уже является zlib-сжатым.

Дополнительное сжатие ZIP/RAR - бессмысленно (или почти бессмысленно): Попытка сжать уже сжатый файл (.ctxt) с помощью ZIP или RAR вряд ли даст значительный дополнительный выигрыш в размере. Архиваторы (включая ZIP и RAR) хорошо работают на несжатых данных, находя в них повторяющиеся паттерны. Но когда данные уже хорошо сжаты (например, zlib-ом), в них остается очень мало избыточности, которую можно дополнительно "выжать". В лучшем случае, вы получите небольшое уменьшение размера, в худшем - размер файла даже может немного увеличиться (из-за накладных расходов на формат архива).

"Магия" 10-20x уменьшения размера - ложная: Заявление ОPа о том, что размер файла уменьшится в 10-20 раз после дополнительного сжатия ZIP/RAR, не подтверждается реальностью и, скорее всего, является выдумкой. Если такое уменьшение и наблюдается в каких-то единичных случаях, то это, вероятно, связано с какими-то особенностями конкретных тестовых файлов, а не с "магией" алгоритма. В общем случае, дополнительное сжатие zlib-сжатых данных не даст такого эффекта.

Сообщение ОPа 2: "Что нужно сделать: 1) переписать на C++ или CUDA 2) переписать логику, чтобы не ел 34 ГБ RAM... 3) Добавить рекурсию после сжатия..."

Анализ: ОP предлагает направления для "улучшения" своей программы.

Почему эти "улучшения" не исправят фундаментальные проблемы:

Переписывание на C++/CUDA (ускорение): Переписывание кода на C++ или CUDA (для GPU-ускорения) может сделать программу быстрее, но не решит проблему неэффективности самого алгоритма сжатия и огромного словаря. Скорость работы не является главной проблемой, когда сам принцип сжатия ошибочен.

Перенос словаря на SSD (уменьшение RAM): Перенос словаря с RAM на SSD (диск) не уменьшит размер словаря. Это лишь позволит работать с очень большими словарями, не перегружая оперативную память. Но это замедлит доступ к словарю и, следовательно, скорость сжатия/распаковки. Кроме того, это не отменяет того факта, что словарь все равно нужно хранить и передавать для распаковки.

"Добавить рекурсию после сжатия" (бессмысленно): Предложение "добавить рекурсию после сжатия" не имеет смысла и не понятно, что именно ОP имеет в виду. Вероятно, это еще одно проявление его непонимания принципов сжатия. Рекурсивное применение одного и того же алгоритма сжатия к уже сжатым данным (которые уже и так zlib-сжаты) не приведет к "вечному сжатию" и не обойдет законы теории информации.

Сообщение ОPа 3: "Принцип работы... поместить сжатый файл в ZIP и RAR, то его размер в 10-20 раз МЕНЬШЕ ОРИГИНАЛА..."

Анализ: ОP повторяет свое неподтвержденное и, скорее всего, ложное заявление о 10-20-кратном уменьшении размера после дополнительного сжатия ZIP/RAR.

Почему это неправда (повторение): Как уже объяснялось выше, дополнительное сжатие уже zlib-сжатых данных (файла .ctxt) не даст такого эффекта. Это противоречит как теории, так и практическому опыту.

Сообщение ОPа 4: "Общий для кодирования и декодирования... на всех компьютерах он одинаков."

Анализ: ОP утверждает, что словарь является "общим" и "одинаковым на всех компьютерах".

Почему это вводит в заблуждение (полуправда, но не в том смысле, в котором он думает):

Статические словари (уровни 0-2): Словари для уровней 0, 1 и 2 действительно являются статическими и предопределенными. Они загружаются из файлов .npy и не меняются в процессе сжатия/распаковки. В этом смысле они "общие".

Динамический словарь (уровень 3) - не общий: Словарь для уровня 3 (PersistentCacheDictionary) является динамическим и не является общим. Он пополняется в процессе сжатия новых файлов и зависит от данных, которые вы сжимаете. Поэтому, если вы сожмете разные наборы файлов, словари уровня 3 будут разными.

Общий словарь бесполезен (если он не включен в архив): Даже если бы словарь был полностью статическим и общим, это не имело бы практической пользы, если бы он не был включен в сжатый архив. Хранение словаря отдельно от сжатых данных делает архив бесполезным без доступа к этому словарю.

Окончательный вывод:

Все последние сообщения ОPа не добавляют ничего нового к его ошибочной идее "вечного сжатия". Он продолжает настаивать на нереалистичных заявлениях, непонимании принципов сжатия и псевдонаучных терминах. Дополнительное сжатие ZIP/RAR не решит фундаментальных проблем его метода, а "улучшения", которые он предлагает, не сделают его алгоритм эффективным или практичным.

Пожалуйста, не тратьте время на дальнейшие попытки "улучшить" этот скрипт в направлении, предложенном ОPом. Сосредоточьтесь на изучении реальных алгоритмов сжатия данных и принципов теории информации. Это будет гораздо полезнее.

> пытаться объяснить что-то шизофренику
Вы не понимаете сути шизофрении, эти люди реально верят, что у учёных ошибки в расчётах, а они самые умные и все им скоро хуй сосать будут и пытаться забрать их гениальные труды. Не тратьте время.

>>316643851 (OP)

>>316647522
> а прикиньте через несколько лет просто каждое устройство с завода будет иметь словарь этот ебучий,
Так может ляпнут ток тупня. Словарь по заявлениям больного Опа КОНЕЧЕН. А комбинаций информации - очень много и постоянно создаются новые. Адеквату должно быть понятно что конечным словарём сжать бесконечность невозможно В ПРИНЦИПЕ.

>>316643851 (OP)

>>316647610

ОП на самом деле гений, он изобрел метод бесконечного расширения данных. Добавив всего лишь один цикл в код - можно циклом повторной архивации можно из 1 сраного файла на 1 мб забить любую память бесконечным числом словарей!

бамп

>>316647798
я конечно гуманитарий, но мне всегда нравилась мысль что букв в алфавите мало, а написать вариантов книг можно условно бесконечно
сможешь привести пример для даунов как я?

>>316647798
вся инфа в мире это 60 гб. всё остальное это дубликаты этих 60 гб в разных частотных порядках. как эти порядки расположены ? код и метод выше. формула есть

программе НЕ ГЕНЕРАТОР а метод словаря.

Метод геератора ещё мозгов не хватает и у ИИ не может закодить

хуй знает, меня вайбы этих тредов отправляют в воспоминания когда двач еще был тортом

>>316647855
Бред яна слота даже такого нету

>>316647855
Дегенерат блять, того додика грохнула мафия, ибо он набрал бабла а его хуита не работала.

>>316643851 (OP)
Давай оп я в тебя верю туда сюда хуе мое короче делай технологическую сингулярность, этот мир слишком скучный без неё.

>>316647962
Пидоран, если ты такой умный почему ты ещё скрипт не написал? Иди нахуй отсюда пидор

>>316647962
> вся инфа в мире это 60 гб.
Долбаёб, каждая фотка с рук - уникальная смесь цветовых байтов. что в слове «уникальный» тебе не поняно, придурок?

Пойду куплю винрар чтобы очко у опа сгорело нахуй, лучше винрара ничего нету

>>316647927
вот бесконечный генератор страниц книг.

https://codepen.io/procoders000001/pen/QwLmZaK

суть, вся лингвистика основана на подразделах, действиях, мотивах, и классах

их порядка несколько сотен. но всё можно запрогать

тут всего 6 классов, ( кто, что делает, где, и когда )

так вот вся информатика это 60 гб сбрученных древ.

Также работает ДНк, в днк сказано сколько листьев на ветке. и сколько веток на стволе. В днк нету дубликатов 50 тысяч листьев, и 400 веток. там всего числа, метки, количество повторов.

>>316647962
> вся инфа в мире это 60 гб
Сколько гигабайт в приснившимся самому себе сне?

>>316648083
имел ввиду, чтобы тот анончик привел мне пример чего-то реально бесконечного и что нельзя описать одним словарем условно

к тебе уважаемый сжатошиз 0 вопросов, верю в тебя

>>316648088
Ноль, если сон не запомнился

ВЫЧИСЛЯЙТЕ ПРОТЕИНЫ
ВЫЧИСЛЯЙТЕ ПРОТЕИНЫ
ВЫЧИСЛЯЙТЕ ПРОТЕИНЫ

>>316643851 (OP)
Я верил в тебя, но можешь видос с архивацией и разархивацией залить? Оно нормально работает? Например, для 500гб архива

Почему если какая то эволюция смогла создать биологический интеллект, то человек с этим интеллектом все никак не может создать интеллект искусственный?

>>316648083
Показывай учёную степень в области ДНК. Иначе в твой бред никто верить не будет

>>316647927
Ты не догнал, алфавит для инфы - это две «буквы»: 0 и 1. Вот ими всё и описывается. Оп-хуй предлагает кодировать всё не простыми 0 и 1, а заранее записанными последовательностями 0 и 1. Причём их список конечен. Ну то есть типа как китайцы иероглифами, и у них как раз бывает пиздец, потому что новое слово с нихуя просто так не сделать. Так и у этого долбаёба весь его словарь не сможет описать бесконечность инфы.

>>316648060
>каждая фотка с рук - уникальная смесь цветовых
ты знаешь что такое бинарное кодирование? у 4 бит всего 16 комбинаций
джепег это RLE усреднённых рядов цветов 32 бита. А у меня всё это в словарях, но и сами сжатые данные и словари можно в рекурсии сжимать

Давай "так" без выдачи секретов, страннн

Американцы подтвердили что ключи шифрования невозможно хранить в радиоволнах ибо китайцы и русские могут их ломать ( мгновенно ) а это алгоритм разлоежния

>>316648066
7z бесплатный, лол. Жмут rar и 7z +- одинаково.

>>316648185
А что будет когда протеины вычислятся?

>>316646710
Я не в курсе что там за идея у него, но если у тебя информации много, а словарь один это становится выгодно для размеров суммарных файлов больше словаря.

>>316648060
В том же числе Пи содержится ВСЯ информация которая только может быть. Проблема только в том на какой она там позиции...

>>316648298
Долбаёб, каждая точка обычного жпега = 24 бита, 3 цвета, придурок. Конечно, не все 16 млн комбианций есть в обычной фотке. Допустим их 100-200 тыщ. И эти 100-200 тыщ рассеяны по двумерной матрице в разнообразных сочетаниях. Ты полный даун, если думаешь что твоих 40гб хватит на все фотки земли. Ты дважды даун, если думаешь что однократно хорошо сжатое сожмётся повторно также хорошо.

>>316647798
>Адеквату должно быть понятно что конечным словарём сжать бесконечность невозможно В ПРИНЦИПЕ.
Возможно, конечно. Перестановкам и комбинированием частей словаря так-то.

>>316648088
вся вселенная и что либо это 60 гб. а 60 гигов это 4 миллиарда комбинаций меток 65 к пар. всё остальное это ссылки на эти 60 гб. тут, уж будут прорывы в физике да во всём. частиц нету, атомов нет, это ссылки на темную энергию и всё. всё есть дубликат дубликата. ( частиц, атомов, домов, панелек да что угодно )

>>316648406
Значит нужно вычислять число пи со словарем.

>>316648475
60гб как то маловато для вообще всех возможных комбинаций.

>>316648406
> Проблема только в том на какой она там позиции.
Воот, а без знания этой позиции можно сказать что там НИХУЯ не содержится, ибо бесполезный мусор - суть отсутствие информации.

>>316643851 (OP)
Опять выходишь на связь, шизло!

Хочешь чтоб тебя опять обоссали?
Ну открывай ротешник
СПАСИБО АБУ ЗА ХОРОШИЕ ТРЕДЫ

>>316648332
Из дурки выпустят.

>>316648197
код на питоне работает медленно 100кб 1сек. видео в первом посте

перепись на C++ ускорение в 40 раз.
Перепись на CUDA ускорение в 80-200 раз

>>316648548
Ты просто не в силах осознать что оп буквально приближает новую эру человечества

>>316648222
>Так и у этого долбаёба весь его словарь не сможет описать бесконечность инфы.
методом словаря смог.

Скоро будет арифметика, по типу 2 в степени 400 ( 400 значное число )

>>316648470
Так долбаёбу хоть ссы в глаза - всё божья роса. Он считает что 60 гб достаточно. Больной, хуле.

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

>>316648587
Ты мне нравишься. У меня эта сохраненка лежит на телебоне.

Почему ты сразу на плюсах не попросил? Я теперь так делаю.
И еще вопрос - какие сферы приложения?

>>316648526
Так я не ОП и я не предлагаю что-то кодировать числом Пи. Это просто как пример.

Но maybe теоретически сделать набор блоков определенной длинны M, а затем кодировать блоки файлов ключами длинной меньше M, путем комбинирования блоков из словаря...

>>316648629
Смог ты лишь насрать в тред и больше нихуя. Тебе про Гугл уже сказали. Ты, долбаёб, гениальнее гугла и всей толпы тамошних в говне мочёных? Ню-ню, шизик, таблетки прими.

>>316648587
>перепись на C++ ускорение в 40 раз.
>Перепись на CUDA ускорение в 80-200 раз
Откуда ты эти сисла каждый раз берешь, шизло?

>>316648464
Тебе дан исходный код и программа ты сам сможешь разложить свой джепег на древа битов и увидеть какие пары промаркированны.

Получай нобелевскую премию. что уж тут.

весь сбрученный 32 битный код длинны это 16 гб данных но до сегодняшнего дня ссылки на сегменты. больше чем сам 32 бит.

Где приложение чтоб я мог архивировать уже терабайты видосов?

>>316643851 (OP)
Бля, у этого шизоида опять фаза активности между делириями.

У МЕНЯ ВОПРОС ОПУ

Предположим, что этот алгоритм может сжать любые данные до объема, не превышающим, например, 60 Гб.

60 Гб это примерно 510^11 бит

Представим гипотетического фотографа, который отснял 510^11 + 1 уникальных снимков. Он решил сжать все эти снимки по твоему алгоритму. Даже если предположить, что каждое фото сожмется до невероятного 1 бита, все равно останется одно фото, которому не хватило даже этого.

Вопрос: КАК ЭТОТ ГИПОТЕТИЧЕСКИЙ ФОТОГРАФ ПОЛУЧИТ СВОИ СЖАТЫЕ ФОТКИ НАЗАД? Получается что хотя бы одну он проебет

>>316648923
Оп это мессия нового технологического мира

>>316648743
Долбаёб, жпег УЖЕ ПОЖАТ фурье-сжатием.

>>316648664
>И еще вопрос - какие сферы приложения?

сингулярность, рекурсивное ускорение вычислений и рекурсивное сжатие инфы.

>>316648968
Тока гугл об этом не знает, бля. Пиздец шизоидов на двоще, опа нада пристрелить чтоб не мучался.

Принцип Работы, файл сжимается, размер его сохраняется но это теперь файл это ссылки на 34 гб словарь.

А почему именно 34гб? Это какой-то предел? Словарь потянет терабайты разнородной информации (втч бинарники с рандом кашей если открыть их как plain raw).

Мне нравятся твои треды, анонч. Не обращай внимание на тех, кто клеимит тебя шизом. Они банально не разложили твою работу по частям чтобы доказать что ты в чем-то неправ.

>>316648990
Оно реально может ускорять вычисления?

>>316648970
дебилоид. джепег это набор битов. 1 мегабайт 1 миллион цифр. у меня в словаре все числа разложены ))) любых комбинаций которые могут быть !!!!!

понимаешь?!

когда AGI будет, будут симуляции как наш мир, ты сможешь прожить мою жизнь а я твою. хотя до жопы сколько раз это повторялось

>>316649053
Да, рекурсивно

>>316649057
>словаре все числа разложены ))) любых комбинаций которые могут быть !!!!!
Словарь бесконечный?

>>316649062
Ну я немножко начал тебя понимать. Сорян за тупость (нет тех вышки).

То есть мы рекурсивно идем по ссылкам на словарь и восстанавливаем? Но будет ли это быстрее?

ага братва охуенно зацените 3нф я проебался или не особо?

Оп, я нашел видео с твоим участием.

>>316649140
Да, за счёт рекурсии

>>316648961
Есть сундук с сокровища, есть карта сокровищ.

Сокровища можно не тоскать с собой а закопать где знаешь ток ты

А таскать только карту.

В математике могу расписать детально, щас. подожди. Тоже хочешь нобеля?

>>316649089
> Словарь бесконечный?
В том-то весь и фикус, долбаёб утверждает что КОНЕЧНЫЙ словарь достаточен для всего, а ещё можно сжать уже сжатое и так раз так несколько. В результате фильм сжимается до 8 килобайт, лол.

Этот метод сжатия данных основан на иерархической замене повторяющихся битовых паттернов с использованием системы словарей, разделённых на уровни. Каждый уровень работает с определённой степенью абстракции, что позволяет эффективно сжимать данные, сохраняя при этом возможность их восстановления без потерь. Метод сочетает статические и динамические словари, а также использует гибридное хранение данных (в оперативной памяти и на диске) для оптимизации производительности.
Основные принципы метода

Разбиение данных на битовые блоки
Исходные данные разбиваются на небольшие блоки, например, по 2 бита. Это позволяет работать с минимальными единицами информации, которые легко анализировать и заменять. Например, последовательность битов "00 01 10 11" разбивается на четыре блока: 00, 01, 10, 11.

Иерархия словарей
Метод использует несколько уровней словарей, каждый из которых отвечает за сжатие данных на определённом этапе. Уровни 0–3 являются статическими, а уровень 4 — динамическим с адаптивным кэшированием.

Уровень 0: Заменяет пары битовых блоков на коды. Например, пара "00 01" может быть заменена на код "A".

Уровень 1: Работает с кодами, полученными на уровне 0, и заменяет их пары на новые коды. Например, пара "A B" заменяется на код "X".

Уровень 2 и 3: Продолжают процесс сжатия, увеличивая степень абстракции.

Уровень 4: Динамический словарь, который хранит наиболее часто используемые паттерны в оперативной памяти для быстрого доступа, а редко используемые — на диске.

Адаптивное кэширование
Уровень 4 использует алгоритм LRU (Least Recently Used — "наименее недавно использованный") для управления кэшем. Это означает, что если кэш переполняется, из него удаляются те элементы, которые дольше всего не использовались. Это позволяет эффективно использовать ограниченные ресурсы оперативной памяти.

Генерация хэш-кодов
Для представления сжатых данных используются уникальные хэш-коды, которые генерируются на основе кастомного алфавита. Например, код может выглядеть как "A3Xj9K". Это позволяет компактно хранить данные и быстро их идентифицировать.

Сжатие и восстановление данных

Сжатие: Данные проходят через все уровни словарей, где повторяющиеся паттерны заменяются на коды. На каждом уровне степень сжатия увеличивается.

Восстановление: Процесс происходит в обратном порядке. Коды последовательно заменяются на исходные битовые блоки, что позволяет точно восстановить данные.

Гибридное хранение
Для оптимизации производительности метод использует два типа хранения:

Оперативная память (RAM): Хранит наиболее часто используемые паттерны для быстрого доступа.

Диск: Хранит редко используемые паттерны, что позволяет экономить оперативную память.

Эффективность метода
Метод обеспечивает высокую степень сжатия для структурированных данных, таких как тексты, таблицы или изображения. В зависимости от типа данных, сжатие может достигать 5–20 раз. При этом сохраняется возможность быстрого доступа к данным благодаря адаптивному кэшированию.

Применение
Метод может использоваться в различных областях, где требуется эффективное сжатие данных:

Архивирование файлов.

Передача данных по сети.

Хранение больших объёмов информации.

Оптимизация работы баз данных.

Преимущества метода

Высокая степень сжатия: Благодаря иерархии словарей и адаптивному кэшированию, метод эффективно сжимает данные.

Быстрый доступ: Использование оперативной памяти для хранения часто используемых паттернов ускоряет процесс сжатия и восстановления.

Гибкость: Метод может быть адаптирован для работы с различными типами данных.

Масштабируемость: Добавление новых уровней словарей или увеличение размера кэша позволяет улучшить производительность.

Пример работы метода

Исходные данные: "00 01 10 11 00 01"

Уровень 0: Заменяем пары битов на коды:

"00 01" → "A"

"10 11" → "B"

"00 01" → "A"
Результат: "A B A"

Уровень 1: Заменяем пары кодов на новые коды:

"A B" → "X"
Результат: "X A"

Уровень 2 и 3: Продолжаем процесс сжатия.

Уровень 4: Сохраняем результат в кэше или на диске.

Заключение

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

>>316649177
Хорошо. Пруф концепта бы. Например, сложное вычисление.

Ты охуенен.

>>316649265
>New chat
Ты был близок

>>316649296
Фиббоначи

>>316649249
>8 килобайт
Почему не до одного бита тогда?

>>316649249

Уровень 0: 16 пар 8 байт/пара = 128 байт

Уровень 1: 256 пар 8 байт/пара = 2 КБ

Уровень 2: 65 536 пар 8 байт/пара = 512 КБ

Уровень 3: 4 294 967 296 пар 8 байт/пара = ~ 34 ГБ

>>316649167
Вам говноедам лишь бы в дилдоки долбиться и 100500 тред пилить про хуи и тяночкинидают.

Один нормальный тред за выходные и то ОПа шизом нонстоп клеимите. Было бы тут даже 10 таких постеров, двощ был бы совершенно другой бордой, дающей за щеку всем пикабу даже без ваших мамкиных джокеров с набегами. Чисто интеллектуально.

>>316649354
Палево жи. С одного бита хомяки догадаются что гонево всё что он пиздит. А 8 килобайт - это жи целых 8192 байта, блять! Многа, ага, целый фильм можна закодировать, лол.

>>316649387
Нет, это хуже чем дилдаки, блять. Те хоть простые пидорасы, чё с них взять. А оп-хуй этого треда походу тралль зелёный, спецом мозги заворачивает гуманитариям.

>>316643851 (OP)
А для каждого файла будут свои собственные словари или словари всегда одинаковые?

>>316649585
Словарь один

>>316649613
А события, которые еще не произошли, тоже будут в этом словаре?

>>316649323
Можно для тупеньких? Вот есть 10000 операций умножения и деления. Это занимает N времени на системе S. Можно ли при помощи фибоначи это оптимизировать или оно уже оптимизировано?

Допустим, возьмем твои словари. Это может сократить время операции над числами?

>>316649369
В гугл иди, дебил, деньгу зашибать будешь, россия скален, каждому двощеру по три тяночки. Тебе памятник поставят, ёпт. В виде дилдака самосжимаемого, лол.

вот код на С++ надо скомпилировать да но качается 20 гб IDE говна компиляторов

https://drive.google.com/file/d/1eUQYAwf3WmTADBu-ypTEnzjAKaDbaDOA/view

>>316649613
Дак зачем их хранить тогда на диске? Можно же в процессе шифровки\расшифровки динамически куски словаря генерить в памяти. Обращений к диску не будет, скорость в разы возрастет

>>316649663
Компилятор дай бог пару сотен мегабайт весит

>>316649699
До этого я еще не додумался

>>316649546
>мозги заворачивает гуманитариям
Конкретно твои доёбы до его концепции? Я вижу проблему в разжатии, с другой стороны если это ссылки и большая база, то почему нет? Мб не сильно медленнее текущих архиваторов.

>>316643851 (OP)
Под Болженос есть с поддержкой клавиаткры на равно устойчивых триггерах? Ну ч что бы не конфликтовала софтина с антивирусом Бабушкина.

>>316649656
вчера WD и сандиск распались, на две конторы раздельные а ты хочешь что бы всё IT легло и обанкротилось? у меня и тут есть математическое доказательство, но я не хочу что бы моё ебло в каждую школу лепили и везде обсуждали.

новый джобс. да?

>>316643851 (OP)
Это классическая попытка создать "вечное сжатие", но она нарушает фундаментальные принципы теории информации. Давай разберём, почему:

1. Ограничения теоремы Шеннона
Шеннон доказал, что любой источник информации с энтропией
𝐻
H бит/символ может быть сжат не менее чем до
𝐻
H бит/символ, но не бесконечно. Любая попытка сжимать файл ниже этого предела без потерь невозможна.

2. Обман со словарём
Ты предлагаешь использовать общий словарь размером 34 ГБ, который содержит 4 294 967 296 пар 8-байтовых значений.
Файл сжимается в ссылки на этот словарь, а не в реально меньший размер данных.
Но если словарь неизменный и общий, то вся магия рушится: ведь это не сжатие, а просто перекодирование, где ты зависишь от внешнего ресурса.
3. ZIP и RAR не доказывают сжатие
Ты пишешь, что "ZIP и RAR ещё уменьшают сжатый файл в 10-20 раз". Это прямо говорит о том, что "сжатый" файл на самом деле не хаотичный и содержит предсказуемую структуру, удобную для стандартных архиваторов. Если бы твой алгоритм работал как заявлено, ZIP/RAR не смогли бы ничего сжать.

4. Рекурсия сжатия — невозможна
Если бы твой метод позволял повторно сжимать данные без потерь, это означало бы, что можно взять любой файл (например, 1 ТБ), запустить твой алгоритм 1000 раз и получить 1 байт, а потом восстановить его обратно. Это нарушает всю физику информации.

Вердикт
Это не "вечное сжатие", а просто кодирование ссылками на огромный словарь.
Такой метод не уменьшает информационную энтропию, а лишь маскирует её через внешний источник данных.
Для реального применения потребуется иметь этот словарь у всех пользователей, а значит, файлы уже нельзя считать "самодостаточно сжатыми".
Любая попытка реальной рекурсии приведёт к информационному парадоксу: или энтропия растёт, или ты просто создаёшь цепочки ссылок, которые нельзя сжать бесконечно.
Что делать дальше?
Если ты хочешь реальный эффективный алгоритм сжатия, нужно:

Изучить существующие методы (LZ77, LZMA, BWT, ANS).
Оптимизировать работу со словарём, но не думать, что это "магическое сжатие".
Оценивать энтропию данных перед сжатием, чтобы понимать, насколько их можно ужать.
Но "вечное сжатие" — это просто красивая мечта, которая физически невозможна.

>>316649748

>>316643851 (OP)
пегги дудочник ты?

Есть словарь под видео? Там же чисто надо все оттенки сколько их там миллионов запихнуть в словарь и все. В видосах же все одинаково в принципе. И пусть сжимает видосы до пары мегабайт хотя бы бд ремуксы.

>>316649790
Как заебали долбоебы с нейросетками

>>316649852
Типа ОПа, да?

>>316649886
В том числе

СКИНЬТЕ ШРЕКА ПОЖАЛУЙСТА ИЛИ ДРУГИЕ ФИЛЬМЫ.
Пишу с PSP vita , и не хватает памяти! дайте посмотреть.

ребята, сказки не сказки, а всё реально

https://replit.com

Функция AUTOMATIC DEVELOPER - пишет полностью прогу, исправляет все ошибки, проводит все тесты, всё силами ИИ, эменно этот ИИ написал для линукса сжималку по ТЗ
минусы
стоит 15 $ в месяц

мне кубики за 3 мин с полным дебагом скодило АВТОМАТИЧЕСКИ
погромизды не нужны уже ))

https://codepen.io/procoders000001/pen/EaxjLvm

>>316649852
Потому что разъебывают опа по фактам, да?

>>316649928

Почему ОП ещё не сжал дамп Флибусты до 1 килобайта? Сколько можно ждать?

>>316643851 (OP)
Это классический пример мошенничества или просто шутки, связанной с невозможностью «вечного сжатия» данных без потерь.
🚨 Почему это невозможно?

Теорема Шеннона и предел сжатия
Клод Шеннон математически доказал, что существует минимально возможный размер для хранения информации без потерь.
Если бы можно было «бесконечно сжимать», то любой файл можно было бы представить в одном байте, что абсурд.

Парадокс вечного сжатия
Если ты сжал файл и получил меньший размер, это значит, что там была избыточность.
Если файл уже сжат до предела (например, ZIP, PNG, MP3), его невозможно сжать дальше без потерь.
Любая система, обещающая «вечное сжатие», либо теряет данные (lossy compression), либо блефует (использует огромные внешние словари, которые сами по себе весят больше).

Фокус со словарём на 34 ГБ
Авторы идеи предлагают сжимать файлы, заменяя их на ссылки в огромном предопределённом словаре.
Но этот словарь сам занимает 34 ГБ, а значит, реальная экономия отсутствует.
Это похоже на попытку закодировать файлы, но если словарь заранее не знает данные, он их не сможет восстановить.

Фейковые обещания «Zip и RAR сжимают ещё больше»
ZIP и RAR используют стандартные алгоритмы сжатия (Huffman coding, LZ77 и пр.).
Если у тебя уже максимально сжатый файл, второй раз его сжать невозможно.
Если ZIP или RAR вдруг «сжимает» этот якобы «сжатый» файл ещё сильнее, значит, он был не сжат на самом деле!

⚠️ Вердикт:

Это либо обман, либо эксперимент с большими предопределёнными словарями, который на практике не даёт никакого выигрыша.

Лучше не скачивай эти файлы — они могут быть вредоносными! 🚨

>>316643949
Зашёл в тред и сразу проиграл

>>316649995
spasibo!

>>316650068
Че вы носитесь со своей флибустой? Там хоть годнота есть или там один просроченный никому не нужный кал, написанный литературными неграми?

Допустим можно сделать словарь N-уровня. Его можно хранить в облаке, а аннигилятор опа - тонкий клиент.

>>316645088
если мы говорим про 60 гб
то это 480 миллиардов бит.
якобы уникальной информации

но если сделать к этой информации +1₂ это уже можно сжать?

>>316649823
Хороший сериал. И хорошо что на дваче есть как минимум 1 такой персонаж. Значит трушная панк культура не проебана. Не удивлюсь если ОПу за тридцатник, потому-что он больше похож на олда, который стремится что-то пилить и кайфовать от этой хуйни.

Даже если он не прав, он по крайней мере что-то делал, набивал шишки. Это охуенно.

>>316650184
Это его домашнее задание, я сам книги не читаю и хз чё там (быдло)

>>316649949
Фри тайер?

СЖАЛ КУРСАЧ
@
ПОЛУЧИЛ 1 БИТ + СЛОВАРЬ
@
СЖАЛ СЛОВАРЬ
@
ПОЛУЧИЛ БИТ КУРСАЧА + БИТ СЛОВАРЯ
@
ПОСЛАЛ ПРЕПОДУ 01
@
ПРЕПОД РАЗОРХИВИРУЕТ
@
ВМЕСТО КУРСАЧА ПОЛУЧИЛИСЬ НЮДЕСЫ МАМЫ ОПА

>>316650452
Норм бугурт.

ОП, что по коллизиям словаря?

>>316650113
все считали LPU невозможным поэтому никто не инвестировал даже в научные работы по математике а сейчас такое, у Nvidia выпали волосы на жопе. впрочем просвящайся.

>>316643851 (OP)
Я так и не понял как 34 гб будет достаточно для всех комбинаций в мире существующих. Объясни на пальцах.

>>316649949
И чем этот репит лучше бесплтных чатагпт или китайской хуйни?

Ну наконец-то полезные треды в /b

>>316648303
>7z бесплатный
интерфейс говно

>>316650650
>все считали LPU невозможным
Кто? Просто сейчас там дикий запад сейчас в работах и инвесторов засыпают миллионами пегов дудочников. OpenAI вообще из мутной лабы вышел. Посмотри их старые ролики. LPU под узкую задачу, когда гуглам нужны универсальные чипы для того же дипмаинда под белки итп.

Бабки важны, но они не являются истинной причиной прогресса. Сейчас со старгейтом хотят залить деньгами, при том что инвесторы кремниевой вливают в разы МЕНЬШЕ даже за несколько лет.

>>316650708
Ты ключевое не понял, этот дебил 3 раза сжимает уже сжатое. Дебилу говорят что уже сжатое не сжать, ибо нет избыточности, но дебил упорный и ебанутый, и гнёт свою дебило-линию.

>>316648298
ахахах зачет ОП тупой даун не шарит)

ЕСТЬ ИТОГИ РАБОТЫ ОПа?!

ЧТО БЫЛО СЖАТО ЗА ВСЕ ЭТИ ТРЕДЫ?
ЕСТЬ РЕЗУЬТАТ?!

>>316650886
Какой нахуй интерфейс, там его нет. И нахуй не нужен.

>>316646437
Он берёт слэб 34 гб информации и делает его общим для множества файлов с помощью ссылок. Эти ссылки хорошо сжимаются.
В мире программирования есть два ресурса на весах: память и цпу. Сократить потребление одного можно только за счёт увеличения потребления второго. Вот оп экономит память за счёт цпу. Технически в этом может быть смысл для длительного хранения бэкапов каких-то больших, наверное.

>>316651018
Итог один - оп-хуй просто зелёный тралль и регулярно подрывает жопы. Я не могу имаджинировать ебало того идиёта, что всерьёз начнёт эти дебилопроги проверять.

>>316643851 (OP)
>Уровень 0: 16 пар 8 байт/пара = 128 байт
Это не 16 пар, а 4294967295 пар если в битах и 256 если 1 байт кодирует только 0/1.

>>316650712
Чат гопота даёт битый кривой код который не запускается с 1 раза а ток с 10

тут же Функция AUTOMATIC DEVELOPER - ТЕБЕ БЛЯ автоматически пишет и ТЕСТИРУЕТ Что бы было без ошибок и тебя спрашивает, вы видите сайт, задание выполнено?

Функция AUTOMATIC DEVELOPER ток для богатых, за 15$ в месяц. но любое ТЗ тебе выполнит С НУЛЯ, с полным ДЕБАГОМ. те ИИ адекват. трудяга, разраб.

РЕШИЛ ЗАПОСТИТЬ В ШЕБМ ТРЕД
@
1 ГБ СЖАЛ ДО 1 МБ
@
1 МБ СЖАЛ ДО 1 КБ
@
1 КБ СЖАЛ ДО БИТА
@
НАПИСАЛ 0 И НАЖАЛ ОТПРАВИТЬ
@
СЕРВЕРА MAIL СРУ РАЗАРХИФИРОВАЛИ 0 КАК ЖЕСТКИЙ ГУРО ПРОН С ЛОЛЯМИ
@
Т-Т-Т-Т-ТАВАРИЩ ПРОКУРОР ВЫ ВСЕ НЕПРАВИЛЬНО ПОНЯЛИ
@

>>316651086
Терпи кал

>>316647219
СОСРЕДОТОЧЬТЕСЬ НА ИЗУЧЕНИИ РЕАЛЬНЫХ АЛГОРИТМОВ СЖАТИЯ ДАННЫХ И ПРИНЦИПОВ ТЕОРИИ ИНФОРМАЦИИ. ЭТО БУДЕТ ГОРАЗДО ПОЛЕЗНЕЕ.
Малолетний долбоёб без вышки ты?

>>316651461
Ботяра спок.

>>316651307
Он писал что это поможет также и для быстрого вычисления.

>>316643851 (OP)
> СОЗДАНА ПРОГРАММА ВЕЧНОГО СЖАТИЯ ИНФОРМАЦИИ БЕЗ ПОТЕРЬ
А программа вечной автономной капсулы когда будет создана, позволь узнать?

>>316643851 (OP)
а есть какой-то пруф того что оно работает? Хотя бы ссылка на какой-то другой источник информации, где это обсуждают менее именитые ученые чем на дваче? Типа технология должна быть безумно прорывной

pupu

>>316651944
Её мужики уже вскрыли.

>>316651808
В юникоде есть 140 тысяч символов

берём англ и русский словарь и маркируем 140 тысяч слов частых в 1 юникод

вуаля, 2 словарям передача инфы в 20 раз выше слов.

? учёные мочёные, ничего не хотят. поэтому всё через научный отдел двоща.

>>316644234
>>316643974
Давай я тебе 15 баксов скину и сделаешь вайпалку двача которая сама будет вайпать с телефона / компа и сама решать капчу.

>—Æ»šKš/O
Малолетний филолог, ты? Ты в курсе, что языки обходятся максимум 40 символов? Может всё таки хоть на заочное поступишь?
Блядь, теперь понимаю что вуз это база, отсеивающая даунов. Пусть малоэффективная, убивающая лучшие годы. но база.

>>316652694
Кому ты отвечал?

>>316652590
там он может запрогать локальный ИИ который обходит любую капчу сложную, при этом он не хочет комилировать под EXE а на линуксе без консоли не запустишь с мозго еблей

Вы можете не уметь рисовать но есть программы фото роботов там есть все шаблоны всех лиц и национальностей

не умея рисовать вы можете скрафтить любое лицо.

вес программы 100 мб шаблонов 3 тысячи

так вот, по поводу сжатия, шаблонов бинарного кода всех прог в мире всего 60 гб. или 4 миллиарда меток для пар 16 бит которые кодируют 64 бита.

>>316652933
Что у вас там за ебля с консолью? Пишешь тулзу с аргументами, компилируешь, пердишь. Можешь сверху вообще вебинтерфейс (админку) въебать, чтобы не ебаться с терминалом. Будет кроссплатформенная залупа.

>>316653069
Пчел, у тебя получается оооооочень медленный архиватор. Ты сам это пруфанул в треде, где 100кб заняли 1с. Это даже для бюджетного железа из 2010 очень медленно.

Метод и прога кстати решает задачу теории 3 тел.

Думайте.

>>316653200
уже готово на С++ но компиляция оборвалась так как нету злиб в визуал студио 2022

все среды разработки говно, и ты просто так не создашь EXE

>>316650904
Сжатое можно разобрать на кортежи бинарного кода. и комбинировать и ставить метки парам а потом и самим парам. метод позволяет делать ссылки короче самого бинарного с помощью словаря древ.

>>316644615
Так это потери в памяти, т.к например 111 = 1 11 = 11 1; Если идти по картинке 1, не выполняется условие беспрефиксности.

>>316647189
Я так понял, ты на питоне это написал, и пытаешься на плюсы переделать, чтоб побыстрее работало, но в С++ у тебя опыта нет. Если хочешь попробовать сжать большой файл на питоне, чтобы это было быстро, попробуй использовать just in time компилятор для питона - @njit из модуля numba

>>316646915
почему тебя ещё не обоссали?
>нужно 25 гб библиотек и зависимостей?

долбоебина, ты сам нахуярил вагон лишней хуеты вроде ДИАГНОСТИКА JAVASCRIPT и жалуешься, что зависимостей дохуя

>>316643851 (OP)
### Анализ текста о «вечном сжатии информации без потерь»
Рассмотрим заявленные тезисы и их соответствие реальности, опираясь на теорию сжатия данных и предоставленные источники.

---

#### 1. Утверждение: «Шеннон доказал, что существует предел сжатия, определяемый энтропией источника»
Правда: Да, это корректно. Теорема Шеннона о кодировании источника утверждает, что минимальный размер сжатых данных без потерь для источника с энтропией \( H(X) \) стремится к \( N \cdot H(X) \) бит для \( N \) символов .
Комментарий: Это фундаментальный принцип, который действительно ограничивает сжатие. Однако автор не учитывает, что энтропия зависит от статистических свойств данных. Если данные уже сжаты (например, архиватором ZIP), их энтропия близка к максимальной, и дальнейшее сжатие невозможно .

---

#### 2. Утверждение: «Создан словарь 4 уровня для рекурсивного сжатия»
Ложь/Неточность:
- Многоуровневые словари существуют (например, в алгоритмах типа LZ77/LZ78 или современных методах для бинарных изображений ). Однако их эффективность зависит от контекста и типа данных.
- Рекурсивное сжатие противоречит теории информации. После первого сжатия данные теряют избыточность, и повторное применение алгоритма не уменьшит размер, а может даже увеличить его из-за накладных расходов .
- Словарь 34 ГБ технически возможен, но непрактичен. Хранение и обработка такого объёма данных требуют огромных вычислительных ресурсов, а использование SSD вместо RAM замедлит работу в сотни раз .

---

#### 3. Утверждение: «Сжатый файл в ZIP/RAR становится в 10–20 раз меньше оригинала»
Ложь:
- Если исходные данные уже сжаты (например, текстовый файл, преобразованный в ZIP), повторное сжатие тем же алгоритмом не даёт выигрыша. Это подтверждается тем, что ZIP и RAR используют комбинацию LZ-методов и кодирования Хаффмана, которые устраняют избыточность на первом этапе .
- Для несжатых данных (например, текста) такие коэффициенты возможны, но не для всех типов файлов. Например, случайные данные (шифрованные файлы) сжать невозможно .

---

#### 4. Утверждение: «Метод даёт возможность сингулярности и AGI»
Спекуляция:
- Связь между сжатием данных и искусственным интеллектом (AGI) — это метафора, а не техническая реальность. Нейросетевые архиваторы (например, NNCP) действительно улучшают сжатие за счёт предсказания паттернов, но они не создают «сознание» .
- Заявление о «сингулярности» — маркетинговый приём, не имеющий научного обоснования.

---

#### 5. Практичность метода
Критические проблемы:
1. Ресурсоёмкость: 34 ГБ словаря — это гигантский объём даже для современных систем. Реализация на Python без оптимизации (как указано в тексте) будет крайне медленной .
2. Рекурсивное сжатие: Невозможно из-за теоретических ограничений. Даже если использовать GPU (CUDA), это не обойдёт энтропийный барьер .
3. Восстановление из общего словаря: Если словарь статичен, он должен содержать все возможные паттерны данных, что нереализуемо на практике. Динамические словари (как в LZ77) адаптируются под конкретные данные, но их размер ограничен .

---

#### Вывод
- Правдивые аспекты:
- Теорема Шеннона о пределе сжатия .
- Использование словарей в алгоритмах (LZ77, LZ78) .
- Ложные/Спекулятивные утверждения:
- Вечное рекурсивное сжатие.
- Уменьшение размера ZIP/RAR-архивов в 10–20 раз.
- Связь с AGI и сингулярностью.
- **Практичность**: Метод непрактичен из-за гигантских требований к памяти, неэффективности рекурсии и противоречия теории информации. Современные алгоритмы (PAQ, CMIX, NNCP) достигают лучших результатов без таких затрат .

Если цель автора — провокация или художественная метафора, текст интересен. Если же это попытка представить рабочий инструмент — это мистификация. Для реального сжатия стоит использовать проверенные методы: Brotli, Zstandard, или нейросетевые архиваторы вроде NNCP.

>>316653481
>все среды разработки говно, и ты просто так не создашь EXE
Мне похер, я на линухе компилю и в хуй не дую. Прогаю в VScode вообще.

>>316654185
если такой крутой то пиши на CUDA И получай нобеля.

>>316654206
мразь. ненавижу.

>>316654250
> NNCP
Сжатие нейронками
https://bellard.org/nncp/
Винда (CUDA): https://bellard.org/nncp/nncp-2024-06-05-win64.zip
Линух (CUDA): https://bellard.org/nncp/nncp-2024-06-05.tar.gz
Линух (Python+PyTorch, GPU required): https://bellard.org/nncp/nncp_v2-2021-02-06-1.tar.gz

>>316651932
Ну он долбаеб, оп придумал хуйню которой уже лет 70 ее тот винрар использует, только у него словари на 64 гига а пара мб. Если бы сжимание с 64гб словарем не занимало 15 секунд на 1мб файл его бы все использовали, но оно к сожалению занимает и хуй ты что с этим сделаешь.

>>316654185
Ему надо промт грузануть с нуля, чтобы тот сваял чисто на плюсах, ничего не зная про питон версию. И попросить как всю эту ебу компилить под его версией windows.

>>316654141
Нахуй ты его так жёстко приложил?

>>316654250
Чел, я с юристами бегала, и математиком пол года, хотела продать метод за 100 млн р а потом $

как правило эйчары и есть сами директора,,

Так в чём смысл в 95% случаев меня просили изложить полный метод и демонстрацию что БЫ МЕТОД СПИЗДЕТЬ, до меня дошло что нельзя продемонстировать метод, что бы не догадались, а догадаются всегда. А это значит, что я просто подарю метод корпорации или эйчару

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

повторяю.,у меня есть математическое доказательство, и оно продемонстированно в виде кода. в первом посте.

1 ) в мире и странах нету патентования методов и интерфейсов алгоритмов
2) создавать сервис писать готовую прогу на C++ и CUDA дохуя вложений.

так что лучше общественный прогресс будет. чем лишнее внимание

>>316654498

>>316654141
вот такая база на 60 гигов рекурсивно сжимает инфу

Пары бинарного кода 2 битного маркируются метками, а те пары тоже метками и так до 4 уровня. файл это метки 4 уровня.

или же 32 бита в 128 бит или же 16 бит в 64 бита и обратно

>>316654699
Тухлодырку ты хотела свою продать за сто лямов, а не метод сжатия

РАЗРАБЫ ГУГЛА И МАЙКОВ, ВАШИ ИИ НЕ МОГУТ КОМПИЛИРОВАТЬ ПРОГУ В EXE. ебланы.

OPEN AI звездаразы, мразИ, за 3 года не могут в EXE прогу отдебажить и скомпилировать

мрази. вам тут сингулярность показывают что всё есть дубликаты бинарного кода у 4 бит 16 комбинаций всего

>>316654967
ога. ток 95% Эйчаров и есть сами директора и пиздят методы и код. Так что удачи на себезах инсайды своей логики давать. лул

и свои методы и код ты нихуя не защитишь никак. ПРОБЕЛ. ТУПИК.

>>316643851 (OP)
>>316654699
Давайте проанализируем предоставленный код и его соответствие заявленным возможностям в тексте.

---

### Общее описание кода

Код представляет собой программу для сжатия данных, использующую рекурсивные словари (4 уровня) для замены повторяющихся блоков данных на более короткие метки. Программа реализует графический интерфейс пользователя (GUI) на основе библиотеки `tkinter`, а также поддерживает сохранение словарей между сессиями.

Основные компоненты:
1. Словари для сжатия:
- Четыре уровня словарей (`NUM_LEVELS = 4`), где каждый уровень отвечает за замену пар блоков данных на числовые метки.
- Первые три уровня используют статические словари, хранящиеся в `.npy` файлах.
- Четвертый уровень — динамический словарь, который хранит данные в оперативной памяти и на жестком диске.

2. Разбиение данных на блоки:
- Данные разбиваются на блоки по 2 бита (`BIT_BLOCK_SIZE = 2`).
- Эти блоки объединяются в пары, которые затем заменяются на метки из соответствующих словарей.

3. Хэширование:
- Используется пользовательская функция `int_to_hash` для преобразования чисел в строки фиксированной длины (`HASH_LENGTH = 7`).

4. Архивация:
- После сжатия данные дополнительно сжимаются с помощью `zlib`.

5. Графический интерфейс:
- Позволяет выбирать файлы для сжатия/распаковки, отображает информацию о размерах файлов и состоянии словарей.

---

### Что делает программа?

Программа выполняет следующие действия:

1. Сжатие:
- Исходные данные разбиваются на блоки по 2 бита.
- Пары блоков заменяются на числовые метки, используя словари четырех уровней.
- Результат записывается в выходной файл вместе с дополнительным сжатием через `zlib`.

2. Распаковка:
- Процесс обратный сжатию: метки извлекаются из файла, восстанавливаются пары блоков, а затем собираются в исходные данные.

3. Управление словарями:
- Словари первого уровня загружаются из предварительно созданных `.npy` файлов.
- Четвертый уровень использует кэш в оперативной памяти и постоянное хранилище на диске.

---

### Соответствие заявленному

#### 1. "Вечное сжатие без потерь"
- Анализ: Это утверждение ложно. Программа не обеспечивает "вечное" сжатие. На каждом уровне сжатия создаются новые словари, которые занимают место. В какой-то момент объём всех словарей превысит объём исходных данных.
- Практичность: Несмотря на это, программа может быть полезна для сжатия небольших файлов или данных с высокой степенью повторяемости.

#### 2. "34 ГБ словаря хватит всем"
- Анализ: Утверждение завышено. Размер словарей зависит от входных данных. Для больших объемов уникальных данных словари будут расти до тех пор, пока не достигнут ограничений системы.
- Практичность: Ограничение размера словарей (например, `np.uint32`) делает невозможным их бесконечное расширение.

#### 3. "Файл становится в 10-20 раз меньше после сжатия"
- Анализ: Это возможно только для данных с высокой избыточностью. Если данные уже оптимально сжаты, дальнейшее сжатие не даст значительного эффекта.
- Практичность: Эффективность сжатия зависит от типа данных. Для высокоструктурированных данных (тексты, логи) результат может быть хорошим, но для случайных данных — нет.

#### **4. "Использование метода Яна Слоота"**
- **Анализ**: Метод Яна Слоота никогда не был научно обоснован и считается мистификацией. Упоминание его имени здесь скорее маркетинговый ход.
- **Практичность**: Нулевая.

---

### **Практичность программы**

#### **Плюсы**:
1. **Наличие GUI**: Программа удобна для использования благодаря графическому интерфейсу.
2. **Модульность**: Код разделен на функциональные блоки, что упрощает его понимание и модификацию.
3. **Поддержка словарей**: Использование словарей позволяет эффективно сжимать данные с высокой степенью повторяемости.

#### **Минусы**:
1. **Ограниченная масштабируемость**: Размер словарей ограничен типом данных (`np.uint32`), что делает невозможным работу с большими объемами уникальных данных.
2. **Высокие требования к памяти**: Четвертый уровень требует значительного количества оперативной памяти для кэширования.
3. **Отсутствие инноваций**: Алгоритм не предлагает ничего нового по сравнению с существующими методами сжатия (например, LZ77, Huffman).

---

### **Заключение**

Программа работает как инструмент для сжатия данных с использованием словарей, но её заявления о "вечном" сжатии и универсальности ложны. Она может быть полезна для сжатия небольших или высокоизбыточных данных, но не является решением для масштабных задач.

Если вас интересуют практические применения, лучше рассмотреть современные алгоритмы сжатия, такие как Zstandard (Zstd), Brotli или LZMA, которые обеспечивают более высокую производительность и эффективность.

>>316655132
вот. поляки делают AAA екшены в то время как 99% населения в говне

>>316655132
Для улучшения кода данной программы можно предложить несколько подходов, основанных на общепринятых практиках рефакторинга и оптимизации кода. Ниже приведены конкретные рекомендации:

### 1. Удаление закомментированного кода
Закомментированные фрагменты кода могут сбивать с толку других разработчиков, которые будут поддерживать или модифицировать программу в будущем. Если такие фрагменты больше не нужны, их следует удалить [[3]].

### 2. Оптимизация использования памяти
Программа использует значительное количество памяти, особенно для четвертого уровня словаря. Чтобы минимизировать использование памяти:
- Рассмотрите возможность хранения словарей на диске вместо оперативной памяти.
- Ограничьте размер кэша для четвертого уровня, чтобы избежать переполнения памяти.

### 3. Использование более эффективных алгоритмов
Выбор правильных алгоритмов может значительно повысить производительность. Например:
- Используйте библиотеки сжатия данных, такие как Brotli или LZMA, которые показывают лучшие результаты по сравнению с `zlib` [[8]].
- Рассмотрите возможность применения алгоритмов с предварительно определенным словарем, если это соответствует вашим задачам [[9]].

### 4. Минимизация операций внутри циклов
Чтобы ускорить выполнение программы, минимизируйте количество операций внутри циклов. Например, вычисления, которые не зависят от итерации, можно вынести за пределы цикла [[5]].

### 5. Логирование ошибок
Текущая реализация логирования ошибок уже хороша, но можно добавить более детальную информацию о состоянии программы при возникновении ошибок. Это поможет быстрее находить и исправлять проблемы.

### 6. Улучшение структуры кода
- Разделите функциональность на более мелкие, специализированные функции. Это сделает код более читаемым и легким для понимания.
- Используйте классы для группировки связанных функций и данных, что также улучшит организацию кода.

### 7. Тестирование и проверка производительности
Добавьте юнит-тесты для ключевых функций программы. Это поможет убедиться, что изменения не приводят к регрессии. Также проведите профилирование производительности, чтобы найти узкие места в коде [[4]].

### 8. Документация
Добавьте комментарии и документацию к функциям и классам, чтобы облегчить понимание кода для других разработчиков. Хорошая документация также помогает поддерживать код в долгосрочной перспективе.

### Пример улучшений

#### Оптимизация функции `compress`
```python
def compress(data, dictionaries):
current_data = split_into_2bit_blocks(data)
original_length = len(current_data)

for level in range(NUM_LEVELS):
code_to_pair = dictionaries[level]
pair_to_code = code_to_pair if level < NUM_LEVELS - 1 else {}

# Предварительная подготовка данных вне цикла
if len(current_data) % 2 != 0:
current_data.append(0)

new_data = []
for i in range(0, len(current_data), 2):
pair = tuple(current_data[i:i+2])
if pair in pair_to_code:
code = pair_to_code[pair]
else:
code = len(code_to_pair)
if code >= np.iinfo(np.uint32).max:
logging.error(f"Dictionary level {level} reached maximum size limit.")
return None
code_to_pair[pair] = code
new_data.append(code)

dictionaries[level] = code_to_pair
current_data = new_data

return current_data
```

#### Добавление тестов
```python
import unittest

class TestCompression(unittest.TestCase):
def test_compress_decompress(self):
data = b"testdata"
dictionaries = [{} for _ in range(NUM_LEVELS)]
compressed = compress(list(data), dictionaries)
self.assertIsNotNone(compressed)
decompressed = decompress(compressed, dictionaries)
self.assertEqual(data, bytes(decompressed))

if __name__ == "__main__":
unittest.main()
```

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

>>316647407
слушай, у тебя проблема в том, что чтобы разметить, все значения 64х битного слова из словаря. тебе потребуется 64битная ссылка.

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

ты конечно можешь ссылать только на "популярные" комбинации слов. но так и обычные архиваторы работают.

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

>>316654983
ебучее тупое уёбище, ты же даже не понимаешь, что и зачем пихаешь в IDE

>>316655575
Анон, полегче будь. ОП просто мирный шиз, а не воюющий тупой дилетант. Не стоит на больного человека гнать.

>>316655488
На основе предоставленного кода и анализа его структуры, а также с учётом общих принципов оптимизации программного обеспечения, предлагаю следующие дополнительные улучшения для программы:

### 1. Оптимизация использования словарей
- В текущей реализации словари используются для хранения пар блоков данных. Однако размер этих словарей может быстро расти, особенно на четвёртом уровне. Чтобы минимизировать использование памяти:
- Рассмотрите возможность использования более компактных структур данных, таких как `array.array` или даже битовые массивы, если это возможно.
- Ограничьте размер словарей на каждом уровне, чтобы избежать их чрезмерного роста. Например, можно периодически очищать словарь, если он достигает определённого предела [[6]].

### 2. Параллельная обработка
- Для больших файлов процесс сжатия может быть довольно медленным. Использование многопоточности или многопроцессорности может значительно ускорить работу:
- Разделите входной файл на части и обработайте каждую часть в отдельном потоке или процессе.
- После завершения обработки всех частей объедините результаты. Это можно сделать с помощью модуля `concurrent.futures` или `multiprocessing` в Python [[9]].

### 3. Улучшение алгоритмов
- Алгоритмы сжатия могут быть оптимизированы для достижения лучших результатов:
- Рассмотрите использование более эффективных алгоритмов сжатия, таких как Brotli или Zstandard, которые показывают лучшие результаты по сравнению с `zlib` [[10]].
- Если данные имеют специфическую структуру, можно разработать специализированный алгоритм сжатия, учитывающий эту структуру.

### 4. Оптимизация работы с файлами
- Текущая реализация загружает весь файл в память перед обработкой. Для очень больших файлов это может быть проблематично:
- Реализуйте потоковую обработку файлов, где данные читаются и записываются по частям, не занимая всю доступную память.
- Это можно сделать с помощью буферизованного чтения и записи файлов [[2]].

### 5. Улучшение пользовательского интерфейса
- Графический интерфейс уже имеет базовый функционал, но его можно улучшить:
- Добавьте индикатор прогресса для операций сжатия и распаковки, чтобы пользователь мог видеть, сколько времени осталось до завершения.
- Улучшите визуальное оформление интерфейса, используя современные стили и темы, например, через библиотеку `ttkthemes`.

### 6. Добавление тестов
- Хотя в коде уже есть базовая проверка ошибок, добавление юнит-тестов поможет гарантировать правильность работы программы:
- Напишите тесты для основных функций, таких как `compress`, `decompress`, `split_into_2bit_blocks` и других.
- Проверьте работу программы с различными типами данных и большими файлами [[4]].

### 7. Оптимизация логирования
- Логирование ошибок уже реализовано, но можно улучшить его:
- Добавьте возможность настройки уровня детализации логов (например, DEBUG, INFO, ERROR).
- Включите в логи дополнительную информацию, такую как время выполнения ключевых операций, что поможет в диагностике проблем.

### 8. Работа с большими данными
- Для работы с действительно большими данными можно рассмотреть использование внешней памяти:
- Храните временные данные на диске вместо оперативной памяти, используя файлы временных данных.
- Это позволит обрабатывать файлы, размер которых превышает доступную оперативную память.

### 9. Документация
- Убедитесь, что код хорошо документирован:
- Добавьте комментарии к каждой функции, описывающие её назначение, входные параметры и возвращаемые значения.
- Создайте руководство пользователя, которое объясняет, как использовать программу и какие возможности она предоставляет [[5]].

### Пример улучшений

#### Реализация потоковой обработки
```python
def stream_compress(input_file, output_file, dictionaries):
buffer_size = 1024 * 1024 # Размер буфера: 1 МБ
with open(input_file, 'rb') as fin, open(output_file, 'wb') as fout:
while chunk := fin.read(buffer_size):
compressed_chunk = compress(list(chunk), dictionaries)
if compressed_chunk is None:
return False
compressed_bytes = zlib.compress(compressed_chunk.encode('utf-8'), level=9)
fout.write(compressed_bytes)
return True
```

#### Добавление индикатора прогресса
```python
def update_progress(progress_bar, value):
progress_bar['value'] = value
progress_bar.update()

progress_bar = tk.ttk.Progressbar(root, orient="horizontal", length=300, mode="determinate")
progress_bar.pack(pady=20)

# При сжатии или распаковке обновляйте индикатор
update_progress(progress_bar, percentage_completed)
```

Эти изменения помогут сделать программу более производительной, удобной для использования и надёжной.

я хуею шизов ПОЛОН ТРЕД!!!!!!!!!!!! они заполонили планету!!!1111

>>316655620
Вот ещё советы

https://chat.qwenlm.ai/s/3dde27e3-c1a1-4f25-8785-80ba722a0222

А теперь сиськи с супом на стол или будет бунт.

>>316643851 (OP)
Ваша идея о "вечном сжатии информации" звучит интригующе, но требует критического анализа с точки зрения теории информации и компьютерных наук. Давайте разберем ключевые моменты:

1. Теоретические ограничения сжатия данных
Теорема Шеннона о кодировании источников действительно утверждает, что данные можно сжать без потерь до размера, близкого к их энтропии. Однако это не означает, что можно создать алгоритм, который будет сжимать данные бесконечно. Энтропия — это предел, ниже которого сжатие без потерь невозможно.

Ваш метод, основанный на "словаре 4 уровня", предполагает, что можно достичь бесконечного сжатия за счет рекурсии. Однако рекурсивное сжатие не может преодолеть энтропийный предел. Каждый уровень сжатия будет добавлять свои накладные расходы (например, метаданные, необходимые для восстановления данных), что в конечном итоге ограничивает эффективность сжатия.

2. Практические ограничения
34 ГБ словарь: Хотя вы утверждаете, что 34 ГБ достаточно для описания "бесконечной рекурсии", на практике это не так. Словарь такого размера может быть полезен для сжатия данных, но он не может охватить все возможные комбинации данных, особенно если данные имеют высокую энтропию.

Скорость работы: Если ваш алгоритм работает медленно, это может быть связано с тем, что он требует значительных вычислительных ресурсов для обработки рекурсивных структур. Переписывание на C++ или CUDA может ускорить выполнение, но не устранит фундаментальные ограничения алгоритма.

Использование SSD вместо RAM: Это возможно, но приведет к значительному замедлению работы программы, так как доступ к SSD намного медленнее, чем к оперативной памяти.

3. Рекурсивное сжатие
Идея рекурсивного сжатия (сжатие уже сжатых данных) интересна, но на практике она имеет ограниченную эффективность. После первого этапа сжатия данные обычно становятся ближе к своему энтропийному пределу, и дальнейшее сжатие либо невозможно, либо дает минимальный выигрыш.

4. Магия сжатия в ZIP/RAR
Если сжатый файл занимает меньше места в ZIP или RAR, это может быть связано с тем, что эти алгоритмы используют свои собственные методы сжатия, которые могут быть более эффективными для определенных типов данных. Однако это не означает, что ваш метод обеспечивает "вечное сжатие". Это просто демонстрирует, что разные алгоритмы сжатия могут давать разные результаты.

5. AGI и сингулярность
Утверждение, что ваш метод может привести к созданию искусственного общего интеллекта (AGI) или сингулярности, является спорным. AGI требует не только огромных вычислительных мощностей, но и сложных алгоритмов обучения, понимания контекста и адаптации к новым задачам. Сжатие данных, даже если оно эффективно, не решает этих проблем.

Что можно сделать:
Оптимизация кода: Переписать код на C++ или CUDA для повышения производительности. Однако учтите, что это не решит фундаментальных ограничений алгоритма.

Использование внешней памяти: Реализовать механизм работы с SSD, чтобы уменьшить нагрузку на оперативную память. Это может быть полезно для работы с большими объемами данных.

Тестирование и анализ: Провести тщательное тестирование алгоритма на различных типах данных, чтобы понять его реальную эффективность и ограничения.

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

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

Если у вас есть конкретные вопросы по реализации или теории, я готов помочь!

>>316655528
>размер его ссылки достигнет размера слова на которая она ссылается.

Вот, сжатый файл, не меняется в размере, но если добавишь его потом в сжатую папку или вин рар или 7zip то будет в 10 раз меньше

пример словарь 1
А = 111000
словарь 2
А=1111000

бинарный код один и тот же, но метка словарей разная. также и тут существует 4 миллиарда древ всевозможных комбинаций. а разными словарями

те 4 миллиарда разных меток. которые кодируются бинарно 32 бита в 128 бит.

>>316643851 (OP)
C/C++ дев с 6 годами опыта ттт. Так уж и быть после работы посмотрю что ты там придумал, но ничего не обещаю.

>>316655842
Текст и код ОПа уже разобрала нейронка, так что можешь не париться

>>316654983
ОПче, не заводись. Там же буквально нехер осваивать чтобы скомпилировать. Ты хочешь лениво не разбираясь собирать проги. Попроси нейросетку научить. Кидай ей ошибки. Зачем тебе готовый бинарник? Компиль прямо на машине, тем более кода немного будет.

Че за хуйню перегруженную вы навыдумывали? Учитесь, чурки тупые. Храню свой бекап с рарными пикчами в zip архиве в числе пи начиная с 246 523 886 149 знака, кому охота, скачайте, пароля на нём нет. На всякий на всякий случай обозначу, что переводить всё в шестнадцатеричную систему, конец заканчивается последовательностью "54681216814323464314358468412" в десятеричной.

>>316655914
Там и нейронка не нужна, любой первокур айтишной специальности без проблем поймёт, почему идеи ОПа неосуществимы. Даже код смотреть необязательно, по описанию всё ясно.

>>316655693
всю информатику основали эти 2 чела, без них у тебя не было бы пеки.

они прошивали спектрумы, делали копии компьютеров IBM в 50 раз ДЕШЕВЛЕ разбирая печатные машины то что стоило 40к $ они за 1к$ делали

Понятия персональных компьютеров не было, компьбютеры были ток у корпораций и институтов,

тут мы подошли к черте, когда вся информатика, становится квантовой те , с помощью кода выше ты можешь хранить зетабайты в 1мб рекурсивно с помощью словаря на 60 гигов. и рекурсивно ускорять ИИ и вычисления и память

записи с камер можно хранить в 16 к битрейтом 500мб в сек. ВЕЧНО

Задай себе воппрос как была запрогана первая цифровая клава? если все носились с набивом перфокарт

>>316655954
>ОПче, не заводись. Там же буквально нехер осваивать чтобы скомпилировать.
ЗЛИБ И графическая оболочка требует зависимостей которых нет в 40 гб ИДЕ визуал студио.

Я из треда вынес следующую хуйню.
ОП мирный полезный шиз. Но именно такой, что находится в пределах нормы и гения, а не чисто негативка.
Если бы он получил хорошее образование, он бы нашел свое место в жизни создав какую-нибудь интересную хуйню.
Сейчас он упирается в недостаток своего образования, не может использовать накопленное знание другими и наступает на грабли. Обидная хуйня.

>>316648298
>4
Бля это чё за магия, была 1 фотка собаки, а стало 4 точно таких же!

>>316656122
Ну я над этим покекал конечно. Не знаю кто использует полноценную вижуал, кроме надрочившихся программистов. Я предпочитаю делать все на минималках, ставить конкретные вещи если они нужны. На твоем месте просто бы попросил какую-нибудь нейросеть объяснить как тебе собрать программу под твою винду, что и как поставить. А вижуалстудио нахуй на помойку бы выбросил - только лишнее место занимает.

>>316655829
Эта нейронка права

https://codepen.io/procoders000001/pen/qEWLeaV

>>316655839
неважно насколько словарей ты разобьешь, на 2 или 4 миллиарда но тебе придется так или иначе ссылаться на все значения 64 битного слова.

твоя конечна ссылка всеравно будет занимать 64 бита. например 32 бита из нее будет занимать адрес самого словаря, и еще 32 бита поиск значения в этом словаре чтобы покрыть все значения.

а иначе будет потеря данных

еще раз, у тебя файл который ты кидаешь содержит упорядоченные битовые ссылки типа 1.2.3.4.5...n это лучшие условия для арфиватора
а все данные исходного файла просто вынесены в исходный файл.

>>316656132
Гении получаются, когда знаний много, а шизы мало, она под контролем и не прогрессирует. ОП же, к сожалению, ошизел конкретно и серьёзно, имея при этом крайне скудные познания в базовой части относительно теории информации. Шизы практически не поддаются обучению, вот он и застрял на своей сверхценной, но изначально неправильной идее.

>>316655829
https://replit.com

Функция AUTOMATIC DEVELOPER

попроси провести тест кода питона на место и пары. он проведёт на сожрёт токены на 4 $ и место на 60 гигов.

Функция AUTOMATIC DEVELOPER это чат бот полный дебагер, те лучше чат гопоты в 50 раз

>>316656515
>>316656515
>>316656515
>на все значения 64 битного слова.

эти слова могут быть одинакоымми под разными алфавитами.

Это значит что имея триллион алфавитов я могу файл запрогать как бесконечное 11111111111111 но логика сборки будет словарь где это запрогано точнее порядок.

у меня в 60 гигах запроган порядок для всей всей информатики. и так получилось что 32 бит ссылка даёт 128 бит. Как? читай и изучай код. магия.

>>316656742
ну нет я почитал твой тред. ты просто формулой разворачиваешь 1 допустим в последовательность 1.2.3..8

но эта формула будет работать только на этой последовательности.

если ты захочешь закодировать допустим 9.8.7..1
тебе потребуется уже другая формула. и так для каждого значения.

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

>>316657156
вот, там древа всех значений. в базе данных 60 гб в сыром виде юникода 144 гб но можно сделать алгоритм без словарей

Можно не хранить все карты, если знать широту и долготу и азимут. можно летать без карт. куда хочешь

>>316654699
>Чел, я с юристами бегала
>бегала
У НЕЁ СИСИК И ПИСИК СЖАТЫЙ ПИСИК

>>316657156
вся вселенная работает на принципах чётных и нечётных степеней
2) сбрутить все синусы можно будет также 60 гб всех вариантов
- эти синусы можно применить к бинарному коду

>>316657318

чтобы записать все вариации значений слова в 64бита тебе потребуется сторедж в 2⁶⁴⁺¹ бит информации.
посчитаешь столько это?

>>316648209
>Показывай учёную степень в области ДНК. Иначе в твой бред никто верить не будет

Я скажу больше. вот что. почему вакцину можно сделать только из нулевого пациента? -

В лесу 1000 деревьев на каждом дереве 100 веток на каждой ветке 50 листьев или же 50 дубликатов листье, веток и деревьев

Или же 1 настоящее дерево, а все остальные дубликаты это ссылки на это дерево откуда и берут команды днк, ведь иначе не было бы леса, или же дерево было бы одно.

также и тут, все днк в россии это ссылка на днк медвепута также как и в сша ссылки на днк байдена и трампа, они использовали технологии и создали клонов по этой технологии.
Отсюда и терпильство.

>>316657619

Это записано в 4 уровневом словаре где пары кодируют пары

простой пример 01 - это 1 а 10 это 2

12 это 1
а 21 это 2

Ресурсия. началась.

>>316657417
какие ты там синусы собрался срезать?

для того чтобы закодировать большое число тебе понадобятся меньшие числа, но занимающие такое же количество информации в сумме что и большое.

>>316657808
а 00 и 11 куда делись? съелись? как мы их будем записывать? 3 и 4 лол? нашлась пропадающая при рекурсии информация получается?

>>316649995
бляяять так вот откуда у нормипидоров этот уёбищный юмор в стиле теории большого взрыва, из пендостанского брейнрота.

>>316657836
кодируются не числа, а пары чисел. метками. потом пары метки кодируются метками и так до 4 уровня. в итоге файл это ссылка на метки 4 уровня. все варианты меток 60 гб

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

по типу не нужно хранить терабайты карт, если есть азимут и широта.

>>316657836
ты не понимаешь тогда логику много многоуровневого словаря.

Представь.... базу данных где индексы индексируют индексы, когда наступает рекурсия? скажем для всех вариантов пар АБ? при условии что все пары кодируются 1 символом но разным алфавитом?

>>316658018
>а 00 и 11 куда делись?
Они все из разных алфавитов. алфавитов можно напридумывать бессконечное количество как и цифр, и знаков но у них у всех один паттерн.

>>316657836
В движке хитман 1 модель но 400 ссылок, в итоге толпа не жрёт ресурсов. также рекурсия бинарноного кода визуально это 2 пикрол

>>316658326

ну так чтобы разбить двухбитное число тебе надо четыре метки. что
простым пересчетом что в дереве.
на эти четыре метки надо сослаться что по азимуту и широте что простой ссылкой. в дереве широта и долгота будет также кодироваться. в нашем случае одним однобитным числом за номер строки и одним двубитным числом за ветвь. получается 2битное число мы с помощью дерева закодировали 3хбитным.

один лишний бит получается накладные расходы за реализацию слоев.

чем сложнее будет дерево теи больше информации потребуется передавать чтобы гулять по его ветвям

>>316650281
>>316648961
не ответил = слитый оп питух

>>316658501
ты не учитываешь у тебя объем ссылки = заказодированной информации.
ты просто не хожешь через словарь сжимать. хоть сколько гоняй эту рекурсию.

>>316658694
Ты опять ничего не понял у 4 бит - 16 комбинаций.

сбруть их и сделай новый словарь что бы постоянно был один и тот же бин код, но словарь разный. Не могешь придумать? -

Окей простые примеры. ЛУК. И ЛУК?
ЗАМОК и ЗАМОК? КОТ, КИТ?

Как ты понял, от расположения, меняется смысл Возможно квантовый словарь всего так и работает. Ты то прогу тестировал или нет? -

>>316646086
>законы роскомнадзора

>>316648961
>что каждое фото сожмется до невероятного 1 бита,

В информатике всё пишется в кластерах по 5 кб. меньше нельзя.

Метод на самом деле, логичный, в книгах есть страницы, есть справочники где есть все книги, есть справочники по библиотекам где эти книги находятся

оп предлагает метод генерации всех этих справочников и библиотек точнее вавилонская библиотека для бинарного кода.

>В информатике всё пишется в кластерах по 5 кб. меньше нельзя.
следовательно вся информатика ужимается в кластер уникальных 5кб.

>>316658757
так цепочка ссылок, и сама ссылка и есть тело конечного файла )

А можно по русски? Как эта хрень работает? Ниче не понял

ВНИМАНИЕ ЛОР БЕСКОНЕЧНОГО СЖАТИЯ
ЕСЛИ ВЫ В ПЕРВЫЙ РАЗ ТУТ ПРОЧИТАЙТЕ
Иеди ОПа, изложенные простым языком:
1) ОП предлагает сжимать информацию методом словаря (самый примитивный метод сжатия)
2) ОП предлагает вычислять функции не алгоритмически, а с помощью поиска готового ответа в таблице по индексу.
3) Таблицы значений функции так же сжаты по словарю
4) Сами словари так же сжаты по словарю
5) Функция разжатия словаря выполняется мнгновенно, тк она не вычисляется, а берёт значение из готовой таблицы
6) Таким образом разжатие данных любых размеров выполняется мнгновенно и благодаря этому так же возможны любые вычисления мнгновенно

Проблемы метода, которые ОП не понимает:
1) Лимит Шенона - если повторно кодировать словарь по словарю, то в какой-то момент размер данных станет равен размеру словаря и не меньше.
2) Когда данные восстанавливаются из хэша с помощью функции (табличной), то структура данных сохранена в структуре функции. Соответственно никакой экономии не происходит

Интересная тема, о которой стоит задуматься, которая раньше интересовала ОПа, но он от неё отказался в силу тупости:
1) Регенеративное сжатие, где относительно простая алгоритмическая функция из небольшого сида может сгенерировать огромный набор данных. Размер функции и сида в сумме на порядки меньше, чем размер данных.
2) Проблема в том, что поиск регенеративной функции НП-хард задача.
3) Может быть можно решать эту задачу с ИИ в приближении как поступили с протеинами.
>>316643851 (OP)
я тебя просил же так часто не постить

>>316659264
Ты забыл написать что оп говорит о себе в женском роде и шитпостит своей хуйней больше года

>>316643851 (OP)
>>316648332
Их УЖЕ ВЫЧИСЛИЛИ недавно, произошел ПРОРЫВ, я не пизжу. По идее в ближайшие лет 10 должны нахуярить чудо лекарств ебовых.

>>316659264
>1) Регенеративное сжатие, где относительно простая алгоритмическая функция из небольшого сида может сгенерировать огромный набор данных. Размер функции и сида в сумме на порядки меньше, чем размер данных.

окей вот это имеет смысл, возможно тут и "квантовые " алгоритмы применимы

>>316650301
Блядб брат если ты понимаешь чето в основах информатики в самой блядь базе ты внатуре за секунду врубаешься что ОП изобретает вечный двигатель и пососёт хуёв. Это блядь как дважды два очевидно.

>>316650452
У него там должна быть функция специальная которая правильно разжимает, а функцию он тоже сожмёт, пониматься надо.

>>316656245
И че ты потом делаешь с освободившимся местом?

>>316643851 (OP)
Нихуя не пойму в чем алгоритм заключается, ТЗ говно, тут то и человек с таким описанием не напишет, не то что ИИ

>>316659428
Я не думаю что тут причём то квантовые алгоритмы, я в этом нихуя не шарю. Эта задача называется формально Smallest Context Free Grammar и доказали что она NP-hard, то есть практическим образом не решаема.
https://en.wikipedia.org/wiki/Smallest_grammar_problem
Может если ты будешь искать не smallest а в какой-то границе, то можно решить с помощью ИИ достаточно хорошо.
В принципе ты врятли сможешь как зип использовать этот алгоритм, он будет ОЧЕНЬ медленный в запаковке и медленный в распаковке, итеративная генерация данных будет до жопы времени занимать, особенно если они в память не влезают. НО эта тема может быть очень рабочей для архивации, если сделать готовое решение, то все, кто хранит большие архивы данных, купят лицензию за до жопы денег.
Блядь нахуй я вам рассказываю лучше бы стартап сделал хахаха. Я больше не буду про это пиздеть, это идея на миллион внатуре.

>>316659264

Это не сжатие. Это востановление по шаблонам но шаблоны кодируются шаблонам из 256 алфавитов ( знаков юникода)

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

метод генерирует и книгу и страницы со всеми вариантами.

>Проблема в том, что поиск регенеративной функции НП-хард задача.
эта проблема мною решена, пеки смогут ускорять рекурсивно свои вычисления и память.

Сетевая карта может умножать файлы, на сами себя, мой метод 60 гб словарей может делить файлы бесконечно.

простой пример . словарь 1
1=100 ( сжатие в 100 раз )

словарь 2
1 = 1000 сжатие в 1000 раз 1000=1 разжатие в 1000 раз

почему это не изучалось? а потому что алгоритмы компресисии сформировались и закончились в 90 годах, там было всего 100мб 4гб памяти. словарей не создашь .почему вин рар и 7 зип не сделают 4 уровневые словари где пары кодируются парами в рекурсии? ах нет. не разрешают.

Задаём вопросы.

>>316659470
> Это блядь как дважды два очевидно.

имея ссылку на файл ты можешь скопировать файл с сервера.
Экономия в миллионы раз если файл будет скопирован миллион раз

таким же образом файл можно обратно делить сам на себя с помощью словаря из 60 гигов.

Уровень 0: 16 пар 8 байт/пара = 128 байт

Уровень 1: 256 пар 8 байт/пара = 2 КБ

Уровень 2: 65 536 пар 8 байт/пара = 512 КБ

Уровень 3: 4 294 967 296 пар 8 байт/пара = ~ 34 ГБ

>>316659709

>>316659763
нейросеть это поидее и есть такой алгоритм, по сиду приближенно восстанавливает информацию.

вот только я боюсь чем точнее нужно будет восстановить тем больше будет сид и стремиться к размеру конечного объекта.
не ссы че думаешь только на дваче о передовых алгаритмах сжатия информации думают ахаха.

>>316659996
Нейросеть это не то же самое вообще. Я тебе говорю про детерминированный алгоритм, который 100% точную копию разворачивает. Посмотри что такое Context Free Grammar, ты поймёшь суть алгоритма. Для него просто найти параметры вычислительно очень сложно.

>>316659864
>Уровень 3: 4 294 967 296 пар 8 байт/пара = ~ 34 ГБ
Короче, то, что ты 100 раз одно и то же повторил нихуя не делает это правдой.
У тебя 2^32 последовательностей длиной 8 бит. Знаешь сколько таких последовательностей всего может быть разных? 2^64 блядь. Что равно 18,446,744,073,709,551,616
То есть как только ты встречаешь ЛЮБУЮ одну из 18,446,744,069,414,584,320 последовательностей ты уже не можешь её своим словарём закодировать, долбоёб. А ты её встретишь, потому что ты записал в свой словарь только 1/4,294,967,296 возможных пар блядь.
Всё, оватливай нахуй.

>>316643851 (OP)
Попробуй сжать что то большее чем 100гб оборёшься.

>>316660093
>>316659763

конкретно тут метод квантового словаря на 60 гигов так как сбручены все пары для пар комбинаций для пар комбинаций, да можно найти алгоритм который без словаря, но смысл?

С помощью само кодирования эти 60 гигов всю информатику в рекурсии разгонят, память зетабайты, триллионы флопсов, и всё по словарю в кристале те в триллионы раз быстрее текущих H100,

запомните, 1 мб можно будет развернуть в 10000 терабайт за 1 сек. и это не шутки достаточно лишь переписать код выше на CUDA

да в 2025 учёные не могут умножать и делить бинарный код.

Мною же метод этот реализован, но с помощью словарей на 60 гб

>>316660253
эти пары 32 бита кодируют древо обратно в 128 бит. дупло.

32 бита дубликаты из разных алфавитов, это не один и тот же бинарный код

Алфавит 1

А - 111000

Алфавит 2

А - 111000

ток, в алгоритме алфавит это новая, строка, ( не её порядковый номер) А чем маркируется пустота?подумай.

>>316660253
у 4 бит 16 комбинаций. у 16 комбинаций 256 комбинаций у 256 комбинаций 65к комбинаций у 65к комбинаций 4лярда комбинаций

следовательно генерирует 4 миллиарда знаков, из разных алфавитов

получаем файл 1111111111111111111111111 но логика его построения будут разные алфавиты, те правило замещения генерации хеша. детерминированного

по типу 001 -002 но для 4 миллиадов алфавитов

>>316660253
давай пойдём по другому. это движок хитман и дид ризинг занимает 32 мб рамы консоли PS2
сама модель занимает 200кб. по карте гуляют 400 ботов. Вопрос. КАК? есть только один метод как это сделать. что бы 400 ботов не занимали в 400 раз больше памяти. те это ссылки. но как физический движок это учёл? давай. догадывайся.

>>316660702
ты не учитываешь что больванчики в хитмене не уникальные . это КОПИИ, заранее определенные копии. захочешь другой тип перса, тебе нужно записать в словарь еще одного.

>>316660905
вот, разрабы сделали невозможное они 800 ботов запекли как поведение 1 бота. в толпе с физикой в итоге движок помнит все 20 видов и не тратит 400 раз лишних действий

в мирорс эдж 1 2008 запекли тени и текстуры в итоге у тебя фото реал графика уровня 4090 в 4к которая идёт на GT9800 - 512 мб

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

Бля, интересная идея, конечно

Если правильно понял принцип, у ОПа словарь со всеми комбинациями из двух битов которые мапятся в в буквы (ascii символ 1 байт или 8 бит)
То есть при первом переборе файла побитово у нас каждые 2 бита привратятся в 8, т.е. файл увеличится в 4 раза
Но у ОПа есть еще ожин словарь где каждая комбинация двух символов мапится в 1 символ
Т.е. рекурсивно сжимая один и тот же файл он по идее будет сжматься в два раза
Ссылки на словарь ему хранить не нужно потому что каждый байь файла и есть ссылка на словарь

В словаре комбинаций битовых пар будет всего 4 значения 00=а 01=b 10=c 11=d
Сколько будет вариаций в соваре пар буков мне лень считать, но количство больше 4(aa = a, ab=b, ac=c, ad=d, ba=e ...), то есть это второй словарь
В третьем прогоне у опа будет еще один словарь со всеми вариациями букв из предыдущего
И потом еще раз с уже охуевшим 60 гиговым словарем с вариациями букв из предыдущего
Потом ОП хочет засунуть плучившийся текст в 7zip, лол, а потом опять превратить байты в буковы

В первом шаге файл вырастает в 4 раза, в следущих трех уменьшается в 2 раза, то есть после каждой итерации мы получим исходный файл сжатый в два раза

Но 7zip хорршо сжимает текстовые файлы где есть человеческие слова и похо сжимает файлы где символы редко повторяются, что и нагенерит скрипт опа
Так что уже после первого прогона алгоритма (который будет пидорасить файл газиллион лет) мы получим файл сжатый в два раза
А потгм бужем бесконечно тратить мамкино электричество

>>316646374
неудобный пост. скипаем

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

>>316646374
>Restrictions: Must run in ≲50 hours using a single CPU core and <10GB RAM and <100GB HDD on our test machine.
У опа по всем параметрам не проходит.

>>316661296
>мирорс эдж
Ты просто даун, у которого яркость освещения ассоциируется с качеством графики. Помню, когда только вышла gta-5, то там тоже были такие графические моды, которые тупа делали солнце ярче, но при этом они позиционировались как улучшающие графики и не понижающие производительность. И такие же дауны их скачивали и облизывались ДООО ВОТ ЭТО ГРОФОНИЙ СТАЛ ПАЧИМУ РОКСТАР ТАК НЕ МОГЛИ СДЕЛОТЬ.

>>316659864
Хаааа я понял, ты просто перепутал байт и бит, короче.
Получается у тебя на уровень ноль ты кодируешь 8 бит информации с помощью восьми бит информации в словаре. Гениально.
Блядь я щас реально завизжал потому что я понял, что на уровне 4 у тебя словарь это просто все 32 бит числа. И ты короче кодируешь точно так же с помощью 8 бит индекса 8 бит. Это ёбнуться можно, типа коэффициент сжатия у тебя получает ОДИН.
Ааааааа хахахха.

>>316661335
>Так что уже после первого прогона алгоритма

CPU И RAM также можно разложить на 60 гигов и получить бесконечную рекурсию.

ты просто не можешь регистр блоками кодировать. 32 бита в 128 бит

>>316661699
вечная рекурсия, информатики

>>316661699
Неясно почему перельман молчит, или не догадался до этого

>>316661943
Сколько бит в байте скажи быстро.

Пидоры, че вы там вечно сжимаете, ебучие шакалы бля?

>>316661699
суть в том, что я должна была работать в Nvidia за 400к$ месяц год, но их Эйчар хотел на собезе спиздить метод и код, мой юрист и математик это просёк и послал их куда подальше, осознав что метод и код нельзя сохранить - решено сделать опен сорс. радикальными методами. Месяц назад инвидия сделали метод блочного кодирования текстур снизив затраты памяти в 3 раза.

но... мой метод позволяет рекурсивно сжимать1 гб в 1 мб имея на ssd словари на 60 гигов.

фильмы и игры можно со 100 гигов ужать в 1 мб. и сжатие распаковка будет 10 гб сек

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

так что знайте айчары пиздят ваши методы и коды на собезах

>>316662123
Два. Или 1 или 0.

>>316662123
Запрогать можно как хочешь. не ток 8

>>316662278
Хуйня твоей метод, потому что уже давно есть архиватор Бабушкина, который сжимает терабайт до килобайта.

>>316661792
даю инсайд и нобелевку.

Полносвязанный граф маркова после 60 гб, повторяет себя, те идёт рекурсия, и этих графов можно бесконечное количество плодить

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

>>316662278
Так ты ещё в израиле живешь, чтоли?
Как тебе хезболы приколы?

>>316643851 (OP)
Давай на простом примере покажи. У нас есть два файла. Информация в первом: 1
Информация во втором: 1 000 000 000

По твоим словам размер файла уменьшится в 10 раз. 1 это минимальное значение (бит), а второе число это 10 бит, в десять раз больше. А ты говоришь что можешь дать словарик и ключ, который будет весить в 10 раз меньше чем файл. Давай свой словарь, неважно какого он размера, и покажи какой ключ ты к нему дашь, чтобы вес ключа был меньше веса второго числа.

>>316643851 (OP)
Скинь почту, есть деловое предложение. Не фокусник.

>>316662825
[email protected]

>>316643851 (OP)
Хуйня. Таким же методом можно сжать файл до одного бита, просто нужен ещё один словарь в котором содержится этот файл и фото пизды твоей мамки.

>>316657748
>также и тут, все днк в россии это ссылка на днк медвепута также как и в сша ссылки на днк байдена и трампа, они использовали технологии и создали клонов по этой технологии.
Нихуя себе.

>>316662985
По задумке ОП-а словарь на 32гб описывает все возможные двоичные последовательности. Например строка 14, строка 576, строка 167236 итд. И любой файл можно записать как последовательность этих строк из словаря. Но ОП не понял, что в такой системе ключ к строке будет весить столько же, сколько сама строка.

>>316662192
Рот прикрой, а то иички тебе сожму до молекулы.

>>316661792
>>316661792
Посчитал
1 прогон битовые пары в байт = словарь 4 индекса
2 прогон пары байтов в байт = словарь 16 индексов
3 прогон пары байтов в байт еще раз = словарь 256 индексов
4 прогон пары байтов в байт чтоб ополовинить файл = словарь 65,536 индексов или ровно два байта
Тоесть надо в файле подменять каждые два байта на другие два байта
Или я не понял что там за словарь такой в котором в один байт влазит больше 256 значений
Или если ты не на байты будешь биты подменять то я хз у чего может быть 8 значений и чтоб оно было меньше двух битов

>>316663289
Она ещё думает что следующий уровень "словаря" это 60 гигабайт (34*2), хотя размер растёт экспоненциально и размер будет 2048 петабайт лол. Поэтому мы так скромненько остановились на 4 уровне и пока больше не сжимаем.

Сегодня у чатботов будет тяжелая ночь.

>>316663289
>Или я не понял что там за словарь такой в котором в один байт влазит больше 256 значений
Ну там в хитмане н-писи видел? А в лесу деревья? В один лес влазит больше одного дерева, понимаешь...

Хуйня, я могу сжать файл 1.11 ГБ до 61 килобайта! Стандартными средствами Шиндошс. Распаковка и сжатие за пару секунд на среднем процессоре (5700x). Кто не верит - ставьте анус в треде, покажу как это делается.

>>316643851 (OP)
ОП, идея интересная, но глобально твоя проблема в том что сами ссылки на словарь будут слишком длинными, и фактически не дадут сжатия. Нужно размышлять другую сторону, вместо ключ-значение попробуй использовать вектор внутри матрицы размера n на n - так сможешь вместить больше комбинаций. Думой.

Че, нет желающих анус свой проебать? Жаль...

>>316663973
И да, все ещё жду почту с галкой опа.

Эх как же жаль, что нельзя закодировать X уникальных значений, используя меньше, чем Х уникальных кодов
https://en.wikipedia.org/wiki/Pigeonhole_principle

Какая же пидорская наука математика, отнимает нобелевку.

>>316663987
[email protected]

>>316664190
А где галка?

>>316664076
Можно, если кодировать не в таблицу, а в вектор на матрице.

Ниче, пацаны, мне голоса сказали что скоро Аннунаки десятичную систему кодирования завезут, в один бит можно будет от 0 до 9 значения записывать, квантовые технологии! Вот тогда заживем. Властелин Колец театральная версия в 4к будет мегабайт весить, а на рыксах 580 можно будет протеины для вечной капсулы считать...

Что это, архиватор Бабушкина? Мне вернули мой 2007? Я сплю?

>>316647256


>спрошу у нейросетки бред у тебя или нет

А своей головы у тебя нет, таракан ебаный?

>>316663645
Чет не врубаюсь 16 пар чего?
Битов? Байтов?

>>316663789
>>316664396

Примеры сжатия будут?

>>316664437
16 пар днк.

>>316664443>>316664439

Анус ставишь что не смогу сжать "файл 1.11 ГБ до 61 килобайта! Стандартными средствами Шиндошс. Распаковка и сжатие за пару секунд на среднем процессоре (5700x)"? Тольк опо-честному, если проигрываешь - фото ануса с супом в тред кидаешь.

>>316664508
Ну так скидывай пример.

>>316664565
Нет, сначала анус ставь. Если поставишь - могу даже на твоем компе сжать, скажу какой алгоритм.

>>316664508
>файл 1.11 ГБ
В котором пара сплошных рядов единиц и нулей?

>>316647681
Сука, умри.

>>316664437
Байт это два значения ноль или один уже сказали же.
Значит два байта это 4 значения.

>>316663645
Ну хз, слишком тупой и ленивый чтоб читать про многоуровневые словари куда помещается все включая дерево на котором сидит хитман с н-полной писькой в руке
Может потом почитаю
Но удачи че, я кайфану если взлетит и двачеру дадут нобелевку

>>316647681
>телефоны будут в 50 тысяч раз быстрее

>>316647962
Сукп, чтоб тебе большой энциклопедический словарь в жопу сунули, все тома разом. И желательно плашмя.

>>316664652
Да уже выяснили, что всё её сжатие заключается в том, что она перепутала бит с байтом.

>>316647962
Чтоб тебя вареным говном из кетайской канализации накормили.

>>316662751
минимальный размер кластера во всех системах это 5кб те 5 тысяч знаков.

но если ты хочешь игратся не с блоками а единицами то вот тебе пример степеней обратимых

>>316648083
Нарыгал тебе за шиворот, пидарас.

>>316663080
>Нихуя себе.
как была запрогана первая цифровая клавиатура и драйвер для неё если клавиатур не было? сидят значит деды такие, схемку пайку делают, да перфо карты набивают, драйвер для цифровой мышки и клавы мутят.

>>316648298
Чтоб ты своим словарем подавился, мразь. Чтоб тебе им по ебалу наебошили, гнида.

>>316664962
Причем тут ДНК и клавиатура, шиз? Нахуй ты с темы на тему прыгаешь?

>минимальный размер кластера во всех системах это 5кб

>>316663645
>В один лес влазит больше одного дерева, понимаешь...

всё человечество это дубликат двух обезьян, ну или адама и евы.
мы все дубликаты наших предков

ведь не даром в майнкрафте было сказано, ничто не истино, всё дозволенпхо

>>316665055
Её когда к стенке припирают она всегда так делают.
Щас ещё туману напустит скажет типа "не все секреты простым смертным рассказывают............. . ... .... . .. ." (секреты уровня сколько бит в байте)

>>316648475
Сука, аминазин в палату, быстро. Мы его теряем...

>>316664508
Щя я 100тб на изи запакую ток это спарс файл кек

>>316663973

>>316664565
>>316664626
>>316664890
https://transfiles.ru/voymb
Держите, пацаны. 11 гигов в 610 килобайт влезло.

>>316665100
Шиз с 9 классами образования не слышал про мутации.

>>316665199
Ну давай, запакуй, пиздобол ебаный.

>>316665100
>не даром в майнкрафте было сказано

>>316643851 (OP)
А чего рабочий стол пустой? Это точно твой компьютер?

>>316649181
Сожми мне войну и мир с помощью словаря русского языка. Позязя.

>>316665364
Так она сжала все ярлыки.

>>316649387
>Было бы тут даже 10 таких постеров

То мы бы поняли что в дурку анторнет провели.

>>316643851 (OP)
Опять шизло на связь выходит.

У меня был друг, Дима, такой же шиз как ОП, тоже с двача (двач умер блять) осенью ркн-совершил нахуй, печально. Это хорошие ребята, но им нихуя не объяснишь, это как вера, фанатизм такой у них в голове.

>>316665440
Хуй знает че хуже - ОП, который явно душевнобольной или блядь просто типичные мочехлёбные кретины с 1 извилиной, которые нихуя ни в чём не понимают и такие ООО ДА ЧЕТО В ЭТОМ ЕСТЬ ТАК УМНО И ЗАГАДОЧНО ЗВУЧИТ.
Пиздец просто.

>>316649748
Она только с антивирусом Дедушкина, епт.

>>316665475
Я очень надеюсь, что ОПу не надоест и что ей родители не выпишут таблетки, потому что меня изрядно развлекает.

>>316665420
Сжал войну и мир с помощью азбуки.
|треад.
могу сжать всю музыку мира до семи нот, кста. Ннада?

>>316649852
Не говори.

Насекомые, сами жодуматься не могут где их ебут.

Тупое жвачное дебильное стадо.

>>316665200
Я нихуя не понял, что происходит на видео. Исходный файл получает другой формат такого же размера, зачем-то создается архив с сконвертированным файлом, а потом исходный файл конвертируется обратно в старый формат? В чем смысл этих действий?

>>316665420
С помощью словаря русского языка не выйдет. Догадаешься сам почему?

>>316665678
Код писала нейронка, которая заменит программистов, по запросу шизофреника. Вопросы?

>>316665714
А где обещанное вечное сжатие-то? Где вообще какое-то иное сжатие, кроме через старый добрый винрар? Что за наебка?

>>316665842
Ишь че захотел, может тебе сразу нобелевку принести?
Думаешь большие фирмы хотят для тебя свои секреты раскрывать?

>>316665842
Брат, вот где сжатие -->>316665270

>>316665678
>Исходный файл получает другой формат такого же размера,

Если поместить его в рар или зип он будет в 10 раз меньше

Архив можно сжимать по новой.

Прикол в том, что бы скомпилировать в C++ в ИДЕ визуал студио на 30 гигов нету зависимостей от злиб, 7зип и вин рара. поэтому рекурсию не прикрутить

>>316657417
Сука ебало тебе долотом сбрутил

>>316666021
Готов купить твою разработку, давай свой тг

Вот вы на ОПа гоните, а ответьте, почему Слоота УБИЛИ за день до сделки по продаже его кодирующей системы? И не пиздите, что сам умер, прям за день до сделки, ага-ага.

>>316666021
Так чучело на ОПе и не сжимает архив, оно зачем-то два не связанных процесса делает. Один конвертирует файл в другой формат, создает при этом файл в 6-7 раз больше, и разконвертирует обратно. Другой процесс это тупо сжатие винраром. Что это за демонстрация уровня /b/ сейчас была?

>>316662373
А Дедушкина есть?

Что такое сжатие то, объясните?

Так, а ответьте ка мне серьёзно уже кто-нибудь. Почему энтропия данных высчитывается только по частоте символов, а не, например, ещё и по их расположению относительно друг друга, по крайней мере для некоторых данных типа картинок и т. п.? А то если считать по определению Шеннона, то белый шум из 12-битных цветов будет менее энтропичным, чем вменяемая картинка из 24-битных цветов (я именно на таком примере проверял сам). Мне кажется просто, что что-то с определением энтропии Шеннона не так, не особо универсально оно.

>>316663973
Блять, еще один дурачок попался...

>>316666158
понял, что пустышку с потенциалом у него не купят, что на демонстрации его ожидает ужасный позор и замутил мистификацию, чтобы запомниться непризнанным гением
/тхреад

>>316665707
Да

>>316665512
Меня больше забавляют хуесосы, которые бегут к нейросетке с вопросом почему дважды два равно пять это наебка.

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

>>316666382
Терпи

>>316665914
Сжатие хуя плоскогубцами

Второй обзор. Задаём вопросы

1) словарь не будет больше 60 гб. словарь универсальный на все комбинаии и на всегда
2) текущая производительность 100кб сек.
3) сжимать файлы можно рекурсивно до 600 байт

>>316666021
Прикол в том что аминазин по тебе плачет

>>316666790
>Второй обзор
Поясни за первый, что за хуйня у тебя там происходит?

>>316666790
ОП, сожми вот этот файл и сделай видео:
https://limewire.com/?referrer=48k1433kko

>>316666779
Защеку тебе.

>>316666847
Моя щека - это твоя щека, мы оба анонимы

>>316666790
Да ты хуйню показываешь, нет смысла сжимать такое мелкое говно по пять мегабай. Сожми фильм на 20-30 гигов, покажи какой будет конечный размер, сколько времени займет сжатие, сколько времени займет распаковка, может он и нахуй не нужен твой архиватор ебаный, может он сжимать-разжимать шесть часов будет, я скачаю оригинальный файл быстрее.

>>316665199
Пидор, где твой файл на 100 тб, защекан пиздливый?

Разве сжатие байтов в биты это не про общую алгебру?

>>316666924
И сжаты мы по одному словарю... словарю Ожегова блеать...

>>316666385
>понял, что пустышку с потенциалом у него не купят, что на демонстрации

Я, как тян, математически при их и своих юристах и их кодерах доказала, и показала мат формулу они нарушили договор, они не выполнили требование и не дали 400к$ - нвидия кидалы. они хотели меня кинуть ещё раз, что бы показала программу. рабочую эту.

Метод слишком простой, что бы все поняли, но слишком опасный что бы моя команда его защищала публично в одиночку. 15 человек о нём в мире знают, 5 крупных хостеров его используют. Это топ 5 IT компабний. ( майки, эпол, гугл ) Но они строят шизу, что этого метода нет, и что вечного сжатия и рекурсии вычислений и памяти нет.

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

LPU считали невозможным. знайте, всё есть повторение 60 гб словаря.

Разве сжатие байтов в биты это не про общую алгебру?

>>316643851 (OP)
Размер индекса = размеру индексируемых данных. Долбоебский шиз. Поясни ка за эту хуйню.

2 бита информации это 4 возможных значения. Помещаем их в словарь, ок. Какого размера нужен индекс в словаре чтоб указывать минимум на 4 разных значения. Внезапно, тоже 2 бита. Ну и хули ты сжал? Ни-ху-я. Только еще и словарь в нагрузку получил. И хоть блядь 100500 уровней сделай этих словарей. К тебя всегда размер индекса такой же как и индексируемых данных.

Сажа и /thread

>>316666984
Виндовый тар не умеет в спарсовость к сожалению. Сам пидор кстати

>>316667083
А если вместо индекса будем использовать вектор на матрице?

>>316667027
Ты блять шизло а не тян.

>>316666790
>>316666830
И во втором такая же хуйня, шиз тупо меняет формат файла с помощью специально сделанной микропрограмки, сжимает его, а потом разжимает и конвертирует в исходный формат взад. В чем изобретение-то заключается, я спрашиваю?

>>316667083
Ты че, пидор, у нее эпл и гугл алгоритм юзают, не веришь что ли, петух дырявый? Это тян, она слово дала бля.

>>316667141
Это одно и то же.
Принцип голубей в ящике блядь почитай, это элементарно.

>>316667127
Значит ты пиздобол ебаный, а кто пиздит - тот пидорас.

Что думаете о не ассоциативном сжатии?

>>316643851 (OP)
А что так мало, всего 400 постов? Давайте покормим ещё этого шиза, нам же не трудно потратить на него несколько часов жизни

>>316667196
Ты шутки не понял
https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B5%D0%B6%D1%91%D0%BD%D0%BD%D1%8B%D0%B9_%D1%84%D0%B0%D0%B9%D0%BB

>>316667027
>я бы могла и моя команда иметь миллионы и миллиарды, но у меня в жизни и так всё есть
скинешь тысячу рублей мне на кошелёк? для меня это деньги, неделя питания

>>316667211
Я лично сюда поорать зашел)

И с вас всех заодно. Я и есть оп)

>>316667169
Я пытаюсь этот код понять.

>>316667329
Кто "я"? ОП? Ты не можешь код понять, по которому файл формат меняет и обратно, который тебе чат гопоты нагенерил?

>>316643851 (OP)
Чувак, попробуй с chatgpt в шахматы сыграть, и поймешь, чего стоит твой машинописный проект

>>316667399
Нет, я фанат творчества ОПа и мне интересно стало че ему там чат нагенерил.

>>316667186
Нет, это другое по закону тождества.

>>316643851 (OP)
Оп, ты еще тут? Выкладывай блять код на гитхабе, заебал, сейчас гляну ебана рот нахуй что ты там понаписал и высру свое мнение. Надеюсь ты еще тут нахуй

>>316667169
>В чем изобретение-то заключается, я спрашиваю?
В прогреве богатых гоев, сперва изображать аскета-Перельмана, потом "поддаться" на уговоры инвесторов дать ему деняк. Как варик.

>>316643949
Проблема в том, что тебе постоянно нужно будет что-то более жесткое, пока ты не упрешься в лимит порно. Это будет ад.

>>316667433
Я пока что вижу там по итогу злиб сжамает, лол.

>>316667466
Я уже готов дать деняк, но оп не хочет оставлять контакты

>>316667170
>это тян
У тян конечно меньше размер мозга и аналитическое мышление развито слабее. Но не на столько же лол
Не, там просто шиз, у которого видимо некоторые отделы головного мозга бесконечно сжались.

>>316667509
Ишь разбежался, это как если бы сиськостримерша дала своему первому зрителю за донат в 100 рублей. Сперва надо популярной стать, цену себе набить, потом уже устраивать аукцион на сигну

Что думаете о не ассоциативном сжатии байтов как о алгебраических свойствах композиций?

>>316647535
>То есть теперь 40 гигов достаточно чтобы оцифровать всю инфу на земле? А гугол то не знает, блять.
Может и знает. Рассказал бы он всем, если бы знал?
Сейчас вот возьмёт и закроется нахуй со своими миллиардами, потому что надо добро сделать людям))))

>>316643851 (OP)
Пиздец, оп, там тупо zlib compress-decompress. Тебе нейронка нагенерировала код который - да, создает словарь, да, делает кучу телодвижений с numpy, но все сжатие-разжатие это тупо zlib строки, он даже словарь не использует. Словарь там просто как мертвый груз который есть просто чтобы был, как и 99% кода
Мне даже немного жаль, хотя идея у тебя интересная так то, структурировал бы ты ее получше

>>316667775
>хотя идея у тебя интересная так то
У неё идея пронумеровать каждое 32 бит число тем же самым 32 бит числом и называть это сжатием.

>>316652590
>Давай я тебе 15 баксов скину и сделаешь вайпалку двача которая сама будет вайпать с телефона / компа и сама решать капчу.
А я капчу не решаю вообще
Сижу с взломанного ichan
В чём я не прав?

>>316666945
Тут. 1.5 мб в 4 кб. словарь вырос на 10мб. но после 60 гб он перестанет расти.

>>316667891

>>316667891
Злиб из кода убери, подруга.

>>316667652
>>То есть теперь 40 гигов достаточно чтобы оцифровать всю инфу на земле? А гугол то не знает, блять.

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

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

Кстати, оп, можешь оставить контакты? Хоть какие нибудь? В идеале писал бы ты на гите и я там бы напрямую что нибудь оставил бы если что, тот же пулл реквест или тряпку моченную иссуй. Завтра планирую к вечеру всерьез посмотреть что там у тебя и поднять это хрень, может чего и натыкаю, и у тебя рил бесконечное сжатие
Хотя все равно странно, ведь на то чтобы хранить указатель на объект в настолько большом словаре для каждого бита, тебе нужно в лучшем случае столько же бит, сколько число и занимает само по себе

>>316668052
Я сейчас этот код смотрю там каша ебовейшая, как будто нейронка насренькала.

>>316667981
>план американской глобализации но план геноцида

>>316668095
Так он же и написал что там нейронка насрала. Но сама теория интересная, если эта хрень может хотя бы сделать из одной строки другую, которая легче сжимается, даже тем же zlib, то уже можно смотреть что да как. Или в целом привести код в порядок и понять что нейронка его наебала

Докажи, что 2 * 2 не равно 5.

>>316668172
2*2=2.

Следовательно их произведение не равно 5.

>>316667891
Почему твои .ctxt такого же размера, как и оригинальный файл? Где сжатие-то?

>>316667981
>яндекс браузер имеет переводчик на все языки вслух, и все видео ютуба он перевёл
чушь, у него есть какой-то кэш для трендовых видосов, но если запускаешь что-то новое или непопулярное, он требует время на обработку
у прямых эфиров дилей перевода в 30сек - 1 минуту

Бамп

>>316668208
Ещё раз, при умножении 2 2 при аргументе стремящемся к бесконечности, мы будем иметь, что 2 2 будет стремиться к 5.

>>316668257
Ты вообще про что?

>>316667083
>>316667083
Индекс имеет 4 индекса вложенности в итоге 32 бита кодируют все 128 бит. Как? код и метод выше.

Простой пример. Имея две одинаковые книги. Можно не пересылать страницы, а говорить только номер.

так вот, метод генерирует сами страницы и книги

таким образом сжатие в 5-10 раз. за 1 цикл.
Циклы можно повторять до 800 бит.
если разлодить RAM и CPU на 60 гигов словарей то будет рекурсия без вычислений, лучше напомни сколько в X86 запрогано словарей в мб.

>>316668281
Вот они ваши "интеллектуалы" и "не шизофреники". Когда хоть малейший намёк на неудобную информацию, они сразу уходят в игнор и якобы непонимание. Агенты лженауки.

>>316668215
окей давай попробуем сжатую папку NTFS.

>>316667952
>>>316667891
Ты ему упрости задачу
Так будет проще

>>316668164
Я знаю, что она писала, это шутка такая.
Первые находки анализа кода.

>создали сжатие-тред в полдень
Блядь, опять всё проспал.

Несчастная нейронка пыталась написать обычный словарь с хэш таблицей, представляю как она тряслась нахуй.

>>316668215
почему файлы весят столько же ?что бы был понятен метод разложения 4 уровневого индекса. Я могу добавить 5 уровень, тогда словари будут не 60 гб а 100гб но ссылок можно сделать ограничить до 10 млрд на 5 уровне потом на 4.

на 5 уровне файл в виде ссылок будет 30 кб вместо 1мб.

вин рар 7 зим и злиб имеют свои словари и лучше сжимают чем сжатая папка NTFS

Эх, много таких по весне оттаивает... У меня мамка в ПНД работала раньше, частенько рассказывала про таких вот изобретателей вечных двигателей. Бред изобретательства достаточно распространён, и всегда эти изобретатели строят сложнейшие теории, базируясь на детсадовских ошибках в логике или мышлении.

>>316668537
ZLIB из кода убери он всё сжатие делает у тебя.

Если бы я изобрел имба технологию, то вряд на двач бы ее постил и местным обезьянам, думающим что американцы были не Луне, что-то еще доказывал. Логический вывод - тред пиздёж
Парируйте

>>316668501
Существует заговор шизофрении.

За деньги целый год прогеры не хотели прогать вечный словарь. Словно великая тайна за этим стоит.

Поэтому, Я, как Тян, долбила ИИ запросы. и только месяц на питоне была готова программа. все считали это невозможным

>>316668700
Парирую тебе за щеку. Парируй.

>>316668701
Ты могла за месяц питон выучить уже, ты же всё равно ниче не делаешь особо целыми днями.

>>316668558
зачем? он сжимает и словарь и файл. что бы по новой рар его смог. в рекурсии. ты ещё не понял о чём метод?Это словарь всех сжатых состояний в сыром виде словарь бы занимал 144гб постоянных

>>316668739
Так ты за неделю мог бы аниме нарисовать. Почему не научился? ты годами особо ничего не делаешь