предисловие
В очень жаркой ситуации вы должны пойти еще дальше с игрой в гольф.
(например, в задании, где ваш ответ имеет длину 100 символов, и это просто смущает, что вы не можете сделать это 99)
В этом случае, теперь вы используете алгоритм победителя этого задания :)
Цель
Вы должны написать программу, которая принимает uint32 и возвращает наиболее сжатую форму.
$ mathpack 147456
9<<14
- Там будет несколько решений для числа. Выберите самый короткий
- Если сжатая форма длиннее или равна исходному номеру, вернуть исходный номер
правила
- писать на любом языке - выводить на любом языке
- я знаю, что в C
'abc'
есть,6382179
и вы можете достичь довольно хороших результатов с этим преобразованием. но языки разделены в этом вызове, так что не унывай - запрещено использовать внешние переменные. только операторы и литералы и математические функции!
счет
Вот тестовые примеры: pastebin.com/0bYPzUhX
ваш показатель (в процентах) будет равен соотношению byte_size_of_your_output / byte_size_of_the_list
без разрывов строк .
(Вы должны сделать это самостоятельно, так как я на всякий случай проверим лучшие коды)
Победители будут выбраны по баллам и языку вывода !
Примеры:
$ mathpack 147456 | mathpack 97787584 | mathpack 387420489
9<<14 | 9e7^9e6 | pow(9,9)
code-challenge
Бебе
источник
источник
write in any language - output in any language
- два языка могут быть разными, верно?Ответы:
Код: Mathematica, Выход: C, ~ 62.1518% (12674/20392)
Я думал, что тоже попробую С из-за этих забавных литералов персонажей. В настоящее время это единственное, что пытается найти этот ответ, и он работает довольно хорошо.
Надеюсь, я ничего не пропустил, но этот ответ поможет избежать обратной косой черты, одинарных кавычек и триграфов. Существует некоторый закомментированный код, который использует восьмеричные или другие escape-последовательности для непечатаемых символов, но я не думаю, что это на самом деле необходимо, потому что C должен иметь возможность обрабатывать любые байты в символьных литералах, afaik (пожалуйста, исправьте меня, если я я не прав)
Как с другим представлением, проверьте это с
источник
\n
) и 13 (\r
). Нулевой байт будет компилироваться нормально, но с сообщением об ошибкеwarning: null character(s) preserved in literal
.Код: Mathematica, выход: Юлия, ~ 98,9457% (20177/20392 байта)
Функция берет число и возвращает самую короткую найденную строку . В настоящее время применяется четыре простых оптимизации (я могу добавить еще завтра).
Вы можете применить его ко всему файлу (чтобы измерить его оценку) следующим образом:
Обратите внимание, что некоторые из этих оптимизаций предполагают, что вы используете 64-разрядную версию Julia, так что целочисленные литералы дают вам
int64
по умолчанию. В противном случае вы будете переполнены для целых чисел больше 2 31 . Используя это предположение, мы можем применить несколько оптимизаций, промежуточные шаги которых на самом деле даже больше 2 32 .РЕДАКТИРОВАТЬ: я добавил оптимизацию, предложенную в примерах OP, чтобы поразрядно xor два больших числа в научной нотации (фактически, для всех xor , или и и и ). Обратите внимание, что расширение
xormap
,ormap
иandmap
включить операнды за пределами 2 32 могут помочь найти дополнительные оптимизации, но она не работает для данных тестов и только увеличивает время выполнения что - то вроде в 10 разы .РЕДАКТИРОВАТЬ: я сбрил еще 16 байтов, проверив все на
n-9, n-8, ..., n+8, n+9
наличие какого-либо из возможности сокращения них , и в этом случае я представлял число на основе этого, добавляя или вычитая разницу. Есть несколько случаев, когда одно из этих 18 чисел может быть представлено на 3 или более символов меньше егоn
самого, и в этом случае я могу сделать дополнительную экономию. Теперь требуется около 30 секунд, чтобы запустить его во всех тестовых случаях, но, конечно, если бы кто-то на самом деле «использовал» эту функцию, он бы запустил ее только для одного числа, так что это все еще намного меньше секунды.РЕДАКТИРОВАТЬ: один невероятный 4 байта, делая то же самое для умножения и деления. 50 секунд (разделенные не занимают так много времени, потому что я проверяю их, только если число на самом деле делится на интересующий фактор).
РЕДАКТИРОВАТЬ: еще одна оптимизация, которая на самом деле не помогает с данным набором тестов. Этот может сохранить байт для таких вещей, как 2 30 или 2 31 . Если бы вместо этого у нас были uint64s, было бы много чисел, где это могло бы принести огромную экономию (в основном, всякий раз, когда представление битов заканчивалось многими единицами).
РЕДАКТИРОВАТЬ: Убрал XOR , или , и оптимизация в целом. Я только заметил, что они даже не работают в Джулии, потому что (совершенно очевидно) научная запись дает вам плавающее число, где побитовые операторы даже не определены. Интересно, что одна или несколько новых оптимизаций, кажется, охватывают все случаи, которые были сокращены этими оптимизациями, потому что оценка не изменилась вообще.
источник
От J до C (не проверено, но работает в большинстве случаев, вид базового ответа.)
Выводит строковый литерал, который, если он введен в C, представляет число (как упомянуто в OP). Это не серьезное представление, а скорее что-то, чтобы укрепить мои навыки J, которыми я поделился.
Альтернативный однострочный:
Что J пытается сделать из этого, когда вы вводите это:
Большое спасибо, J. Также, для тех, кто «знает» о J, visio качается за создание более сложных функций:
источник
\
,?
или'
?m&u@:v
используйтеm u v
для сохранения ценных символов и повышения читабельности. Применяя это к коду, мы получимf =: [: (,~ 0 $~ 8 - 8 | #) #:
иg =: [: ($~ 8 ,~ # % 8:) f
наконецtoCString =: a. {~ [: #. g
. Все вместе мы получаемa. {~ [: #. [: ($~ 8 ,~ # % 8:) [: (,~ 0 $~ 8 - 8 | #) #:
, что действительно легко читать.