Про китайскую комнату. Уж очень бесит этот аргумент.
Когда слышу про китайскую комнату, я хватаюсь за бритву. Китайская комната — это в точности компьютер, ни больше, ни меньше. Таким образом, это совершенно бесполезная метафора для обсуждения феномена сознания. Ну, разве что для людей, которые никогда не видели компьютер и не читали про машину Тьюринга.
Ошибка Сёрла (автора метафоры) состоит в том, что он задает вопрос о понимании китайского языка человеком, находящимся внутри комнаты (и дает отрицательный ответ с последующим выводом о невозможности алгоритмизации сознания). Но роль человека в комнате очень мала — это просто компьютерный процессор, который представляет собой всего лишь конечный автомат, притом небольшой. Если уж ставить вопрос о том, обладает ли комната сознанием, то искать его нужно, очевидно, не в процессоре, а в состоянии памяти.
Я думаю, в любой дискуссии все упоминания китайской комнаты можно смело выбрасывать и заменять на тезис о том, что сознание (не)алгоритмизуемо.
Я имел в виду другое — чтобы другой человек мог попросить носителя наушников вступить с ним в коммуникацию. ;) Это на случай, если наушники такого типа станут популярными.
Мой опыт таков. Я предпочитаю верстать в TeXе, даже если формул немного. Просто так мне привычней и удобней. Превращение заготовки в хабрастатью требует несколько шагов, часть из которых требует ручной работы:
Предварительная обработка tex-исходника. Я сейчас забыл, из чего она состояла, но бо́льшая часть работы делалась полуавтоматически в текстовом редакторе. Вроде бы можно почти все автоматизировать awk- и sed-скриптами. Самая неприятная часть — нумерация формул и других объектов, на которые нужно проставить ссылки (\ref и подобные команды). Требуется заменить все автоматические ссылки на искусственные (где отображаемая метка прописана вручную или с помощью скрипта). Ну и вообще нужно использовать более бедное подмножество TeXа, чтобы потом не возникло проблем.
Конвертация tex-испходника в html (автоматически). Я пробовал разные способы, tex2ht годится.
Постобработка html, чтобы его мог переварить старый хабраредактор. Больше всего возни было с картинками, потому что их нужно было вручную заливать в хранилище и копировать ссылки.
Здесь показан прямой процесс преобразования, но в общем случае он циклический — нужно исправлять ошибки в уже опубликованном тексте, а также нужно вести версионирование.
Есть одна интересная проблема, для которой я придумал решение, но не довел его до конца (а если бы довел, то про это была бы отдельная статья на Хабре). На первом этапе делается полуавтоматическое преобразование tex-исходника, и логично хранить два варианта в разных git-ветках: master и habr. Тогда можно исправления в master переносить в habr с помощью git merge. Проблема заключается в том, что встроенный в git механизм сравнения diff3 работает на уровне строк и поэтому не может сделать красивое слияние. Решение заключается в том, чтобы подсунуть гиту другой diff3, работающий на уровне слов. Причина, по которой это не было сделано, заключается не в том, что такую реализацию diff3 сложно найти и настроить, а в том, что мотивация была слишком слаба — после внесения изменений в master оказывалось довольно легко и быстро протащить их в ветку habr вручную.
В общем, худо-бедно процесс был поставлен, пусть с некоторыми неудобствами. При этом, благодаря контролю версий, можно распараллелить работу между несколькими сотрудниками разной квалификации.
Как этот процесс провернуть на новом редакторе, я вообще не представляю. В принципе вместо html подошел бы любой другой формат, главное — стандартный, в который можно (полу)автоматически конвертировать из чего угодно.
Не знаю, как работает конкретно Котлин, но сюда просится параметрический полиморфизм: для любой функции типа R->R строится естественное отображение в функцию, переводящую величину нулевой размерности в величину того же типа. В худшем случае это синтаксически будет выражаться как (map' f v), где map' — это вышеупомянутое отображение (и только его нужно реализовать), хотя, конечно, изящней было бы писать просто (f v), но для этого, кажется, придется каждую функцию f: R->R перегружать, что явно неудобно.
Получается, что создатели языков благосклоннее относятся к инфиксным операциям нежели к префиксным и суффиксным. Так, например, в Котлине можно определять инфиксные собственные функции, а вот префиксные и постфиксные - нет (см. здесь)
Так что пока в KotUniL обходимся без постфиксных функций.
Тогда как это работает? Насколько я понял, писать (1 m) не получится, потому что нет пользовательских постфиксных операций, но как работает синтаксис (1.m)? Я бы сказал, что такой записи вижу постфиксную операцию m, примененную к числовому литералу (1.). А если вместо литерала будет переменная числового типа?
Использование в формулах функций типа синуса или интеграла мы опускаем, поскольку они определены над безразмерными величинами.
Синус и другие тригонометрические функции, действительно, можно применять только к безразмерным величинам, но вот интегрирование и дифференцирование работает как, соответственно, умножение и деление. Дифференциал действует как аддитивная операция, поэтому размерности не меняет (dx имеет ту же размерность, что и x). Подынтегральное выражение «чисто случайно» записывается как умножение одной величины на дифференциал другой. Аналогично, запись дифференцирования тоже «чисто случайно» записывается как отношение дифференциалов двух величин. На самом деле такая нотация конечно же не случайна, в этом есть большой смысл.
Также размерной является операция скалярного умножения векторов, для этого необходимо, чтобы все компоненты вектора имели одинаковый тип (но у перемножаемых векторов типы могут быть разными).
Тем самым наше пространство является кандидатом на звание абелевой группы, да поправят меня математики среди наших читателей, если это не так.
Это пространство действительно является абелевой группой, но только по умножению. Такие группы называют мультипликативными (хотя это не определение, а договоренность — если обозначаем групповую операцию как умножение, нейтральный элемент как единицу и т. д., то принято говорить «мультипликативная»). Поскольку складывать можно не любые элементы (а только элемент сам с собой), то группы по сложению не образуется, и, следовательно, никакое поле тоже не получается.
Вообще-то backtick — это обычный обратный апостроф, который есть на стандартной клавиатуре (в левом верхнем углу). Также он является ASCII-символом, о чем нетрудно догадаться, взглянув на его юникод-представление, — значение входит в первые 128 символов (0x60 < 0x80 = 128).
перекладывание вины («Сторонний сайт не отвечает на наши запросы»)
Не вижу здесь никакого перекладывания вины или иных манипуляций. Для меня это выглядит просто как сообщение некоторого факта. Конечно, сообщение может быть фактологически ложным, и это не очень просто проверить, но ведь и правда случается, что сайт не отвечает на запросы.
Когда слышу про китайскую комнату, я хватаюсь за бритву. Китайская комната — это в точности компьютер, ни больше, ни меньше. Таким образом, это совершенно бесполезная метафора для обсуждения феномена сознания. Ну, разве что для людей, которые никогда не видели компьютер и не читали про машину Тьюринга.
Ошибка Сёрла (автора метафоры) состоит в том, что он задает вопрос о понимании китайского языка человеком, находящимся внутри комнаты (и дает отрицательный ответ с последующим выводом о невозможности алгоритмизации сознания). Но роль человека в комнате очень мала — это просто компьютерный процессор, который представляет собой всего лишь конечный автомат, притом небольшой. Если уж ставить вопрос о том, обладает ли комната сознанием, то искать его нужно, очевидно, не в процессоре, а в состоянии памяти.
Я думаю, в любой дискуссии все упоминания китайской комнаты можно смело выбрасывать и заменять на тезис о том, что сознание (не)алгоритмизуемо.
Я понимаю, что эта гифка очень меметична, но всё-таки реальные ответы сотрудника не настолько орфографически и пунктуационно бесячие.
Почему три части?
https://xkcd.com/566/ — Too bad they never made any sequels.
Но это, конечно, дело вкуса.
Я имел в виду другое — чтобы другой человек мог попросить носителя наушников вступить с ним в коммуникацию. ;) Это на случай, если наушники такого типа станут популярными.
А уже разработали стандартный жест, означающий «включи прозрачность наушников, я сейчас буду с тобой разговаривать»?
Но это значит, что количество отсчётов (представимых значений) растет квадратично. А количество цифр зааисит от него логарифмически.
Почему квадратично? Навскидку кажется, что в константу раз (примерно вдвое).
Судя по числовому значению, это обычная килокалория.
Не шифроваться, а подписываться. Далее в тексте это сказано явно.
Но речь появилась еще раньше, и намного.
Мой опыт таков. Я предпочитаю верстать в TeXе, даже если формул немного. Просто так мне привычней и удобней. Превращение заготовки в хабрастатью требует несколько шагов, часть из которых требует ручной работы:
Предварительная обработка tex-исходника. Я сейчас забыл, из чего она состояла, но бо́льшая часть работы делалась полуавтоматически в текстовом редакторе. Вроде бы можно почти все автоматизировать awk- и sed-скриптами. Самая неприятная часть — нумерация формул и других объектов, на которые нужно проставить ссылки (\ref и подобные команды). Требуется заменить все автоматические ссылки на искусственные (где отображаемая метка прописана вручную или с помощью скрипта). Ну и вообще нужно использовать более бедное подмножество TeXа, чтобы потом не возникло проблем.
Конвертация tex-испходника в html (автоматически). Я пробовал разные способы, tex2ht годится.
Постобработка html, чтобы его мог переварить старый хабраредактор. Больше всего возни было с картинками, потому что их нужно было вручную заливать в хранилище и копировать ссылки.
Здесь показан прямой процесс преобразования, но в общем случае он циклический — нужно исправлять ошибки в уже опубликованном тексте, а также нужно вести версионирование.
Есть одна интересная проблема, для которой я придумал решение, но не довел его до конца (а если бы довел, то про это была бы отдельная статья на Хабре). На первом этапе делается полуавтоматическое преобразование tex-исходника, и логично хранить два варианта в разных git-ветках: master и habr. Тогда можно исправления в master переносить в habr с помощью git merge. Проблема заключается в том, что встроенный в git механизм сравнения diff3 работает на уровне строк и поэтому не может сделать красивое слияние. Решение заключается в том, чтобы подсунуть гиту другой diff3, работающий на уровне слов. Причина, по которой это не было сделано, заключается не в том, что такую реализацию diff3 сложно найти и настроить, а в том, что мотивация была слишком слаба — после внесения изменений в master оказывалось довольно легко и быстро протащить их в ветку habr вручную.
В общем, худо-бедно процесс был поставлен, пусть с некоторыми неудобствами. При этом, благодаря контролю версий, можно распараллелить работу между несколькими сотрудниками разной квалификации.
Как этот процесс провернуть на новом редакторе, я вообще не представляю. В принципе вместо html подошел бы любой другой формат, главное — стандартный, в который можно (полу)автоматически конвертировать из чего угодно.
Довольно странно брать эндшпили из базы партий. Гораздо эффективней построить свою версию таблиц Налимова, там в основе довольно простая идея.
Не знаю, как работает конкретно Котлин, но сюда просится параметрический полиморфизм: для любой функции типа R->R строится естественное отображение в функцию, переводящую величину нулевой размерности в величину того же типа. В худшем случае это синтаксически будет выражаться как (map' f v), где map' — это вышеупомянутое отображение (и только его нужно реализовать), хотя, конечно, изящней было бы писать просто (f v), но для этого, кажется, придется каждую функцию f: R->R перегружать, что явно неудобно.
Тогда как это работает? Насколько я понял, писать (1 m) не получится, потому что нет пользовательских постфиксных операций, но как работает синтаксис (1.m)? Я бы сказал, что такой записи вижу постфиксную операцию m, примененную к числовому литералу (1.). А если вместо литерала будет переменная числового типа?
Синус и другие тригонометрические функции, действительно, можно применять только к безразмерным величинам, но вот интегрирование и дифференцирование работает как, соответственно, умножение и деление. Дифференциал действует как аддитивная операция, поэтому размерности не меняет (dx имеет ту же размерность, что и x). Подынтегральное выражение «чисто случайно» записывается как умножение одной величины на дифференциал другой. Аналогично, запись дифференцирования тоже «чисто случайно» записывается как отношение дифференциалов двух величин. На самом деле такая нотация конечно же не случайна, в этом есть большой смысл.
Также размерной является операция скалярного умножения векторов, для этого необходимо, чтобы все компоненты вектора имели одинаковый тип (но у перемножаемых векторов типы могут быть разными).
Это пространство действительно является абелевой группой, но только по умножению. Такие группы называют мультипликативными (хотя это не определение, а договоренность — если обозначаем групповую операцию как умножение, нейтральный элемент как единицу и т. д., то принято говорить «мультипликативная»). Поскольку складывать можно не любые элементы (а только элемент сам с собой), то группы по сложению не образуется, и, следовательно, никакое поле тоже не получается.
Поэтому удобней не следовать этому совету
а набирать на клавиатуре (только не перепутав с обычным апострофом).
Вообще-то backtick — это обычный обратный апостроф, который есть на стандартной клавиатуре (в левом верхнем углу). Также он является ASCII-символом, о чем нетрудно догадаться, взглянув на его юникод-представление, — значение входит в первые 128 символов (0x60 < 0x80 = 128).
Теперь мне не дает покоя наречие «королева», пытаюсь придумать, что оно могло бы означать и с какими глаголами употребляться.
Не вижу здесь никакого перекладывания вины или иных манипуляций. Для меня это выглядит просто как сообщение некоторого факта. Конечно, сообщение может быть фактологически ложным, и это не очень просто проверить, но ведь и правда случается, что сайт не отвечает на запросы.