Простите за занудство, но без вероятностного пространства с метрикой говорить о вероятности встретить динозавра бессмысленно, сколько бы экспериментов мы не проводили.
Аргумент о множественных экспериметах (стат. устойчивость, ЗБЧ и пр.) работает только при предположении о равнораспределенности и независимости результатов отдельных опытов. В прочих условиях этот аргумент тоже не работает.
C'est la vie.
Роман очень прикольно читает лекции.
Однажды он пришел в маске и начал рассказывать про ниндзя и про то, что над делать то, что качает.
Жалко только, что и 20% материала не понимаю вообще.
Всё-таки есть разница между индикаторами в виде полоски с процентами и нынешними циклическими.
Первые предполагают однонаправленность процесса: полоска никогда не вернётся в более раннее состояние и любое изменение для пользователя означает «процесс идёт», что успокаивает. Гаррисон верно задаёт вопрос: не столько информация интересует пользователя, сколько факт того, что процесс идёт и бояться нечего.
Нынешние же популярные циклические индикаторы не говорят ровном счетом ничего: глядя на них, нельзя сказать, на каком этапе находится процесс. Более того, создаётся психологическое ощущение, что процесс может и не завершиться никогда, раз индикатор раз за разом приходит в одно и то же состояние. Как пользователю узнать, что всё в порядке и ничего не зависло, если индикатор как зацикленный то и дело циклично меняется?
Я, когда вижу такой вот циклический индикатор, первым делом проверяю, всё ли в порядке с интернет-подключением, не тормозит ли ноут, нет ли чего-то ещё плохого, потому что в ином случае индикатор обычно не появляется. Чувствуете, что индикатор делает в точности обратную задачу по сравнению с предшественником?
хаскель можно отнести к классу java, поскольку эффективность программы определяется оптимизацией при компиляции и сложная абстрактная программа будет медлнее аналогичной на С.
и это печально, и безысходно.
да, об этом (определения Bool, [], кортежей) тоже стоит упомянуть.
Если под базовостью понимать вхождение в Прелюдию, то стоит упомянуть о Maybe, Ordering и др. Впрочем, автор согласился, что у него только поверхностно описываются «базовые» типы, чем я удовлетворён.
К слову, сказано, что любой тип данных и функция из Прелюдии может быть описана в терминах языка (как Bool или Maybe) или псевдокода (как списки или кортежи) и реализована непредопределённым образом для каждой реализации компилятора, допуская как реализацию напрямую, как написано, так и по собственному разумению.
То есть тот набор типов, которые реализованы отдельно (по Вашим словам) некими примитивами, не определён стандартом, а определяется каждой конкретной реализацией. Этот набор может не ограничиваться Int и Char.
В этой статье используется очень прагматичный подход к ознакомлению, которые не затрагивает ряд догматичных аспектов языка.
Например, говорится, что к базовым типам относятся Числа, Логические величины, Символы, Списки, Упорядоченные множества (tuples) и Функции. По какому признаку одни типы относятся к базовым, а другие — нет? Возможные видимые варианты ответа:
1. как языковая элементарная конструкция, без которой язык ущербен? С самого начала, даже в официальном описании языка, подчёркивается, что многие типы из Prelude могут быть описаны натуральными средствами языка, например, data Bool = True | False, или data Char = 'a' | 'b' | ... Многие типы из приведённых допускают альтернативное описание. С другой же стороны, IO не может быть описан средствами языка, хотя в списке базовых типов не значится.
2. как реализуемые особым образом типы? Например, список — участок памяти, Bool — всем привычный bool, Int — всем привычный 4-байтный int. Если так, то почему сюда не включен IO? Да и зачем в языке столь высокого уровня с первых шагов акцентировать внимание на такой конкретике.
3. как типы сорта * в противопоставление типам сорта * -> * или более сложных сортов? Да, Int :: *, Char :: *, Bool :: *, но [] :: * -> * уже не подходит.
Так почему именно эти типы были названы базовыми?
Кроме этого момента есть ещё некоторые минусы, вроде смешивание рассказа о языке и о ghci, скачки от одной темы к другой, отсутствие единой линии (плана) повествования, малое число примеров, демонстрирующих объясняющие слова.
Я не знаю, на кого рассчитана статья. И несмотря на это, хорошо, что появляются новые туториалы по языку. Продолжение не будет лишним, но мне кажется, что лучше собрать уже имеющуюся русскоязычную литературу и опираться на неё во избежание повторения уже написанного и изложенного, но ради дополнения.
У Вас интересная модель в том смысле, что даёт какие-то наглядные результаты, но очень уж много независимых параметров.
Идея рассматривать случайные графы здесь видится существенным упрощением. Модель Эрдёша и Реньи не является яркой, тем более, как Вы заметили, не описывает динамику. Есть и другие модели. Например, модель Барабаши и Альберта описывает построение френдов, когда человек основывается только на уже написанное и не меняет своих френдов во времени, хотя выбирает френдов исходя из их популярности (знаком эффект, да?). Есть близкая модель, насколько я помню, имени Прайса, когда число френдов не фиксировано, случайно, но имеет фиксированный закон распределения.
Есть ещё одна модель — модель Уатса и Строгаца — в которой описывается «rewiring», случайная перелинковка френдов, как в Вашей модели, но с меншим числом параметров.
Модели двух типов (статичное приписывание френдов и «rewiring») можно комбинировать.
Подробнее смотрите англ. википедию
Конечно, это не так мощно и универсально, как в приведенной в статье модели, но типичные эффекты демонстрируются. Основной профит — малое число параметров, которые можно менять все наглядным образом.
Это справедливо для всех лямбда-систем, в которых можно f x = g x (любой x) эквивалентно f = g (это свойство называется экстенсиональностью, само по себе эквивалентно наличию эта-редукции наровне с привычной бета-редукцией).
Все вышеописанное работает, если кривая достаточно гладкая, а колесико небольшое. Если колесико будет сравнимо по величине с самой кривой, то приведенный выше вывод уже не годится.
Это не точное описание условия.
Правильнее сказать так: радиус кривизны кривой ни в какой точке не должен быть меньше радиуса катящейся окружности.
Иначе на трассе будут области, физически недостижимые.
В примере с квадратом, особыми точками являются углы, в которых кривизна бесконечно малая.
В приведённой модели происходит следующее: окружность докатывается до угла, пересекая перпендикулярную стенку, и затем, не меняя точки касания (вершина угола), телепортируется таким образом, чтобы касаться другой стороны.
Поскольку угол физически недостижим, для правильного результата следует удалить отрезки длины r при каждом угле с каждой стороны. Трасса станет разрывной, но зато движение центра колёсика будет непрерывным.
ЗЫ за статью спасибо, приятно посмотреть на эти, как в статье сказано, «няшные» кривые.
Так вот, слова о том, что компилятор и статическая типизации сильно помогают кому-то от ошибок, вызывают лишь недоумение.
Не скажу, что как статическая типизация отражается на эффективности написания кода без ошибок, но как не крути, нетипизированный язык синтаксически более свободный, но семантически менее очевидный. Это означает не более чем то, что программист имеет большую свободу в том, что и как писать, но сложнее понимать, что хотел сказать программист тут или там.
Представьте себе какую-нибудь нетривиальную программу, например, просто вызов метода с аргументом: f(x). Если типизации нет, то и выжать из этого кода ничего больше нельзя. Если же имеется типизиция, то это о многом говорит. Скажем, если f : Int -> Int и x : Int и уже понятно, что функция целочисленная, а аргумент — число.
Другой вариант: generic-функция f : List<T> -> List<T>, в этом случае читатель может сразу заключить, что поскольку функции не важен тип элементов списка-аргумента, то она и не опирается на значения отдельных элементов, манипулируя ими как абстрактными единицами данных, указателями, если хотите. Тогда можно предположить, например, что f(map(m, x)) делает то же, что и map(m, f(x)), где m : T -> T есть функция любого конкретного типа T или generic, модифицирующая отдельный элемент списка, а map поднимает модификацию до всего списка, аналог Select в C#. Такого нетривиального умозаключения нельзя сделать для нетипизированного языка, потому что там никогда не понятно, на что опирается функция, а на что нет.
Не заглядывая в спецификацию, нельзя сказать, что функция делает; но глядя на тип, можно сказать, что функция не делает. Читателю это помощь, компилятору — подсказка, IDE — пояснение, что может желать программист. Программист же получает, помощь со стороны IDE, настраивает дружеские взаимоотношения с компилятором и будущим читателем. Кроме того, сразу отсекаются те ошибки, причина которых лежит в неправильном изложении мысли человека на используемом ЯП; другие ошибки по-прежнему останутся. Это в теории; на практике, как известно, бывает по-другому.
Вы не очень удачный пример подобрали, хотя и интересный.
Любая неквантовая система эволюционирует по собственному закону, которое можно выразить некоторым дифф. уравнением. На малых временных масштабах дифф. уравнение решается точно, если дано точное исходное состояние. Стало быть всё, всякий ГСЧ на таких системах будет опирать только на то, что исходное состояние нам не известно. Для хаотических систем это работает, хотя опять же на малых масштабах по времени будет наблюдаться детерменизм.
Вы правильно сказали: «Его положение в пространстве невозможно предсказать на сколь-нибудь длинный (по астрономическим меркам) промежуток времени».
Однако даже системное время в мс (или даже просто в секундах) можно использовать для генерации СЧ в небольшом диапазоне, если это требуется, скажем, раз в сутки/неделю/месяц. Опять же, это вопрос о масштабах, в нашем мире нет ни одной полностью детерминированной системы.
Автор статьи же ставит вопрос о том, что делать, если генерировать нужно много и сразу. Можно ли использовать предложенные Вами методы для генерации 100500+ СЧ в ед. времени? Не получится.
Квантовые генераторы — это другой уровень. При измерении физ. величины состояние коллапсирует в собственное состояние физ. величины вероятностно, притом эти вероятности определяются квадратом модуля коэффициентов разложения состояния по базису из собственных состояний физ. величины.
Случайность является истинной, неподдельной, поэтому всё как бы хорошо. Но там могут возникнуть проблемы, связанные с эволюцией состояния во времени: нестационарное состояние будет меняться во времени детерминированным образом вплоть до следующего измерения, однако может понадобиться некоторое время для того, чтоб отойти от собственного состояний физ.величины, которое было получено при предыдущем измерении.
Но эти порядки совершенно другие, нам столько информации сразу не нужно.
Да, пожалуй неточно выразил мысль. Действительно, если будет найдена любая (в частности, эффективная) стратегия поиска, то решение существует. Однако по своему качеству задачи «определить, есть ли решение» и «за кратчайшее время определить решение» существенно разные. Как правило, необходимость ответить на первый вопрос встаёт сразу, как формулируется проблема. Это своеобразный билет на корректность. Если ответ положительный, то второй вопрос корректен, посему уже тогда имеет смысл пытаться его решить.
К слову говоря, нам, бывает, не столь принципиально получить именно правильный ответ. Например, если стоит задача найти волновую функцию основного состояния атома водора, мы вполне можем считать ядро неподвижным, что, вообще говоря, не совсем так, но нас удовлетворяет. Часто, наша цель не решить точно поставленное уравнение или что-то такое, а найти примерно решение реальной задачи, опираясь на уравнение модели-идеализации.
Опять же, разные бывают задачи. Какие-то просто необходимо уметь решать с любой наперед заданной точностью, другие — нет. И здесь мы первый вопрос задаём «а есть ли решение вообще», а потом уже, по острой надобности, «как найти решение» и «как найти его оптимально».
P.S. основная мысль первого сообщения заключалась в том, что математика ставит немного другие задачи перед собой, за что её нельзя винить. Вопросами поиска оптимальных стратегий занимаются некоторые её разделы, которые следует, по возможности, знать каждому программисту.
P.P.S. что ж за наваждение такое-то: я ответил на сообщение Monnoroch, который ответил на мое сообщение выше. Не судите строго за нарушение иерархии сообщений )
Проблема существования решения и наличия эффективной стратегии поиска решения — две разные, практически слабокоррелирующие задачи.
Во-первых, не всегда существование решения означает принципиальную возможность его получить.
Принципиальные проблемы начинаются, если допускаются принципы по типу двойного отрицания. Для примера: можно показать, что для любого утверждения F существует такое число x, которое равно единице, если F истинно, и нулю в противном случае; кроме того, можно F выбрать таким образом, что x существует, но значение мы принципиально посчитать не можем. Избитый пример F=«числовая прямая R суть меншее по мощности из несчётных множеств».
Как следствие, мы можем говорить, в частности, что существует решение уравнения 100500-й степени, даже сами не зная, как его получить. А иногда не знаем не потому, что ещё метод не придумали, а потому что принципиально не можем знать (см. пример выше)
К счастью, эту проблему можно исключить, но для этого нужно отказаться от таких уютных принципов, как доказательство от противного и иже с ними. Примером такой неклассической теории служит конструктивизм, где утверждение «существует x, что ...» означает «уже описан алгоритм для нахождения x, что ...».
Автор статьи ставит более приземлённый вопрос: всегда ли алгоритм по нахождению решения, если он существует и где-то описан, является оптимальным. Этот вопрос в математической практике также возникал не раз. В некоторых теориях были построены алгоритмы генерации эффективных алгоритмов по образцу.
Математика не ставит цель решить задачу «оптимальным» доказательством, её цель — уменьшить размер доказательства и сделать его интуитивно понятным.
Во время чтения статьи меня не отпускало чувство, что статья посвящена некоторым аспектам функционального программирования (возможно, с типами).
Серьёзно:
Сначала объясняется важность интерфейсов, мол, алгоритмы должны быть абстрагированы по-максимуму, поэтому используем интерфейсы вместо конкретных реализаций, классов.
Потом четко выделяется мысль «у функции не должно быть скрытого аргумента this, все аргументы равноправны».
Потом доказывается, что работать с неизменяемыми типами удобнее, чем с теми, которые имеют своё внутреннее состояние.
Автор как-бы подводит нас к замечательной мысли: не стоит нагружать объект лишним сложноконтролируемым поведением. Гораздо приятнее использовать неизменяемые типы данных, фабрики для их генерации и функции, свободные от this, для обработки.
Если тип назвать «характеристикой» терма, кайнд (kind) — типа, то «характеристикой» kind будет нечто, что [в частности] Барендрегт называет sort, например, в «Introduction to generalised type systems».
Да и в речи «тип терма, вид типа, сорт вида» звучит приемлемо.
Впрочем, если в русской литература используется перевод «сорт», то следует использовать именно его, как бы непривычно это не звучало. Нужно использовать единообразные обозначения.
Я в целом согласен с Вами, но считаю, что пример с переулком не очень выразителен. Так как нельзя нападасть на того, кого не видишь, я бы предпочел идти в абсолютной темноте без (без!) всякого риска, чем идти (пусть оглядываясь с автоматом в руках), опасаясь каждого вздоха за плечом
Концепция нудистского пляжа, я считаю, самая диеспособная (поскольку общество формирует мораль и требует её исполнения, поддерживая тем самым порядок — эта схема действовала всегда в той или иной форме)
Статейка доставила удовольствие… понастольгировать. В детстве, помню, меня очень увлекало разнообразие и красочность непозиционных систем. Была энциклопедия толстенькая, называлась вроде «Аванта. Математика» (где-то 2000г.), там с картинками рассказывалось и про египетскую, и про шумерску, и, что меня особо впечатлило, про систему племени (кажется) майя. Последняя вроде и не позиционная, но, с другой стороны, смешанная (если не изменяет память, майя использовали точки и горизонтальные черточки, записанный друг под другом, черточка значила 5, точка — 1, таким образом число представлялось такой себе колонкой вертикальной; нижний разряд значил от 0 до 20, второй значил от 0 до 18 умножить на 20, третий разряд — от 0 до 20 умножить на 20*18; в то время как все народы Евразии использовали только 1-10-100-1000-… и 1-60-3600-… у Шумеров, то есть степени одного числа, майя использовали смешанно 20 и 18 в качестве основы)
Хорошая была книга, для детей в самый раз, не сложно, без каких-либо формул.
Аргумент о множественных экспериметах (стат. устойчивость, ЗБЧ и пр.) работает только при предположении о равнораспределенности и независимости результатов отдельных опытов. В прочих условиях этот аргумент тоже не работает.
C'est la vie.
Однажды он пришел в маске и начал рассказывать про ниндзя и про то, что над делать то, что качает.
Жалко только, что и 20% материала не понимаю вообще.
Это не терм, это операция подстановки, которая повляется при применении β-редукции к терму
f v wв такой вот обобщенной форме записи.P.S. по-моему, статья написана легким для восприятия языком; читать приятно.
Первые предполагают однонаправленность процесса: полоска никогда не вернётся в более раннее состояние и любое изменение для пользователя означает «процесс идёт», что успокаивает. Гаррисон верно задаёт вопрос: не столько информация интересует пользователя, сколько факт того, что процесс идёт и бояться нечего.
Нынешние же популярные циклические индикаторы не говорят ровном счетом ничего: глядя на них, нельзя сказать, на каком этапе находится процесс. Более того, создаётся психологическое ощущение, что процесс может и не завершиться никогда, раз индикатор раз за разом приходит в одно и то же состояние. Как пользователю узнать, что всё в порядке и ничего не зависло, если индикатор как зацикленный то и дело циклично меняется?
Я, когда вижу такой вот циклический индикатор, первым делом проверяю, всё ли в порядке с интернет-подключением, не тормозит ли ноут, нет ли чего-то ещё плохого, потому что в ином случае индикатор обычно не появляется. Чувствуете, что индикатор делает в точности обратную задачу по сравнению с предшественником?
и это печально, и безысходно.
Если под базовостью понимать вхождение в Прелюдию, то стоит упомянуть о Maybe, Ordering и др. Впрочем, автор согласился, что у него только поверхностно описываются «базовые» типы, чем я удовлетворён.
К слову, сказано, что любой тип данных и функция из Прелюдии может быть описана в терминах языка (как Bool или Maybe) или псевдокода (как списки или кортежи) и реализована непредопределённым образом для каждой реализации компилятора, допуская как реализацию напрямую, как написано, так и по собственному разумению.
То есть тот набор типов, которые реализованы отдельно (по Вашим словам) некими примитивами, не определён стандартом, а определяется каждой конкретной реализацией. Этот набор может не ограничиваться Int и Char.
Например, говорится, что к базовым типам относятся Числа, Логические величины, Символы, Списки, Упорядоченные множества (tuples) и Функции. По какому признаку одни типы относятся к базовым, а другие — нет? Возможные видимые варианты ответа:
1. как языковая элементарная конструкция, без которой язык ущербен? С самого начала, даже в официальном описании языка, подчёркивается, что многие типы из Prelude могут быть описаны натуральными средствами языка, например,
data Bool = True | False, илиdata Char = 'a' | 'b' | ...Многие типы из приведённых допускают альтернативное описание. С другой же стороны, IO не может быть описан средствами языка, хотя в списке базовых типов не значится.2. как реализуемые особым образом типы? Например, список — участок памяти, Bool — всем привычный bool, Int — всем привычный 4-байтный int. Если так, то почему сюда не включен IO? Да и зачем в языке столь высокого уровня с первых шагов акцентировать внимание на такой конкретике.
3. как типы сорта * в противопоставление типам сорта
* -> *или более сложных сортов? Да,Int :: *,Char :: *,Bool :: *, но[] :: * -> *уже не подходит.Так почему именно эти типы были названы базовыми?
Кроме этого момента есть ещё некоторые минусы, вроде смешивание рассказа о языке и о ghci, скачки от одной темы к другой, отсутствие единой линии (плана) повествования, малое число примеров, демонстрирующих объясняющие слова.
Я не знаю, на кого рассчитана статья. И несмотря на это, хорошо, что появляются новые туториалы по языку. Продолжение не будет лишним, но мне кажется, что лучше собрать уже имеющуюся русскоязычную литературу и опираться на неё во избежание повторения уже написанного и изложенного, но ради дополнения.
Идея рассматривать случайные графы здесь видится существенным упрощением. Модель Эрдёша и Реньи не является яркой, тем более, как Вы заметили, не описывает динамику. Есть и другие модели. Например, модель Барабаши и Альберта описывает построение френдов, когда человек основывается только на уже написанное и не меняет своих френдов во времени, хотя выбирает френдов исходя из их популярности (знаком эффект, да?). Есть близкая модель, насколько я помню, имени Прайса, когда число френдов не фиксировано, случайно, но имеет фиксированный закон распределения.
Есть ещё одна модель — модель Уатса и Строгаца — в которой описывается «rewiring», случайная перелинковка френдов, как в Вашей модели, но с меншим числом параметров.
Модели двух типов (статичное приписывание френдов и «rewiring») можно комбинировать.
Подробнее смотрите англ. википедию
Конечно, это не так мощно и универсально, как в приведенной в статье модели, но типичные эффекты демонстрируются. Основной профит — малое число параметров, которые можно менять все наглядным образом.
Это справедливо для всех лямбда-систем, в которых можно
f x = g x(любой x) эквивалентноf = g(это свойство называется экстенсиональностью, само по себе эквивалентно наличию эта-редукции наровне с привычной бета-редукцией).а улыбать — ниразу не видел.
ведь понятно, что автор хотел сказать.
Это не точное описание условия.
Правильнее сказать так: радиус кривизны кривой ни в какой точке не должен быть меньше радиуса катящейся окружности.
Иначе на трассе будут области, физически недостижимые.
В примере с квадратом, особыми точками являются углы, в которых кривизна бесконечно малая.
В приведённой модели происходит следующее: окружность докатывается до угла, пересекая перпендикулярную стенку, и затем, не меняя точки касания (вершина угола), телепортируется таким образом, чтобы касаться другой стороны.
Поскольку угол физически недостижим, для правильного результата следует удалить отрезки длины r при каждом угле с каждой стороны. Трасса станет разрывной, но зато движение центра колёсика будет непрерывным.
ЗЫ за статью спасибо, приятно посмотреть на эти, как в статье сказано, «няшные» кривые.
Не скажу, что как статическая типизация отражается на эффективности написания кода без ошибок, но как не крути, нетипизированный язык синтаксически более свободный, но семантически менее очевидный. Это означает не более чем то, что программист имеет большую свободу в том, что и как писать, но сложнее понимать, что хотел сказать программист тут или там.
Представьте себе какую-нибудь нетривиальную программу, например, просто вызов метода с аргументом:
f(x). Если типизации нет, то и выжать из этого кода ничего больше нельзя. Если же имеется типизиция, то это о многом говорит. Скажем, еслиf : Int -> Intиx : Intи уже понятно, что функция целочисленная, а аргумент — число.Другой вариант: generic-функция
f : List<T> -> List<T>, в этом случае читатель может сразу заключить, что поскольку функции не важен тип элементов списка-аргумента, то она и не опирается на значения отдельных элементов, манипулируя ими как абстрактными единицами данных, указателями, если хотите. Тогда можно предположить, например, чтоf(map(m, x))делает то же, что иmap(m, f(x)),гдеm : T -> Tесть функция любого конкретного типа T или generic, модифицирующая отдельный элемент списка, а map поднимает модификацию до всего списка, аналог Select в C#. Такого нетривиального умозаключения нельзя сделать для нетипизированного языка, потому что там никогда не понятно, на что опирается функция, а на что нет.Не заглядывая в спецификацию, нельзя сказать, что функция делает; но глядя на тип, можно сказать, что функция не делает. Читателю это помощь, компилятору — подсказка, IDE — пояснение, что может желать программист. Программист же получает, помощь со стороны IDE, настраивает дружеские взаимоотношения с компилятором и будущим читателем. Кроме того, сразу отсекаются те ошибки, причина которых лежит в неправильном изложении мысли человека на используемом ЯП; другие ошибки по-прежнему останутся. Это в теории; на практике, как известно, бывает по-другому.
Любая неквантовая система эволюционирует по собственному закону, которое можно выразить некоторым дифф. уравнением. На малых временных масштабах дифф. уравнение решается точно, если дано точное исходное состояние. Стало быть всё, всякий ГСЧ на таких системах будет опирать только на то, что исходное состояние нам не известно. Для хаотических систем это работает, хотя опять же на малых масштабах по времени будет наблюдаться детерменизм.
Вы правильно сказали: «Его положение в пространстве невозможно предсказать на сколь-нибудь длинный (по астрономическим меркам) промежуток времени».
Однако даже системное время в мс (или даже просто в секундах) можно использовать для генерации СЧ в небольшом диапазоне, если это требуется, скажем, раз в сутки/неделю/месяц. Опять же, это вопрос о масштабах, в нашем мире нет ни одной полностью детерминированной системы.
Автор статьи же ставит вопрос о том, что делать, если генерировать нужно много и сразу. Можно ли использовать предложенные Вами методы для генерации 100500+ СЧ в ед. времени? Не получится.
Квантовые генераторы — это другой уровень. При измерении физ. величины состояние коллапсирует в собственное состояние физ. величины вероятностно, притом эти вероятности определяются квадратом модуля коэффициентов разложения состояния по базису из собственных состояний физ. величины.
Случайность является истинной, неподдельной, поэтому всё как бы хорошо. Но там могут возникнуть проблемы, связанные с эволюцией состояния во времени: нестационарное состояние будет меняться во времени детерминированным образом вплоть до следующего измерения, однако может понадобиться некоторое время для того, чтоб отойти от собственного состояний физ.величины, которое было получено при предыдущем измерении.
Но эти порядки совершенно другие, нам столько информации сразу не нужно.
К слову говоря, нам, бывает, не столь принципиально получить именно правильный ответ. Например, если стоит задача найти волновую функцию основного состояния атома водора, мы вполне можем считать ядро неподвижным, что, вообще говоря, не совсем так, но нас удовлетворяет. Часто, наша цель не решить точно поставленное уравнение или что-то такое, а найти примерно решение реальной задачи, опираясь на уравнение модели-идеализации.
Опять же, разные бывают задачи. Какие-то просто необходимо уметь решать с любой наперед заданной точностью, другие — нет. И здесь мы первый вопрос задаём «а есть ли решение вообще», а потом уже, по острой надобности, «как найти решение» и «как найти его оптимально».
P.S. основная мысль первого сообщения заключалась в том, что математика ставит немного другие задачи перед собой, за что её нельзя винить. Вопросами поиска оптимальных стратегий занимаются некоторые её разделы, которые следует, по возможности, знать каждому программисту.
P.P.S. что ж за наваждение такое-то: я ответил на сообщение Monnoroch, который ответил на мое сообщение выше. Не судите строго за нарушение иерархии сообщений )
Во-первых, не всегда существование решения означает принципиальную возможность его получить.
Принципиальные проблемы начинаются, если допускаются принципы по типу двойного отрицания. Для примера: можно показать, что для любого утверждения F существует такое число x, которое равно единице, если F истинно, и нулю в противном случае; кроме того, можно F выбрать таким образом, что x существует, но значение мы принципиально посчитать не можем. Избитый пример F=«числовая прямая R суть меншее по мощности из несчётных множеств».
Как следствие, мы можем говорить, в частности, что существует решение уравнения 100500-й степени, даже сами не зная, как его получить. А иногда не знаем не потому, что ещё метод не придумали, а потому что принципиально не можем знать (см. пример выше)
К счастью, эту проблему можно исключить, но для этого нужно отказаться от таких уютных принципов, как доказательство от противного и иже с ними. Примером такой неклассической теории служит конструктивизм, где утверждение «существует x, что ...» означает «уже описан алгоритм для нахождения x, что ...».
Автор статьи ставит более приземлённый вопрос: всегда ли алгоритм по нахождению решения, если он существует и где-то описан, является оптимальным. Этот вопрос в математической практике также возникал не раз. В некоторых теориях были построены алгоритмы генерации эффективных алгоритмов по образцу.
Математика не ставит цель решить задачу «оптимальным» доказательством, её цель — уменьшить размер доказательства и сделать его интуитивно понятным.
Как вам кажется, здесь скобок много или в самый раз?
doSmthWithClosure((function(x){ return function(){ return x } })(value))Серьёзно:
Сначала объясняется важность интерфейсов, мол, алгоритмы должны быть абстрагированы по-максимуму, поэтому используем интерфейсы вместо конкретных реализаций, классов.
Потом четко выделяется мысль «у функции не должно быть скрытого аргумента this, все аргументы равноправны».
Потом доказывается, что работать с неизменяемыми типами удобнее, чем с теми, которые имеют своё внутреннее состояние.
Автор как-бы подводит нас к замечательной мысли: не стоит нагружать объект лишним сложноконтролируемым поведением. Гораздо приятнее использовать неизменяемые типы данных, фабрики для их генерации и функции, свободные от this, для обработки.
Да и в речи «тип терма, вид типа, сорт вида» звучит приемлемо.
Впрочем, если в русской литература используется перевод «сорт», то следует использовать именно его, как бы непривычно это не звучало. Нужно использовать единообразные обозначения.
Концепция нудистского пляжа, я считаю, самая диеспособная (поскольку общество формирует мораль и требует её исполнения, поддерживая тем самым порядок — эта схема действовала всегда в той или иной форме)
Хорошая была книга, для детей в самый раз, не сложно, без каких-либо формул.