LINUX.ORG.RU

[quine][sh][dc] Смысл жизни

 ,


0

1
$ A="dc -e'[[dc -e]P39dP8BPrP8DP1F6BAPP10P]dx'"; diff -sq <(echo $A) <(eval $A); echo $A | tee /dev/stderr | wc -c
Files /dev/fd/63 and /dev/fd/62 are identical
dc -e'[[dc -e]P39dP8BPrP8DP1F6BAPP10P]dx'
42

License: public domain

★★★★★

Последнее исправление: Xenius (всего исправлений: 1)

ну присвоил параметру А значение, сделал значение А читаемым для ПХП и отправил его diff-у с параметрами. после передал значение в дерево каталогов , а после вайл в качестве аргумента передался в приборчики и идентифицируется DC.

Free-Boatman
()
Ответ на: комментарий от Free-Boatman

Причем тут PHP? Ты что, о квайнах не слышал?

Добавь строчку в текстовый файл (перевод строки в конце), chmod +x на него и запусти, а потом сравни с выводом cat file

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

ничего не понял. :) я только до форматов исполн. файлов дошёл.

Free-Boatman
()
Ответ на: комментарий от Xenius

Этот вопрос спорный. Здесь изначально было много условностей, не оговариваемых явно. Со временем, основная мысль потерялась. Смотрите сами.

Когда мы сравниваем два квина, один длиной 10 слов, другой длиной 1000 слов, то очевидно, что первый проще устроен в любом случае. Длина здесь является некоторым критерием простоты. Но когда мы сравниваем два квина, один длиной 40 символов, другой 50, то совершенно не очевидно, какой из них проще устроен. Здесь нужен другой подход к простоте.

Может быть, малая длина важна по другим причинам? Вспомним, например, баммеров кода (см., к примеру, HAKMEM или книгу Стивена Леви). Но они говорили о длине программы в байтах. Ровно столько байт, сколько программа займет в памяти ЭВМ. И это было действительно важно!

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

Когда я говорил про простое устройство квина, я имел ввиду следующее.

Квин A, вообще говоря, должен обладать двумя свойствами: A-конечной длины, и A==eval(A).

Поскольку в sh функции не являются объектами первого порядка, то выражение A==eval(A) следует понимать как (echo A)==(eval A). Значит, результатом вычисления A должна быть строка, и квин, следовательно, должен включать операции печати. Кроме того, обеспечивая конечность длины квина, мы вероятнее всего будем использовать присвоения (возможно, опеределение функций, циклы). По идее, без этого не обойтись, но все остальное не обязательно.

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

В частности, в приведенном примере, это: строковое представление, печать, присвоение.

anonymous
()
Ответ на: комментарий от anonymous

Зато байты кода — наиболее простой метод вычисления характеристики квайна. И от байтов кода зависит место, занимаемое квайном в памяти того кто его читает.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

В такой характеристике мало ценного. Кроме того, про память человека раз уж речь зашла - ваш квайн даже после 10 повторений сложно запомнить - он в 5 раз длиннее кратковременной памяти и не разбивается на группы))) Конечно, это шутка, но в любом случае, приведенный мной запомнить легче, согласны?

Кроме того, раз уж вы используете dc, я, пожалуй, для printf заранее определю макрос p, и не буду считать его определение частью квайна, кроме того, удалю 4 необязательных пробела. Останется 36 символов.

Больше подходит на характеристику простоты вот такая - количество существенных частей в определении. В приведенном мной случае это (выделено в []):

[=]['][=][\47][%s][\47][;] [printf] [«][$s][»] [«][$s][»]['][;] [printf] [«][$s][»] [«][$s][»]

%s, $s, \47, printf выделены каждый как один существенный элемент, потому что, хоть они и записываются несколькими символами, на деле представляют собой каждый одну неделимую сущность.

Сколько таких неделимых сущностей у вас?

anonymous
()
Ответ на: комментарий от anonymous

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

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

Я так понимаю, что вы забыли, что [s] — это лоркод.

[s][=]['][=][\47][%s][\47][;] [printf] [«][$s][»] [«][$s][»]['][;] [printf] [«][$s][»] [«][$s][»]

Такой подсчёт непоследователен, поскольку считает кавычки, но не считает обратный слеш.

Я бы посчитал так или так:

(s)(=)(')(s=(\)(47)(%s)(\)(47); printf "$s" "$s")(')(;) (printf)( )(")($s)(")( )(")($s)(")

(s)(=)('s=(\47)(%s)(\47); printf "$s" "$s"'); (printf) ("($s)") ("($s)")
То есть 21 или 11. Значимые (без которых не работает) пробелы следует всё-таки считать.

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

dc -e[110376904385883PP1566865418P]dx

(dc)( )(-e)([)(110376904385883)(P)(P)(1566865418)(P)(])(d)(x)
(dc) (-e)([(110376904385883)(P)(P)(1566865418)(P)])(d)(x)

То есть, 12 или 10...

Кстати, самый простой (какой я знаю) квайн на чистом dc (не мой) выглядит так:

6581840dnP

То есть в нём всего лишь 4 смысловых компонента.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.