Нет сам интерпретатор не может решить проблему, т.к. это на уровне правил языка - если где-то указывается тип, то он должен быть либо параметром, либо определён выше.
за счет вращения Земли получаются даровые 0,3 км/с, а чтобы вывести на полярную, сначала вы должны их наоборот погасить, а потом доложить столько же своих в другую сторону
Вот эти даровые 0,3 км/с и нужно закрыть. Ракета же не будет запускаться сперва строго на запад с погашением вращения Земли, потом разворачиваться на полярную орбиту. Нужна величина векторной суммы 7,8 км/с на наклонении 97° и 0,3 км/с на запад в сравнении с векторной суммой 7,8 км/с на восток и 0,3 км/с на запад.
Так и не пойму, можно ли трюк Норвига с заменой `(symbol-function fn-name)` провернуть где-то кроме CL и основанных на нём вариантов. При наличии исходного текста функции макрос выглядит как более переносимое решение всё-таки, да. Хотя по сути это точно функция - отображение входного аргумента в возвращаемое значение.
У Норвига в PAIP сделано функциями. Там как-то проще, чем через макросы, в том смысле, что о просачивании символов в другую область видимости не надо заботиться.
(defun memo (fn name key test)
"Return a memo-function of fn"
(let ((table (make-hash-table :test test)))
(setf (get name 'memo) table)
#'(lambda (&rest args)
(let ((k (funcall key args)))
(multiple-value-bind (val found-p)
(gethash k table)
(if found-p
val
(setf (gethash k table) (apply fn args))))))))
(defun memoize (fn-name &key (key #'first) (test #'eql))
"Replace fn-name's global definition with a memoized version"
(setf (symbol-function fn-name)
(memo (symbol-function fn-name) fn-name key test)))
У макроса есть какое-то существенное преимущество?
Как я понимаю, getd - это функция из HomeLisp'а, которая возвращает исходный код функции? В Common Lisp такого нет, вроде бы.
В 1945 году, в одном из лучших совхозов Омской области «Лесном», с площади посевов озимой пшеницы в 91 га, посеянной по всем правилам, рекомендованным акад. Лысенко, собрали всего 6 ц, зерна, то есть в среднем по 7 кг с гектара... Наконец, в прошлом 1946 году, в том же Сибирском научно-исследовательском институте, которым руководит акад. Лысенко, из 150 [га] стерневых посевов было запахано 112 га, так как на них родился один бурьян.
Функция x*ln(x) около нуля ведёт себя вроде бы нормально, в бесконечности не уходит.
Не уходит, но у неё, как и у квадратного корня, в нуле экстремум с бесконечной производной, поэтому нужно как-то делать, чтобы оптимизация в область притяжения этого экстремума не заходила.
если f(x) дважды дифференцируема, то липшицева непрерывность гарантируется.
Если всюду дважды дифференцируема — возможно, да. А так есть, например, квадратный корень, который в окрестности нуля не липшиц-непрерывен. У меня вот лично в решаемой задаче появляется функция, которая около нуля ведёт себя как x ln(x) — если туда минимизатор залез, то уже не вылезает.
Недавно ещё узнал, что есть немонотонный поиск по направлению, где условия Вульфа выполняются только "в среднем за n итераций", что может для CG или L-BFGS ускорить сходимость (спрямляет путь через кривые овраги).
Автор вот пишет, что посмотрел Scratch — и решил, что Basic лучше.
Я тоже не понимаю, почему — там и набор спрайтов из коробки, и игры кто-то на нём вполне пишет.
Подозреваю, это собственный синдром утёнка у автора, а ребёнка, очевидно, никто не спрашивал.
«Список кошек» — это частный случай «списка животных», в список животных можно занести кошку, а в список кошек занести любое животное (например, собаку) нельзя.
Тут вы сами себе противоречите. Правильно было бы "элемент, доставаемый из списка кошек, будет животным, а вот гарантировать, что из списка животных мы всегда будем получать именно кошек, нельзя".
В этом противоречии собака-то и зарыта. IEnumerable<T> — это функция int -> T (получить элемент по индексу), с одной стороны, и функция (int, T) -> IEnumerable<T> (записать элемент типа T по индексу), с другой. Т.е. это функция и принимающая, и возвращающая T.
Решить весь SICP и систематизировать свой опыт — огромный труд, поклон вам!
Как по-вашему, нужна ли первокурсникам реально часть относительно интерпретации?
Когда начинается написание интерпретатора — понятно, зачем брать один из Лиспов — выражения распарсить легко. То, что идёт до этого — как мне показалось, достаточно неплохо переносится практически на любой язык с динамической типизацией (кроме потоков языка для изображений, но они, как я понимаю, не входят даже в стандарт Scheme) и уже даёт неплохой фундамент для типичных студенческих задач. Написать интерпретатор на основе изученного — это красиво, конечно (eval-apply как электричество и магнетизм в уравнениях Максвелла), но не такое уж CS 101.
По итогу решения всех задач, использование списков в тех местах, где можно было бы сделать структуры с именованными полями, вам видится как полезный дидактический ход или введение затруднений на пустом месте? С одной стороны, понятно, что авторы хотят донести идею, что любые данные в конечном счёте можно построить на одной примитивной структуре (пусть в реальности это байт, а не список). С другой стороны, всякие cadadr для доступа к частям структуры не столь самоочевидны, как они подаются.
Сомнения — это хорошо.
Проблема в том, что основная информация по безопасности всех вакцин с течением времени существенно уже не поменяется.
Начальница, между прочим, могла вообще случайно в тот же день подхватить грипп или даже ковид, иммунитет-то после прививки ещё минимум неделю формируется.
Так что прекращайте этот FUD, берите жену за руку, делайте глубокий вдох и ведите в прививочный кабинет.
На одной чаше весов — не вакцинироваться и перенести инфекцию (то, что я заражусь в этом случае, вероятность почти 100% с учетом новых более заразных штамов).
Для тех, кто думает, что такие утверждения голословны — просто из соображений того, что для остановки эпидемии требуется, по разным оценкам, от 30 до 60 процентов иммунизованных, простой вывод — до конца пандемии без прививки вероятность перенести инфекцию составляет от 30 до 60 процентов. Плюс для непривитых остаётся вероятность заболеть уже после окончания пандемии.
Отложенные эффекты от конкретных вакцин неизвестны, но для похожих вакцин известно, что таких эффектов не наблюдалось.
Долговременные эффекты от перенесённого ковида… Частично известны, и они не очень приятные.
Вчера получил вторую прививку "Спутником". Кроме небольшой температуры, никаких больше побочек не было.
Вопрос в том, что хвост, про который вы говорите, появится сам собой, если под "0.1" считать "ближайшее к 0.1 число, представимое в двоичном формате с плавающей точкой".
В статье, на которую вы ссылаетесь, есть конкретная фраза:
The flip side of this question is figuring out how many decimal digits it takes to uniquely identify a float. Again, we aren’t concerned here with converting the exact value of the float to a decimal (we’ll get to that), but merely having enough digits to uniquely identify a particular float.
И далее выводится, что для одинарной точности "enough digits" — это 9 для худшего случая, для некоторых может быть меньше (для 0.5, например, хватает 2).
Теоретически, конечно, может потребоваться полное представление, но это только если число из строки читается в формат более высокой разрядности, чем тот, в котором строка была выведена — тогда могут, действительно, быть неоднозначности (ближайшее к 0.1 число в одинарной точности не то же самое, что в двойной). Но если выводить тупо 16 десятичных цифр, то это проявляется при чтении в четверную точность или выше, что крайне редко на практике.
Для класса «инженерных» задач эта идея – использовать как систему типов Международную систему единиц СИ, всегда казалась мне очевидной и потенциально полезной, но почему-то нигде в современных распространенных языках не реализованной, за исключением некоторых возможностей в Matlab и Mathcad.
Имеет ли смысл использовать такое на практике? Думаю, что лучше не стоит.
Правильно думаете. NaN — это семейство значений с плавающей точкой, у которых экспонента состоит полностью из 1, а мантисса не состоит полностью из нулей. Поэтому nan как литерал не обязан быть по хэшу равен nan, полученному в ходе вычислений.
По теме статьи — вопрос дискуссионный, что считать наиболее правильным подходом. Как по мне, надо бы различать два случая:
1.0**nan должно быть nan, т.к. 1.0 обозначает лишь некоторое число между 1-eps/2 и 1+eps. В частности, (1 + 10**(-10))**nan — nan, но (float32(1 + 10**(-10)))**nan == 1 выглядит несколько абсурдно
1**nan (1 — целое число) вполне можно взять равным 1.0, т.к. целочисленный литерал тут обозначает точную единицу без какой-либо погрешности
Ещё большой плюс этих алгоритмов — они подходят для потоковых данных, когда чтение числа необратимо удаляет его из буфера.
Для массивов есть ещё вариант "дёшево и сердито", как сделано в языке Julia для суммирования по умолчанию — рекуррентное деление пополам, если длина стала 32 или меньше — наивное суммирование. Точность при этом обычно выше, чем просто при наивном последовательном суммировании, но при этом вычисления хорошо векторизуются, и по сравнению с последовательным суммированием точность практически не страдает.
Проблема фрагментации есть, но со свободным ПО хотя бы можно сделать свой мини-дистрибутив, включающий всё необходимое окружение.
И сам "движок" LaTeX, по-моему, довольно стабилен, проблемы в несовместимости пакетов друг с другом, а не с движком. В WYSIWYG редакторах поди разбери, поменялись в новой версии только интерфейс и набор фич из коробки, или ещё и движок рендера. В MS Office ещё часть настроек может сидеть в реестре — гораздо больше скрытого состояния.
Нет сам интерпретатор не может решить проблему, т.к. это на уровне правил языка - если где-то указывается тип, то он должен быть либо параметром, либо определён выше.
Вот эти даровые 0,3 км/с и нужно закрыть. Ракета же не будет запускаться сперва строго на запад с погашением вращения Земли, потом разворачиваться на полярную орбиту. Нужна величина векторной суммы 7,8 км/с на наклонении 97° и 0,3 км/с на запад в сравнении с векторной суммой 7,8 км/с на восток и 0,3 км/с на запад.
Спасибо, что добавили разъяснение в статью.
Так и не пойму, можно ли трюк Норвига с заменой `(symbol-function fn-name)` провернуть где-то кроме CL и основанных на нём вариантов. При наличии исходного текста функции макрос выглядит как более переносимое решение всё-таки, да. Хотя по сути это точно функция - отображение входного аргумента в возвращаемое значение.
У Норвига в PAIP сделано функциями. Там как-то проще, чем через макросы, в том смысле, что о просачивании символов в другую область видимости не надо заботиться.
У макроса есть какое-то существенное преимущество?
Как я понимаю,
getd- это функция из HomeLisp'а, которая возвращает исходный код функции? В Common Lisp такого нет, вроде бы.(https://ru.wikipedia.org/wiki/Лысенко,_Трофим_Денисович)
Скорее, очень хорошо умел читать запросы высокого руководства и подгонять результат под нужный ответ.
Не уходит, но у неё, как и у квадратного корня, в нуле экстремум с бесконечной производной, поэтому нужно как-то делать, чтобы оптимизация в область притяжения этого экстремума не заходила.
Да, похоже, что те же. У них и в статье про МСГ метод поиска вдоль направления предлагается, который и отдельно от МСГ тоже используют.
Если всюду дважды дифференцируема — возможно, да. А так есть, например, квадратный корень, который в окрестности нуля не липшиц-непрерывен. У меня вот лично в решаемой задаче появляется функция, которая около нуля ведёт себя как x ln(x) — если туда минимизатор залез, то уже не вылезает.
Недавно ещё узнал, что есть немонотонный поиск по направлению, где условия Вульфа выполняются только "в среднем за n итераций", что может для CG или L-BFGS ускорить сходимость (спрямляет путь через кривые овраги).
Автор вот пишет, что посмотрел Scratch — и решил, что Basic лучше.
Я тоже не понимаю, почему — там и набор спрайтов из коробки, и игры кто-то на нём вполне пишет.
Подозреваю, это собственный синдром утёнка у автора, а ребёнка, очевидно, никто не спрашивал.
Тут вы сами себе противоречите. Правильно было бы "элемент, доставаемый из списка кошек, будет животным, а вот гарантировать, что из списка животных мы всегда будем получать именно кошек, нельзя".
В этом противоречии собака-то и зарыта.
IEnumerable<T>— это функцияint -> T(получить элемент по индексу), с одной стороны, и функция(int, T) -> IEnumerable<T>(записать элемент типаTпо индексу), с другой. Т.е. это функция и принимающая, и возвращающаяT.Решить весь SICP и систематизировать свой опыт — огромный труд, поклон вам!
Как по-вашему, нужна ли первокурсникам реально часть относительно интерпретации?
Когда начинается написание интерпретатора — понятно, зачем брать один из Лиспов — выражения распарсить легко. То, что идёт до этого — как мне показалось, достаточно неплохо переносится практически на любой язык с динамической типизацией (кроме потоков языка для изображений, но они, как я понимаю, не входят даже в стандарт Scheme) и уже даёт неплохой фундамент для типичных студенческих задач. Написать интерпретатор на основе изученного — это красиво, конечно (eval-apply как электричество и магнетизм в уравнениях Максвелла), но не такое уж CS 101.
По итогу решения всех задач, использование списков в тех местах, где можно было бы сделать структуры с именованными полями, вам видится как полезный дидактический ход или введение затруднений на пустом месте? С одной стороны, понятно, что авторы хотят донести идею, что любые данные в конечном счёте можно построить на одной примитивной структуре (пусть в реальности это байт, а не список). С другой стороны, всякие
cadadrдля доступа к частям структуры не столь самоочевидны, как они подаются.Так что нещитается
Сомнения — это хорошо.
Проблема в том, что основная информация по безопасности всех вакцин с течением времени существенно уже не поменяется.
Начальница, между прочим, могла вообще случайно в тот же день подхватить грипп или даже ковид, иммунитет-то после прививки ещё минимум неделю формируется.
Так что прекращайте этот FUD, берите жену за руку, делайте глубокий вдох и ведите в прививочный кабинет.
Для тех, кто думает, что такие утверждения голословны — просто из соображений того, что для остановки эпидемии требуется, по разным оценкам, от 30 до 60 процентов иммунизованных, простой вывод — до конца пандемии без прививки вероятность перенести инфекцию составляет от 30 до 60 процентов. Плюс для непривитых остаётся вероятность заболеть уже после окончания пандемии.
Отложенные эффекты от конкретных вакцин неизвестны, но для похожих вакцин известно, что таких эффектов не наблюдалось.
Долговременные эффекты от перенесённого ковида… Частично известны, и они не очень приятные.
Вчера получил вторую прививку "Спутником". Кроме небольшой температуры, никаких больше побочек не было.
Вопрос в том, что хвост, про который вы говорите, появится сам собой, если под "0.1" считать "ближайшее к 0.1 число, представимое в двоичном формате с плавающей точкой".
В статье, на которую вы ссылаетесь, есть конкретная фраза:
И далее выводится, что для одинарной точности "enough digits" — это 9 для худшего случая, для некоторых может быть меньше (для 0.5, например, хватает 2).
Теоретически, конечно, может потребоваться полное представление, но это только если число из строки читается в формат более высокой разрядности, чем тот, в котором строка была выведена — тогда могут, действительно, быть неоднозначности (ближайшее к 0.1 число в одинарной точности не то же самое, что в двойной). Но если выводить тупо 16 десятичных цифр, то это проявляется при чтении в четверную точность или выше, что крайне редко на практике.
Вот не надо путать читателей, называя десятичное представление с фиксированной точкой "точным".
Ну так-то есть библиотеки для C++, для Python, для Julia.
Правильно думаете. NaN — это семейство значений с плавающей точкой, у которых экспонента состоит полностью из 1, а мантисса не состоит полностью из нулей. Поэтому
nanкак литерал не обязан быть по хэшу равенnan, полученному в ходе вычислений.По теме статьи — вопрос дискуссионный, что считать наиболее правильным подходом. Как по мне, надо бы различать два случая:
1.0**nanдолжно бытьnan, т.к. 1.0 обозначает лишь некоторое число между 1-eps/2 и 1+eps. В частности,(1 + 10**(-10))**nan—nan, но(float32(1 + 10**(-10)))**nan == 1выглядит несколько абсурдно1**nan(1 — целое число) вполне можно взять равным 1.0, т.к. целочисленный литерал тут обозначает точную единицу без какой-либо погрешностиЕщё большой плюс этих алгоритмов — они подходят для потоковых данных, когда чтение числа необратимо удаляет его из буфера.
Для массивов есть ещё вариант "дёшево и сердито", как сделано в языке Julia для суммирования по умолчанию — рекуррентное деление пополам, если длина стала 32 или меньше — наивное суммирование. Точность при этом обычно выше, чем просто при наивном последовательном суммировании, но при этом вычисления хорошо векторизуются, и по сравнению с последовательным суммированием точность практически не страдает.
Да не такая уж и ирония.
Проблема фрагментации есть, но со свободным ПО хотя бы можно сделать свой мини-дистрибутив, включающий всё необходимое окружение.
И сам "движок" LaTeX, по-моему, довольно стабилен, проблемы в несовместимости пакетов друг с другом, а не с движком. В WYSIWYG редакторах поди разбери, поменялись в новой версии только интерфейс и набор фич из коробки, или ещё и движок рендера. В MS Office ещё часть настроек может сидеть в реестре — гораздо больше скрытого состояния.