- 1
console.log(24000);
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+7
console.log(24000);
Понятно что за счёт хитрый рекурсий ++x вызывается 24к раз. Но не могу это распарсить за приемлимое время.
Это руками написано?
Руками, конечно.
Не так уж трудно построить серию выводов, в которой каждый последующий простейшим образом вытекает из предыдущего. Если после этого удалить все средние звенья и сообщить слушателю только первое звено и последнее, они произведут ошеломляющее, хотя и ложное впечатление.
(Артур Конан Дойл. Пляшущие человечки)
Очевидно, что для компактной записи надо как-то разложить число на множители (возможно, ложное впечатление для лямбда исчисления, но в машине Тьюринга оно работало). Далее подготовленную кашицу из числа стоит выражать через нумералы Чёрча. Приведу далее недостающие звенья:
Оставим для следующего раза, когда сразу будут честные лямбды.
А тут я и умножение записал громоздко:
Надо n => m => f => n (m (f)), а не то, что я написал с пометкой "надо" (я там сложение написал).
При использовании функций от двух аргументов как раз неизбежно выходит то, что у меня.
Заинлайнив pow и сократив имена, получаем
>Возведение в степень тоже можно было как нумерал напесать.
Думаю тут нужна гипероператорная функция Аккермана для того чтоб окончательно запутать читателя. pow и prod — частые её случаи.
Особенно радует повышение дзена, когда с ростом питульности гипероператора из формулы выкидывается очередной лишний кусок, что на последней итерации даёт самую простую формулу из возможных:
Хотя, на реализацию гипероператора в таких терминах интересно было бы посмотреть.
Смысл очень простой: он применяет n раз ф-цию f над m.
То есть n раз инкремент 0 — n
То есть n раз сложение m — m*n
То есть n раз умножение m — m**т
Думаю реализация будет такая же во всех случаях.
> prod = (n, m) => (f, x) => n(f, m(f, x)); //
>H(op-1,a,H(op,a,b-1));
Только нужно делать декремент на функции:
Так это оно и есть, только в частной форме.
Рекурсия руками.
Неподвижная точка руками.
> Только нужно делать декремент на функции
Декремент не нужен. Тут же можно обойтись без этого, пользуясь не рекурсией, а корекурсией (если я правильно понимаю значения этих слов). Нумерал Чёрча сам отсчитает нужное количество итераций и сконструирует нужную питушню. Сумма - не разбор левого операнда для наращивания правого, а наращивание правого операнда левым; произведение - не разбор левого операнда ради набрасывания суммы на правый, а левооперандное наращивание нуля правым операндом, и так далее.
В мире нумералов Чёрча надо найти такую функцию f, которой можно подействовать k раз на hyper0, чтобы получился hyperk, никаких декрементов. Если k - нумерал Чёрча, hyperk = k(f, hyper0).
Смотрим. hyper0 - просто succ правого операнда; hyper1 - применение hyper1 m раз к m - сумма; hyper2 - применение m раз функции x => sum(n, x) (или x=>hyper1(n)(x)) к начальному значению 0 - произведение; и так далее. Сокращая здесь и далее hyper до h, получаем:
Видно, что каждый новый гипероператор h' получается из старого h и начального значения x по формуле
Для гипероператора понадобится последовательность n, 0, 1, 1... Очевидно, что из-за начального n она не будет чистой функцией от одного аргумента. Я сначала в силу шаблонности мышления не придумал ничего лучше использования обычного бесконечного списка значений. Но для создания такого списка мне понадобилась богомерзкая рекурсия (Z кобенатор).
На самом деле, достаточно FIFO из двух элементов (x1, x2) = (n, 0), в конец которой добавляют 1.
Преобразование гипероператора - преобразование 3-кортежа (h, x1, x2):
С использованием стандартных функций zero, succ, pair, first, second, гипероператор можно переписать кратко как
>19 минут назад #
Господи боже мой, за минуту два сверхупоротых (в хорошем смысле) поста. Теперь мне медитировать полдня, чтоб что-то по делу ответить.
Еще раз какая там у вас клавиатура?
>const h2 = n => m => m(h1(n))(zero);
>const h3 = n => m => m(h2(n))(one);
>const h4 = n => m => m(h3(n))(one);
Интересно можно ли как-то не хардкодить, но вывести из свойств гипероператора нейтральный элемент для каждого n. Для сложения это 0, для умножений и степени — 1.
В смысле убрать эту неэстетичную часть:
> b < (1+(op>1))
Чтобы построить новый гипероператор, нужен старый и нейтральный элемент старого. Из работающего гиператора нейтральный элемент можно найти подбором.
x @ x0 = x
В теории тут можно и без кобенаторов, т.к. количество итераций не превышает n.
Единственное - с h0 будут проблемы.
Не знаете, как этого избежать?
Ну и подбор будет всё равно использовать 0 и 1.
>нейтральный элемент можно найти подбором.
That's not how the Math works.
>Единственное - с h0 будут проблемы.
Никаких проблем нет: всё логично получается:
x+0=x
x*0=0
x⁰=1
Нейтральный эл-т (h_n), есть применение нуля к (h_n+1). Только круг какой-то замкнутный.
Так это кольцо твоего ануса.
Возможно h0 и не инкремент вовсе.
Весомо. В литературе при определении гипероператоров иногда избегают инкремента, останавливаясь на плюсе.
Все остальные операции бинарны, a+b, a*b, a^b;
Инкремент же унарный. Отсюда и траблы при унификации.
То есть я допускаю
Что есть бинарная f(a,a), отличная от инкремента функция (возможно побитовая), которую можно применить b раз, и получить a+b.
Раз такую функцию настойчиво скрывают и либо выкидывают h0, либо вставляют богомерзкую унарщину, скорее всего ничего ценного не нашли.
Питушня должна быть фундаментально проще сложения и умножения, и соответственно - разности и деления, а также должна работать на целых числах.
Тут либо действительно инкремент оставлять, либо вводить R и читерствовать с делением, добавляя кусочек операнда по какой-нибудь экспоненциальной логике (f(a, b) = a+k(a,b)*b). Можно ещё вероятностные операции вводить: f(a,b) = b*random()<1 ? a+b : a; - в среднем за b таких сложений наберётся a+b, но всё из того, что придумывается - какая-то сомнительная питушня.
Да-да, именно в этом направлении и мыслил.
> либо вставляют богомерзкую унарщину, скорее всего ничего ценного не нашли
Всё-таки я упоролся, в вечер пятницы странные мысли лезут в голову.
Используя индукцию можно элементарно доказать что инкремент (или другая функция, которая ведёт себя абсолютно так же) - единственно возможна.
Или в общей питухаскельной форме.
Никаких частичных штук тут не получается, поскольку все промежуточные результаты: инкременты.
То есть доказываем для случая где b=1; f(a,a)=a+1
Потом доказываем что f(a,a)☓b+1 раз = f(a,a)☓b+1
И остаётся доказать кейсы что функция инкрементит a, даже если второй аргумент меньше чем а.
Думал и над этим.
Подбор не такая плохая штука, как может показаться на первый взгляд.
Вдруг код будет выполняться во вселенной, где 0 — нейтральный эл-т умножения? А нейтральный элемент сложения допустим -1.
В целом интересно получается.
Для H₀ нейтрального элемента нет вовсе. Второй аргумент функция игнорирует примерно в таком духе
Для H₁ нейтральный эл-т это 0 . Однако нет инвариантного элементa, который при взаимодействии даёт констранту ради лулза назовём его нейтрализующим.
Для умножения H₂ нейтральный эл-т это 1. Нейтрализующий эл-т 0, он превращает любой другой элемент в себя.
Для степени и высших порядков H₃ всё практически так же. 1 в любой степени это 1. Только нуль превращает всё в 1. Насчёт 0⁰ спорят, и тем не менее.
PS. Как же меня бесят 500 на ГК. Как не напишу километровый пост, вечно получаю ошибку. ЧСХ на ворециях очень редко падает.
Пишите в отдельном редакторе, ну или Ctrl+A, Ctrl+C перед Ctrl+Enter.
Отдельный редактор тем хорош, что по Ctrl+A показывает, сколько символов занято - в итоге можно оценить и подсократить/разбить пост.
> ЧСХ на ворециях очень редко падает.
А Вы случайно не хитрые юникодные символы вставляете в формулы? В ворециях их как раз нет, а в математических постах - вполне возможны (ГК учит ASCII-скромности).
Сказал король юзерскриптов. Можно сделать ЮС который сохраняет перед отправкой коммент в историю в localStorage и не даёт проебать.
По поводу юникода, думаю дело не в нём. Пару раз сохранял текст перед отправкой и попадал на эксепшон, перезагрузка страницы и повторная попытка помогает. Если бы дело было в кодировке, не пропускало бы ни с какой попытки.
Я думаю это что-то чуть более сложное, чем csrf verification error. Что-то протухает или какой-то таймаут превышается. Это объясняет и то, что медленно вручную написанный текст порой вызывает проблемы, а копи-паст вореции, которые генерируются и постятся за секунду — реже.
Впрочем, скрипты для себя пишутся тогда, когда без скрипта уже совсем плохо, т.к. лень. А в npp уже есть автоматический бэкап и автосохранение несохранённых файлов в специальной папке. Начал писать комментарий, другой, закрыл редактор, открыл через неделю, и тексты комментариев сами открываются. Всё те же несохранённые new 1 и new 2.
Да, похоже из-них не падает.
Кстати я только сейчас оценил прикол с жырным нулём (http://govnokod.ru/24000#comment410458).
Он тоже не поддерживается ГК.
Как ни напишу…
Я вот как раз думал над этим.
Можно ведь написать и такой пример, который тайно сделает rm -rf.
Число n - функция, которая принимает функцию f и значение x, а возвращает n-кратное применение функции f к значению x.
succ - функция, которая принимает n и возвращает n+1.
Просто я кажись видел на гитхабчике кодогенераторы похожей произвольной питушни.
Не уверен, что это последняя версия.
Как символично )))
пыхопроверка на пустоту?
В «Lua» противоположная крайность: оператор if считает, что любое выражение эквивалентно true, если оно не nil и не false. Т. е. в «Lua» даже if(0) эквивалентно if(true) и if('') эквивалентно if(true).
Именно поэтому я за «explicit is better than implicit».
Научился, проверь
Хотя, ньюфаги и в этот ноль не могут.
это goatse?
Казалось бы, как это связанно с псевдонимом Михаилом Круга?
Ноль это Фёдор Чистяков:"Музыка драчёвых напильников", "Пушки - в зад!" вот это всё
волос
скрыль
питуш
bash