На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! правила раздела Алгоритмы
1. Помните, что название темы должно хоть как-то отражать ее содержимое (не создавайте темы с заголовком ПОМОГИТЕ, HELP и т.д.). Злоупотребление заглавными буквами в заголовках тем ЗАПРЕЩЕНО.
2. При создании темы постарайтесь, как можно более точно описать проблему, а не ограничиваться общими понятиями и определениями.
3. Приводимые фрагменты исходного кода старайтесь выделять тегами code.../code
4. Помните, чем подробнее Вы опишете свою проблему, тем быстрее получите вразумительный совет
5. Запрещено поднимать неактуальные темы (ПРИМЕР: запрещено отвечать на вопрос из серии "срочно надо", заданный в 2003 году)
6. И не забывайте о кнопочках TRANSLIT и РУССКАЯ КЛАВИАТУРА, если не можете писать в русской раскладке :)
Модераторы: Akina, shadeofgray
Страницы: (2) [1] 2  все  ( Перейти к последнему сообщению )  
> Архивация НЬЮ 2 , ответ на пари от shadeofgray
    Добавлено
    Shadeofgray извените что так,долго времени не отвечал на пари(не было времени).Вы мне ставите условие(но я же вам сказал что я могу сжимать некоторые вектора данных).И вы мне предлогаете за выйгранное пари 5000?Это смех.
    Свою программу я не засвечу даже откомпилированную.
    Я хотел бы поменять условия пари:
    Например см файл:(37591-Значное число).Я могу сжать эти данные в 15 значное число.Я доказываю вам это, и вы мне отсылаете на
    счет WM 9999 р.Согластны?
    p.s.Исходники и откомпилированую программу выслать не могу.
    Прямое и обратное преобразование без потери информации.
    Сообщение отредактировано: Dethlord -

    Прикреплённый файлПрикреплённый файлНовый_текстовый_документ__3_.rar (18.45 Кбайт, скачиваний: 267)
      [quote=albom,1258467539,2423873]Я тоже могу. И что дальше?[/quote]
      Мне интересно если это правда(на разработку алгоритма у меня ушло 5 лет)
      quote=albom,1258467539,2423873]Сами то почему пари не приняли?[/quote]
      В виду сжатия некоторых векторов данных.А не их множества, что тут не понятного?

      Добавлено
      albom почитайте внимательно тот пост он предлагает еще и распаковщик.

      Добавлено
      Сразу скажу что я не использовал словарные методы при сжатии.И не пользовался транцендентностью числа пи(т.е.это не число после запятой в n-последовательности дробной части пи)
        Цитата albom @
        Нет уверенности, что Ваш алгоритм сможет это сделать?

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

        Цитата albom @
        размер упаковщика больше размера исходных данных

        У меня нет

        Цитата albom @
        зачем рассказывать о том, чем Вы не пользовались?

        Да затем что я без залипона сжимаю

        Добавлено
        Цитата albom @
        что какая-то последовательность из записи числа пи сжимается вашим алгоритмом хуже

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

          Кстати фразу об использовании представления числа π для сжатия, я бы считал шуткой, поскольку длина "сжатой" строки в таком алгоритме в лучшем случае равна длине сжимаемой, а нормально даже длиннее.
          например самая короткая двоичная последовательность содержащая в себе все возможные наборы из 16 бит имеет длину 65551 бит. Чтобы определить нужную позицию в ней как раз 16 бит и нужно.
            Цитата amk @
            А говорят тебе о том, что для любого алгоритма сжатия всегда можно подобрать такой пример, что после сжатия выходная последовательность окажется длиннее входной

            Да я вообще-то об этом не спорил я сам понимаю это.
            Цитата amk @
            об использовании представления числа π для сжатия, я бы считал шуткой

            Да метод хороший(про него еще Гарднер писал) вот только время поиска и длина результата может быть большим.
              Алгоритм с числом пи скорее для шифровки, а не для сжатия.
                Цитата amk @
                А говорят тебе о том, что для любого алгоритма сжатия всегда можно подобрать такой пример, что после сжатия выходная последовательность окажется длиннее входной.

                Все таки не для любого.
                В данном примере. Идеальной ф-ие сжатия является функция копирования
                  Цитата amk @
                  Dethlord,
                  сдается мне, что ты не очень хорошо понимаешь о чем тебе говорят.
                  А говорят тебе о том, что для любого алгоритма сжатия всегда можно подобрать такой пример, что после сжатия выходная последовательность окажется длиннее входной.

                  Цитата Dethlord @
                  Да я вообще-то об этом не спорил я сам понимаю это.

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

                  Цитата Dethlord @
                  Я хотел бы поменять условия пари:
                  Например см файл:(37591-Значное число).Я могу сжать эти данные в 15 значное число.Я доказываю вам это, и вы мне отсылаете на
                  счет WM 9999 р.Согластны?

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

                  Вы же предлагаете мне, что я:
                  а. соглашаюсь с измененными условиями пари
                  б. получаю от вас 15-значное число и заверения в том, что алгоритм работает
                  в. выплачиваю вам в два раза больше, чем предполагалось первоначально

                  В такой формулировке мне можно сразу готовить деньги, не дожидаясь исполнения пункта (б) - вы же уже сказали мне, что алгоритм работает на конкретном векторе, а джентльменам верят на слово :)

                  Но даже если бы вы предложили мне распаковщик и доказали, что действительно сжали данные до 15 знаков - даже в таком случае пари, в котором вектор выбираете вы, а не я, мне не интересно. Откуда мне знать - может этот вектор получен в результате работы генератора псевдослучайных чисел, и 15 цифр - это как раз длина генератора (или стартовых значений)? Вы не сказали, как вы получили этот вектор - но я уверен, что это не случайное число. А на случайном числе, по моему убеждению, результат работы вашего алгоритма будет не особенно хорош.

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

                  Добавлено
                  Цитата esperanto @
                  Все таки не для любого.
                  В данном примере. Идеальной ф-ие сжатия является функция копирования

                  Замечание хорошее, но я хотел бы отметить, что надо также как-то сообщить, что мы используем именно её, а не какой-то другой алгоритм "сжатия". Так что размер сообщения всё равно увеличится :)

                  Добавлено
                  2 albom, писали сообщения независимо, а мысли одни и те же пришли в голову :)
                    albom и shadeofgray распаковщик у меня тоже не большой
                    Цитата albom @
                    , тогда запакованные данные будут семенем ГПСЧ, а распакованные данные — последовательностью, генерируемой ГПСЧ

                    Я не пользуюсь генераторами.
                    Цитата albom @
                    Но без этого какие же это доказательства

                    Они будут при согласии опонента.
                    Цитата albom @
                    это строка из первого сообщения сжималась пять лет?

                    Запаковка шла около 4 дней
                    распаковка 4 секунды
                    shadeofgray Я НЕ ПОЛЬЗУЮСЬ ГСЧ
                    Зачем мне вас обманывать если я вам буду предоставлять доказательство(приватно соответственно)
                    Цитата shadeofgray @
                    б. получаю от вас 15-значное число и заверения в том, что алгоритм работает

                    ДОКАЗАТЕЛЬСТВО!
                    Цитата shadeofgray @
                    Цитата (esperanto @ Вчера, 21:50)
                    Все таки не для любого.
                    В данном примере. Идеальной ф-ие сжатия является функция копирования

                    бред полный.
                    shadeofgray я не использовал в своём алгоритме ни один тип реализованих уже методов(типо ГСЧ,словари,хафманы и тд) у меня свой метод.А также я не пользуюсь всякими XORами и самопорождающимися множествами.
                    Т.Е при моем доказательсве вы откините все сомнения, так как я пользуюсь исключительно многомерной математикой и диоффантовыми уравнениями.
                    из 4000-значного числа я сногу очень сильно сжать только 120000000 векторов а это очень мало.
                    Поэтому я не согласен(вероятность что я сожму ваш вектор(например 1000-знаков) составляет примерно 1 %)
                      Ну а в чем тогда ценность вашего алгоритма? Даже RLE может очень сильно сжать намного большее количество специально подобранных векторов, чем ваш алгоритм. Опять же, если он хорошо работает только на некоторых редких векторах, то я легко могу придумать алгоритм, основанный на ГСЧ, который:

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

                      В общем, в таких условиях пари не имеет смысла.
                        Т.е. я хочу сказать, что у вашего алгоритма могут быть другие достоинства. Он может сжимать лучше других алгоритмов, может очень хорошо обрабатывать важные частные случаи, может делать что-то ещё... Если у него есть действительно ценные достоинства, скажите нам о них - лично мне это действительно интересно. Может, это просто proof-of-concept, но очень интересной концепции...

                        Но то, что он "в сотни и тысячи раз сжимает редкие, специально подобранные последовательности, которые другой алгоритм так хорошо сжать не сможет" - это совершенно определенно достоинством не является, т.к. если эти последовательности надо специально подбирать, то ценность алгоритма невелика. Разве что есть такой класс данных (лог файлы, базы данных, что-то ещё), где эти последовательности встречаются на каждом шагу.
                          shadeofgray Можем обьединить усилия после заключения взаимного договора.[
                          quote=shadeofgray,1258537268,2424564]Может, это просто proof-of-concept[/quote]
                          Да, в точку
                          Цитата shadeofgray @
                          Ну а в чем тогда ценность вашего алгоритма?

                          Конечно на коммерческую версию не тянет.
                          shadeofgray можно теоритически расчитать предельную степень сжатия(любых данных) на основе комбинаторных методов.

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

                          Добавлено
                          shadeofgray самое удивительное что RAR-версия файла всего в 2 раза меньше исходного.
                          Ну раз пари не будет покажу сжатую строку:
                          #345568#6787#5#4

                          Данная строка представляет собой сжатую версию файла в 1 посте.

                          PS.Извените оговорился не 15 символов а 16 так как первый разделитель еще(#)
                            Цитата Dethlord @
                            Например см файл:(37591-Значное число).Я могу сжать эти данные в 15 значное число....
                            p.s.Исходники и откомпилированую программу выслать не могу.
                            Сравните это описание с рапидшарой и вы поймёте, почему ваше пари не принято.
                            И вот у меня такой вопрос: можно ли заранее предсказать, какие данные ваш алгоритм сожмёт хорошо, а какие нет?
                              Цитата Dethlord @
                              shadeofgray Можем обьединить усилия после заключения взаимного договора.

                              Я не вижу на этом направлении каких либо перспектив.

                              Цитата Dethlord @
                              PS:Я склоняюсь к теории большого взрыва ,поэтому считаю что это дело времени и когда-нибудь человечество откроет алгоритм сжатия хаотических данных без потерь.

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

                              Цитата Dethlord @
                              shadeofgray Может, это просто proof-of-concept
                              Да, в точку

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

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

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

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

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


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0950 ]   [ 15 queries used ]   [ Generated: 29.03.24, 01:00 GMT ]