Мой "вариант" и есть исключение таких случаев ради умещения в 16 байт.
С бесконечным размеров разархиватора я готов сжимать все фильмы без потерь до нескольких байт.
Можно сжать до пару байт любой существующий в мире файл.
Как вы будете сжимать файл, не находящийся в вашей базе?
Ваш бесконечного размера архиватор включает же сам себя? Сжимаем его самого -- получаем число икс. Сжимаем его самого кроме последнего байта -- число другое. Так как длина бесконечная, мы упрёмся в 2^128 значений.
В конце концов что-то новое появляется не так часто и можно просто выпустить обновление моего архиватора чтобы он это поддержал.
Т.е. предыдущие версии просто не будут разжимать что угодно новое? Отличный выход.
Архиваторы обычные можно применять для сжатия всего подряд -- как, например, сжатие страниц в интернете. Обычно сжимает хорошо, но если попало что-то не то и сжатия не вышло -- не проблема, пусть будет так -- файл выйдет байт на десять больше. Ваш архиватор просто откажется сжимать -- см. вторую часть моего прошлого комментария.
Фильмы, музыка, картинки
Есть сжатие с потерями. Без потерь сжимается отвратительно и вообще сжимать так нет необходимости.
примерно все что угодно что нужно в реальной жизни
было бы неплохо пожать веса к сетке, знаете ли
На мои вопросы вы не ответили -- критерии случайности данных и про равенство архиватора "с вылетом ошибки" вашему.
В каком моменте данные становятся достаточно случайными, чтобы не быть сжатыми вашим архиватором?
Обычный архиватор с условием выброса ошибки при длине результата, большей 16ти байт, попадает под определение вашего архиватора. Все ошибки оправдываются слишком большой случайностью входных данных.
Если брать опять любые реальные вещи, а не абстрактный набор байт.
Если случайные значения не есть реальная вещь, то что насчёт зашифрованных данных? Весов для нейросетки? Вы, как я понял, предлагаете индексировать вообще всю информацию на свете и использовать пресловутый 128-битный индекс как результат "сжатия"?
Коэффициент сжатия ≤1 значит, что не сжимает. Архиватор обязан преобразовывать любые данные на входе к читаемому им же самим формату на выходе, бывает, что и без сжатия.
вполне себе случайные числа, просто с неравномерным распределением
Произвольные -- да, случайные -- нет. При таком подходе все числа можно считать случайными, просто "с неравномерным распределением". Важнейшее качество Г[П]СЧ это как раз таки равномерность и непредсказуемость.
Т.е. ваш алгоритм не работает на произвольных данных? Степень сжатия на рандомах проверять действительно не стоит, но тут вопрос в самой возможности сжатия.
Потому что вводить/выводить в пресловутый Zcash как-то ещё нужно
Речь идёт о криптовалютных миксерах, которые с приходом Zcash стали ненужны. Похоже не все знают, что в Zcash можно переводить деньги скрывая получателя и отправителя
Достаточно всего лишь разом всему миру перейти на Zcash, да. Про Zcash/Monero/Dash (в конце концов) никто и не помнит ничего, кроме факта возможности отмыва с их помощью денег; самоценности в этих валютах толком нет (как в эфире есть крупнейшая экосистема, в битке — стабильность и известность и пр.)
Да-да, знаменитые рейтинги ЯП. У одних Visual Basic популярнее JS (а C не уступает питону), у других — R популярнее TypeScript'а (и это он ещё на три места поднялся)...
В любом случае, лучше Zcash лучше взять даже ethereum + tornado cash, ликвидности там на порядок больше, когда Zcash толком и не торгуется на биржах (coingecko указывает только на "xt.com, whitebit и bkex"), да и сложно будет через него провести достаточно крупные суммы разом. Нужен чисто биткоин — можно взять coinjoin и ему подобные.
от контрактов нет ключей, они неизменяемы. Обновление, если нужно, происходит путём запуска "новой версии" протокола либо путём замены контракта с перенаправление прокси на него (т.е. есть такой же неизменяемый прокси, только перенаправляющий запросы дальше, на контракт, адрес которого можно в прокси и заменить).
пускай пишут большими буквами как проверить со стороны
любая "децентрализованная" крипто биржа имеет во главе "админа", у него есть доступ ко всем ключам и счетам
да ну? на юнисвапе (по образу и подобию которого создано примерно всё остальное) счетов нет, ибо для каждой торговой пары есть свой контракт, где средства и хранятся; создаются они фабрикой контрактов, владельца их нет.
Если все будут держать деньги не на биржах - курса крипты не будет.
"Сложная система контроля типов" - это в основном хаскель надо, в плюсах она вообще слабая; а безопасность это в том числе и проверка переполнений и прочей памяти (раст)
Мой "вариант" и есть исключение таких случаев ради умещения в 16 байт.
Как вы будете сжимать файл, не находящийся в вашей базе?
Ваш бесконечного размера архиватор включает же сам себя? Сжимаем его самого -- получаем число икс. Сжимаем его самого кроме последнего байта -- число другое. Так как длина бесконечная, мы упрёмся в 2^128 значений.
Т.е. предыдущие версии просто не будут разжимать что угодно новое? Отличный выход.
Архиваторы обычные можно применять для сжатия всего подряд -- как, например, сжатие страниц в интернете. Обычно сжимает хорошо, но если попало что-то не то и сжатия не вышло -- не проблема, пусть будет так -- файл выйдет байт на десять больше. Ваш архиватор просто откажется сжимать -- см. вторую часть моего прошлого комментария.
Есть сжатие с потерями. Без потерь сжимается отвратительно и вообще сжимать так нет необходимости.
было бы неплохо пожать веса к сетке, знаете ли
На мои вопросы вы не ответили -- критерии случайности данных и про равенство архиватора "с вылетом ошибки" вашему.
В каком моменте данные становятся достаточно случайными, чтобы не быть сжатыми вашим архиватором?
Обычный архиватор с условием выброса ошибки при длине результата, большей 16ти байт, попадает под определение вашего архиватора. Все ошибки оправдываются слишком большой случайностью входных данных.
Если случайные значения не есть реальная вещь, то что насчёт зашифрованных данных? Весов для нейросетки? Вы, как я понял, предлагаете индексировать вообще всю информацию на свете и использовать пресловутый 128-битный индекс как результат "сжатия"?
Коэффициент сжатия ≤1 значит, что не сжимает. Архиватор обязан преобразовывать любые данные на входе к читаемому им же самим формату на выходе, бывает, что и без сжатия.
Произвольные -- да, случайные -- нет. При таком подходе все числа можно считать случайными, просто "с неравномерным распределением". Важнейшее качество Г[П]СЧ это как раз таки равномерность и непредсказуемость.
В том и смысл, что архиватор-то в одном экземпляре, размер его константен, а сжатой информации потенциально бесконечно много.
Более того: если считать по вашей методике, то коэффициент можно поднять просто архивируя склеенные файлы, верно?
Т.е. ваш алгоритм не работает на произвольных данных? Степень сжатия на рандомах проверять действительно не стоит, но тут вопрос в самой возможности сжатия.
Нет. В 16 байтах информации, больше чем на эти самые 16 байт не влезет. (Доказательство, если нужно: жмём все числа подряд)
Заодно и вопрос-претензия к исходному комментарию: почему размер архива обязан считаться с учётом архиватора?
Санкции санкциями, а Tornado никуда не делся и продолжает работать.
Чем TORN? Он для работы и не обязателен (а ещё он торгуется на DEX'ах).
Потому что вводить/выводить в пресловутый Zcash как-то ещё нужно
Достаточно всего лишь разом всему миру перейти на Zcash, да. Про Zcash/Monero/Dash (в конце концов) никто и не помнит ничего, кроме факта возможности отмыва с их помощью денег; самоценности в этих валютах толком нет (как в эфире есть крупнейшая экосистема, в битке — стабильность и известность и пр.)
Да-да, знаменитые рейтинги ЯП. У одних Visual Basic популярнее JS (а C не уступает питону), у других — R популярнее TypeScript'а (и это он ещё на три места поднялся)...
В любом случае, лучше Zcash лучше взять даже ethereum + tornado cash, ликвидности там на порядок больше, когда Zcash толком и не торгуется на биржах (coingecko указывает только на "xt.com, whitebit и bkex"), да и сложно будет через него провести достаточно крупные суммы разом. Нужен чисто биткоин — можно взять coinjoin и ему подобные.
зато какими категоричными вышли утверждения.
от контрактов нет ключей, они неизменяемы. Обновление, если нужно, происходит путём запуска "новой версии" протокола либо путём замены контракта с перенаправление прокси на него (т.е. есть такой же неизменяемый прокси, только перенаправляющий запросы дальше, на контракт, адрес которого можно в прокси и заменить).
аудиты?
да ну? на юнисвапе (по образу и подобию которого создано примерно всё остальное) счетов нет, ибо для каждой торговой пары есть свой контракт, где средства и хранятся; создаются они фабрикой контрактов, владельца их нет.
если за неё будут хоть что-то покупать -- будет.
вы не поверите...
Материнка, проц, оператива, видеокарта, диск, БП, корпус. Вот.
"Сложная система контроля типов" - это в основном хаскель надо, в плюсах она вообще слабая; а безопасность это в том числе и проверка переполнений и прочей памяти (раст)
Катастрофа. От лагающих вкладок по полгига оперативы теперь не уйти никак (благо есть ещё thunderbird, немного смягчает ситуацию).
Выходная нода - да-а, проблемы могут быть и ещё какие, обычная транзитная нода - проблем нет (сам по факту держу такую, вместо впн'а использую)
Ну, там расширений нет, ничего не изменится.