Оу, кажется, единственный комментатор, который обратил внимание на механизм :)
Нет, пробел между звездочками ничего не изменит, именно перед слешем. Это превращает */ в * / и дезавуирует последовательность как завершающий комментарий токен. Таковым становится следующий в очереди /*/, который до этого наоборот начинал следующий блок комментария, и т.д. по цепочке до завершающего /**/. Лучше всего это наблюдать в IDE с подсветкой синтаксиса.
Понятно. Разумеется выключка комментированием предназначена исключительно для относительно «легких» текстов, и желательно IDE с подсветкой. Это верно для любой подобной техники. Но в «тяжелых» тоже попадалось.
Не очень :)) И как можно пробел (20) перерезать в CR (0D)?
Лезвием дырки в перфокарте сверлить — мда, работа для ювелира-труженика :) Эх, времена… Я в немножко похожей ситуации пользовался автоматическим переносом слишком длинной строки. Принтеры были уже матричные.
Попробую. Из графика частотности видно, что решающее значение для общего показателя компрессии имеют лишь несколько первых интервалов: 6, 12 и 2, 4, 8, 10. По сути без разницы, какие коды использовать — лишь бы эти несколько были наиболее короткими. В предложенном варианте они наиболее короткие.
Наверно я чего-то не понял. Это уменьшит таблицу НАТУРАЛЬНЫХ чисел, исключив из них 3/4 и все неподозрительные на простоту. Таблицу ПРОСТЫХ это увеличит, добавив в нее помимо простых еще и подозрительные на простоту.
Построение на лету хорошо для разовых задач, но усложнение программирования ставит под вопрос выполнимость самих таких задач. Прикладные задачи потребуют дополнить построение на лету кэшированием и сложность программирования возрастет в разы.
Гм, хорошая идея :) В голову не пришло.
Отдельные вещи можно проверить у альтернативных источников. Например, последнее простое в использованной мной таблице 999999999989, имеет порядковый номер 37607912018, здесь primes.utm.edu/nthprime этому можно получить подтверждение. Значит, во всяком случае пропусков нет. А вот проверить на предмет перестановок и подмен — тут увы. Только поэлементное сравнение с такой же таблицей, либо поштучная проверка на простоту. Собственно, этим-то простые и замечательны, что другого способа нет.
Берем все числа в промежутке, который вызывает у Вас подозрения. И проверяем все по очереди :)
Вообще-то таблицы так и строят — берут все числа по очереди. Как тут пропустить что-то можно?
У меня такое чувство. что половина из отметившихся в комментариях не уловила, суть идеи в строго детерминированном характере частотности интервалов. Традиционное же кодирование исходит из некоторых общих представлений о данных. Поскольку частотность интервалов детерминирована, нет никаких проблем рассчитать эффективность любого другого метода кодирования, на последней диаграмме я несколько таких примеров привел. Есть предложение? Посчитайте сами. Итоги в студию.
Не думаю, что будет большая разница между традиционной компрессией последовательности простых и последовательности интервалов между простыми, между ними нет принципиальной разницы. Т.е., сжатие будет приличное, но не олимпийское. Пробовать, честно говоря, лень :)
Точно. За одним минусом — с этого момента восстановление простого по его порядковому номеру становится нетривиальной задачей, что уравнивает метод с более продвинутым.
Нет, пробел между звездочками ничего не изменит, именно перед слешем. Это превращает */ в * / и дезавуирует последовательность как завершающий комментарий токен. Таковым становится следующий в очереди /*/, который до этого наоборот начинал следующий блок комментария, и т.д. по цепочке до завершающего /**/. Лучше всего это наблюдать в IDE с подсветкой синтаксиса.
Лезвием дырки в перфокарте сверлить — мда, работа для ювелира-труженика :) Эх, времена… Я в немножко похожей ситуации пользовался автоматическим переносом слишком длинной строки. Принтеры были уже матричные.
#define DEBUG
#ifdef DEBUG
…
#else
…
#endif
#ifdef DEBUG
…
#else
…
#endif
?
Построение на лету хорошо для разовых задач, но усложнение программирования ставит под вопрос выполнимость самих таких задач. Прикладные задачи потребуют дополнить построение на лету кэшированием и сложность программирования возрастет в разы.
Отдельные вещи можно проверить у альтернативных источников. Например, последнее простое в использованной мной таблице 999999999989, имеет порядковый номер 37607912018, здесь primes.utm.edu/nthprime этому можно получить подтверждение. Значит, во всяком случае пропусков нет. А вот проверить на предмет перестановок и подмен — тут увы. Только поэлементное сравнение с такой же таблицей, либо поштучная проверка на простоту. Собственно, этим-то простые и замечательны, что другого способа нет.
Вообще-то таблицы так и строят — берут все числа по очереди. Как тут пропустить что-то можно?
У меня такое чувство. что половина из отметившихся в комментариях не уловила, суть идеи в строго детерминированном характере частотности интервалов. Традиционное же кодирование исходит из некоторых общих представлений о данных. Поскольку частотность интервалов детерминирована, нет никаких проблем рассчитать эффективность любого другого метода кодирования, на последней диаграмме я несколько таких примеров привел. Есть предложение? Посчитайте сами. Итоги в студию.