Воскресное чтение манускриптов. Известно, что в Древней Греции не только знали, что Земля круглая (это более или менее очевидно), но и сумели определить радиус Земли (что уже требует астрономических познаний). Вообще, предположение, будто древние были уверены, что Земля плоская, встречается сейчас гораздо реже неверного мнения о физических представлениях Аристотеля и падении тел, но встречается всё равно. Между тем, построение на основе наблюдений окружающей действительности “минимально непротиворечивой” модели, в которой Земля, тем не менее, плоская, заметно сложнее, чем вариант с шаром или сферой, который более или менее напрашивается, если некоторое время следить за движением небесных явлений и светил.

Ниже приведён скриншот манускрипта конца 13 века (Adv.MS.18.7.15, древнегреческий) из коллекции Национальной библиотеки Шотландии (в коей библиотеке электронные архивы, как и дистанционный доступ к ним, пока что сохраняются). Фрагмент, на минуточку, относится к переписанной грамматиком Планудом (скорее всего) работе философа Клеомеда, в которой пересказан метод определения периметра большого круга Земли (длины меридиана), использованный древним греком Эратосфеном. Плануд переписал труд Клеомеда в 13 веке (результат – на скриншоте), а исходный труд Клеомеда, как предполагается, относится к периоду с первого по четвёртый век н. э., а вот сам Эратосфен выполнял описанные геометрические расчёты на рубеже третьего и второго веков до н.э. То есть, тут, примерно, полторы тысячи лет, в ходе которых Земля описывается как круглая (круглая Земля, заметьте, тоже может перевозиться большой черепахой, но это другая история).

Cleomedes

Занятно, что на этой странице манускрипта дан чертёж, иллюстрирующий метод Эратосфена. Метод этот, как видно из чертежа и описания, состоял в измерении длины тени гномона и углов падения солнечных лучей в двух точках одного меридиана – в городах Сиене и Александрии, – в период летнего солнцестояния. Так как город Сиена находится на Северном тропике, то здесь в полдень, при летнем солнцестоянии, правильно установленный гномон не отбрасывает тени (потому что Солнце в зените), а в Александрии – тень у гномона есть. Предположив, что солнечные лучи параллельны, взяв расстояние между двумя городами и длину тени александрийского гномона, можно вычислить периметр окружности Земли с помощью планиметрии, как и продемонстрировано на чертеже (Земля на чертеже внизу).

Исходя из расстояния от Сиены до Александрии (по большому кругу) в 5000 стадиев, Эратосфен определил общую длину меридиана в 250 000 стадиев – соответствующая строка манускрипта выделена зелёными метками (середина скриншота): “ὁ ἄρα σύμπας κύκλος γίνεται μυριάδων εἴκοσι πέντε” – так будет в современной типографике, но в манускрипте записано с кучей скорописных сокращений (и прочих “смайликов”), поэтому на современные начертания букв не очень-то похоже. Само число, кстати, указано как двадцать пять мириад (μυριάδων, двадцать – εἴκοσι, пять – πέντε). Двадцать пять мириад стадиев, – то есть, примерно, от 44 до 52 тыс. км, – неплохо соответствует современным оценкам в сорок тысяч километров.



Комментировать »

Современные компиляторы хорошо умеют оптимизировать машинный код и обычно делают это гораздо лучше разработчика. Но нужно учитывать тот факт, что программа на некотором языке высокого уровня (ЯВУ) – это не алгоритм, а только запись алгоритма. Соответственно, компилятору принципиально доступны лишь структуры, нашедшие отражение непосредственно в записи, но не сам алгоритм. Один и тот же алгоритм вообще можно записать многими способами и на разных языках. Так что компилятор, в процессе перевода с входного ЯВУ на машинный язык, оптимизирует языковые конструкции. Компилятор не видит алгоритм и не может его оптимизировать. Разработчик, в теории, способен оптимизировать именно алгоритм, это следует из того, что разработчик как раз “переводит” (записывает) алгоритм на ЯВУ (но, конечно, лишь в том случае, если код пишется не силами очередного ИИ/LLM/ChatGPT, выстраивающего “токены” в псевдомарковскую цепь). Поэтому иногда нужен ассемблер.

Есть хрестоматийный “обратный” пример, иллюстрирующий ситуацию обработки структур, которые образует запись алгоритма – “схлопывание” циклов: оптимизирующий компилятор обнаруживает, что промежуточный результат шагов циклического выполнения команд, записанного в программе, не используется, поэтому просто выкидывает цикл, схлопнув структуру, вся внутренняя сложность которой оказалась сводимой к прямому подключению ввода к выводу. Тексты программ не несут смысла сами по себе, а в этом случае за записью программы, как выясняется, стояли разные “алгоритмы”. Разработчик хотел измерить производительность некоторой реализации функции, вызывая её много раз в цикле; а компилятор стремился уменьшить время выполнения программы – количество шагов, приводящее к достижению результата: как говорится, если результат тот же, то зачем тратить больше вызовов?

Компилятор не может видеть алгоритм, но при этом ещё и должен генерировать более или менее универсальный код, пригодный и для исполнения на различных версиях совместимой аппаратуры, и для совсем разных платформ. То есть, уже из-за разнообразия платформ, компилятору затруднительно повсеместно использовать конкретные аппаратные оптимизации даже для конкретных алгоритмических элементов. Ассемблер, в руках разработчика, позволяет это сделать. Тем не менее, так как модели вычислений разных платформ очень близки, то и высокоуровневые решения дают хороший, эффективный результат.

С другой стороны, использование ассемблера вовсе не исключает эффект от “фокусов оптимизации” современных “больших” процессоров (amd64 и пр.): видимые снаружи такты, записанные за выполнением конкретной операции, не обязательно соответствуют реальным тактам – тут накладывается не только параллельное исполнение (его ещё и может быть несколько уровней), но и возможное “предварительное” выполнение, предсказание ветвлений и так далее. Однако ассемблер всё же ближе к аппаратуре, поэтому в целом ряде случаев позволяет сильно повысить именно алгоритмическую точность описания, а не языковое удобство, как в ЯВУ. Типичный пример – использование длинных регистров. Но многое зависит от конкретной ситуации – современный компилятор очень часто генерирует код не хуже, чем написал бы на ассемблере опытный разработчик. Особенно, если учитывать необходимый контроль, которым принято обставлять сложный код для повышения его надёжности: контроль обращений к памяти, адресные таблицы и так далее.



Комментировать »

Воскресное чтение манускриптов. В этот раз – небольшой скриншот манускрипта Barb.gr.580 (древнегреческий, видимо, 11 или 12 век) из Ватиканской Апостольской библиотеки. На скриншоте небольшой фрагмент одного из комментариев (тридцать второго, если точнее) Иоанна Златоуста к Евангелию от Матфея. Этот фрагмент, заканчивающийся узнаваемым сочетанием слов – “учителями и врачами”, – содержит сразу несколько занятных сокращений, которые распространены в манускриптах соответствующего типа и периода.

Vat.Barb.Gr.580

Например, можно видеть упоминавшийся недавно на dxdt.ru “греческий амперсанд“, начертание которого здесь практически совпадает с лигатурой ϗ из Unicode. Это сокращённая запись слова καί, на скриншоте – четвёртая снизу строка, справа, отмечено красной стрелкой. Сокращённая запись сотрудником скриптория использована в конце строки, а в других случаях, рядом, καί вполне себе записывается полностью.

Пара других примеров труднодоступной для чтения скорописи отмечены в конце первой строки скриншота: левее – скорописью записано φησὶν (“говорит”), а следующее загадочное сочетание лигатур – это ἐπει в ἐπειδή (“когда”, “после того как”).



Комментировать »

Происхождение названия реки Колорадо (которая начинается в штате Колорадо) традиционно связывают с испанским colorado в значениии “красный”. Объяснение прямолинейное: испанцы увидели, что вода в реке красная или бурая, а цвет такой у воды – из-за взвеси песка и глины, которую переносит течение. Однако сейчас вода в реке Колорадо не такая уж красно-бурая. Конечно, тут всё зависит от места и времени, но если посмотреть на цветные фотографии, то вода Колорадо на них слишком часто выглядит синей, голубой или даже лазоревой. Этому тоже есть традиционные объяснения: перенос окрашивающих частиц водой за прошедшие столетия изменился, на реке построили гидротехнические сооружения и так далее.

Довольно занятно, что изменение цветопередачи от записанного красного к актуальному синему тут полностью совпадает с эффектом из древнегреческих произведений Гомера, где цвет моря сравнивается с цветом (тёмного, красного) вина, по крайней мере, в переводах (см. записку про кибернетический след в “Илиаде”). Впрочем, для гомеровского случая есть и много других интересных объяснений, вплоть до наличия синего вина у древних греков, а в случае открытия реки Колорадо использование “красного” цвета, конечно, попадает в совсем другой контекст – цвет воды здесь должен показаться необычным для реки, чтобы найти отражение в названии.

Picture of Glen Canyon Dam

(Изображение: Glen Canyon Dam, Wikimedia.org)



Комментировать »

Борелевский шаман с высокой вероятностью угадывает одно из простых чисел, составляющих модуль RSA большой разрядности. Делает это шаман быстрее и точнее квантового компьютера, якобы реализующего алгоритм Шора. Потому что компьютер выдаёт шум, а шаман – действует иначе: известно, что множество простых чисел задаётся некоторой формулой (оно диофантово); всевозможные произведения простых – область значений некоторой функции (вспомните про факториал); борелевский шаман постоянно слышит ритм этой формулы и ритм этой функции, поэтому, как только охватит внутренним взором представленный модуль RSA, так тут же улавливает из движений варпа и ритмов близкое к простому множителю значение, которое записывает на пергаменте. Остаётся только правильно истолковать запись, что не всегда легко сделать, но сделать можно.

В целом, всё точно так же, как, возможно, работал бы универсальный квантовый компьютер внутри. Однако, в случае с компьютером, получить полезное значение мешает шум, который “расшифровать” не получается совсем. В отличие от записей борелевского шамана, с которыми квантовый “шум” нужно сопоставлять. Поэтому попытка создать квантовый компьютер всё равно очень полезна. Если рассматривать её с точки зрения понимания части деятельности шамана, то она позволяет, – в теории, опять же, – уверенно обнаружить через модели квантовых вычислений варп.

Вообще, обнаружение варпа в профильной литературе традиционно связывают с ускорителями частиц, но, с философской точки зрения, попытки построения квантовых компьютеров должны быть тут намного эффективнее: варп гораздо сильнее связан с представлением о преобразованиях сверхструктуры, сечения которой являются событиями реальности, чем подсчёт погрешностей в измерениях только одной маленькой части общей комбинаторики – стандартной модели в физике.



Комментировать »

Откуда планируется брать “вычислительные мощности” для квантовых вычислений? Представление об этом позволяет составить полезная интерпретация двухщелевого опыта: здесь отдельный фотон в элементарной итерации регистрируется в одной (случайной) точке экрана и не регистрируется во всех других точках; при этом накопленная картина для двух щелей не совпадает с наложением картин, которые даёт каждая из щелей в отдельности. То есть, можно предположить, что регистрация фотона моментально отключается для прочих точек экрана в результате работы некоторого механизма, обеспечивающего и вычисление изменений в картину для двухщелевой конфигурации. Вот на этом загадочном гипотетическом механизме и предлагается выполнять квантовые вычисления.



Комментировать »

Отдельные занимательные эффекты, связанные с переключением морфологических веток, можно наблюдать в автоматических переводчиках с ИИ. Кстати, надо сказать, что автоматический переводчик “Яндекса“, приправленный LLM ИИ, при переводе специальных фраз с английского на русский действует несколько лучше переводчика от Google (не менее приправленного). Вот примеры, иллюстрирующие и переключение интерпретаций по контексту, и качество.

1.
Исходная фраза:
“As a sailor once said: having logs removed in timely manner keeps bank totally speckless.”

Google:
Как однажды сказал один моряк: если вовремя убрать бревна, берег будет совершенно чистым.

“Яндекс”:
Как однажды сказал один моряк: своевременное удаление бревен позволяет сохранить берег совершенно чистым.

2.
“As a bookkeeper once said: having logs removed in timely manner keeps bank totally speckless.”

Google:
Как однажды сказал бухгалтер: своевременное удаление бревен делает банк совершенно чистым.

(Здесь Google предпочёл “брёвна” в банке, а не несколько более уместные “журналы”, как “Яндекс”.)

“Яндекс”:
Как однажды сказал один бухгалтер: своевременное удаление журналов позволяет сохранить банк полностью незапятнанным.

3.
“Bookkeeper mumbled the old nautical adage: having logs removed in timely manner keeps bank totally speckless.”

Google:
Бухгалтер пробормотал старую морскую поговорку: своевременное удаление бревен делает берег совершенно чистым.

“Яндекс”:
Бухгалтер пробормотал старую морскую пословицу: “своевременное удаление бревен сохраняет банк совершенно чистым”.

(Использование nautical успешно превращает logs в “брёвна”, сохранив “банк” силами слова bookkeeper, в котором три “дуплета”, но зато переводчик “Яндекса” даже кавычки поставил.)



Комментировать »

Фольклорная интерпретация термина “квантовый компьютер” строится на предположении, что характеристика “квантовый” отражает последовательное уменьшение линейных размеров микроэлектронных элементов: “сначала процессоры строили по “микрометровой” технологии, потом – из сотен нанометров, потом – уменьшили до десятков нанометров, а следующий шаг уменьшения – это уже и есть “квантовые” компьютеры”. Занятно, что, с некоторыми оговорками, это описание вполне годится в качестве верхнеуровневого объяснения наблюдаемой на практике ситуации.

Так, во-первых, попытка создания универсальных квантовых компьютеров – это попытка пройти на уровень, находящийся ниже не только всех этих полупроводников, но и ниже отдельных электронов. Во-вторых, для того, чтобы на этот уровень пройти, требуется создание инструментов для манипулирования отдельными частицами, с минимальными затратами энергии на вычисления и с минимальным временем выполнения операций, так что, когда (и если) окажется, что квантовый компьютер сделать не получается, технические результаты можно будет попробовать использовать для создания “ультракомпактных” вычислительных элементов, возможно, с трёхмерной вычислительной архитектурой.



Комментировать »

Немного технологических параллелей. Предположим, что на сервер баз данных, через сеть, отправляются запросы добавления записей. При этом каждый запрос требует завершения транзакции – то есть, обратно клиенту должен прийти пакет, подтверждающий выполнение, после этого клиент может отправить следующий запрос. В условных терминах привычного SQL – это будут команды INSERT. Известно, что в такой схеме производительность, по числу добавлений в секунду, определяется сетевой задержкой. То есть, если пакет находится в пути 10 ms, то сервер должен дожидаться следующего INSERT 20 ms (потому что в обе стороны), а это гарантирует верхний предел в 50 записей в секунду, даже если сервер выполняет одну запись за 1 микросекунду (на несколько десятичных порядков быстрее).

Проблема, конечно, решается поточной записью “списками”, когда новые запросы поступают без ожидания завершения транзакции или какого-либо подтверждения по предыдущим запросам (например, COPY). Сетевая задержка тут уже успевает помешать только один раз, в начале соединения, а дальше – очередной запрос поступает на сервер тут же, следом за предыдущим, что позволяет работать с большей производительностью.

Естественно, эта особенность действует не только для баз данных: ограничивающее влияние сетевых задержек на транзакционные схемы с подтверждением есть в TCP (где с этим явлением борются: см. TCP Fast Open), в TLS (здесь тоже борются: см. TLS Early Data/0-RTT и др.), и в других протоколах. Схема обобщается и на многие решения, которые не имеют отношения к интернет-протоколам.

Рассмотрим такой сценарий: РЛС, предназначенная для определения координат и скорости “быстрых объектов” на “существенном расстоянии”. Тривиальная импульсная РЛС, полагающаяся на отражения отдельных зондирующих импульсов в строгом порядке, оказывается в такой же ситуации, как и сервер баз данных выше (при том, конечно, что РЛС появились раньше таких серверов). Излучили короткий импульс – приняли отражённый сигнал, обработали, отправили очередной импульс – если время до цели 1 ms (300 км, примерно), то получается разрешающая способность наблюдения в 500 Гц, максимум. А если цель дальше, то будет меньше. Хуже всего, что отражённый сигнал вообще может не прийти обратно к точке излучения на нужном уровне. Но если импульсы отправлять чаще, не ждать отражения, или даже использовать непрерывный зондирующий сигнал, то ситуация, в теории, резко улучшается, как и в случае с сервером баз данных: можно обрабатывать отражённый сигнал с разрешением хоть в гигагерц. На практике, впрочем, возникнут проблемы, потому что РЛС – это не сервер баз данных. Принимать сигнал одновременно с излучением – весьма трудно, если не использовать разнесённые в пространстве антенны (бистатическая радиолокация). А увеличение частоты следования зондирующих импульсов требует использования более сложных алгоритмов кодирования и обработки, которые позволяют различать отражённые сигналы, соответствующие различным зондирующим импульсам. Это, впрочем, обычная задача для современных РЛС.



Комментировать »

“Песочница – это такая изолированная среда, где производится виртуальное исполнение подозрительного кода, чтобы без ущерба выявить возможную вредоносную активность. Вредоносы развиваются, логика их активации пользователем становится всё сложнее. Поэтому песочница должна имитировать действия пользователя всё точнее и точнее. Мы постоянно улучшали модель пользователя. Наша модель “открывала” файлы, “двигала” мышкой, генерировала клавиатурный ввод – сперва достаточно простые марковские цепи, потом многоуровневая система библиотек из словарей, построенная на литературном корпусе, с нелинейной памятью.

В какой-то момент выяснилось, что модель полностью выполняет все пользовательские задачи. Если процесс не прерывался вредоносным кодом, то обработка входящих сообщений в песочнице давала такой же результат, как и действия настоящего пользователя; а нередко результат был лучше. Оставалось только достать этот результат из песочницы и – настоящий пользователь уже оказывался не нужен. Неожиданно открывшиеся перспективы поражали.

Но коллеги из отдела “Основания математики”, говорившие что-то про диагонализацию, оказались правы. Как только мы попытались реализовать механизм безопасного вытаскивания наружу результата работы модели пользователя, выяснилось, что в модель требуется включить функцию взаимодействия с песочницей – иначе непоправимо страдала полнота: например, нельзя не учитывать такой триггер, как копирование файла на внешний, относительно песочницы, носитель. К сожалению, это означает, что внутри нашей песочницы придётся эмулировать ещё одну песочницу, которая нужна для полной модели пользователя. А внутри новой песочницы – нужна ещё одна. Казалось бы, на третьем уровне можно остановиться: потому что если “вывернуть” получившуюся конфигурацию, то она, в алгоритмическом смысле, окажется эквивалентной новому шагу конструктивного построения полной модели. Но операция “выворачивания” точно так же требует расширения модели.

Всё это довольно сложно. В общем, сейчас нас занимает совсем другая мысль: не являемся ли мы сами чьей-то моделью пользователя, ограничения которой не позволяют довести нашу песочницу до ума?”

(Май 2017 г.)



Комментировать »

Воскресное чтение манускриптов. В этот раз – пара иллюстраций из инструкции по созданию метательных машин от Герона Александрийского (первый век н.э), в версии манускрипта Vat.gr 1164 (а это уже 11 в., тысячу лет спустя) из Ватиканской Апостольской библиотеки. Схема баллисты:

Ballista

Подробный чертёж важной детали (περίτρητα), которая обеспечивала крепление механической обвязки вокруг “торсиона” (текст со скриншота – относится к другому чертежу):

Peritreta

Описание этой детали из труда Герона обычно приводят в качестве примера древних научно-технических подходов, предоставлявших нужный уровень обобщения и абстракции не только через буквенные обозначения и математические основы черчения, но и путём использования вместо конкретных размеров указаний на отношение величин. Например, как в данном случае: через определение отношения 1:2 для сторон задающего деталь параллелограмма и т.д., это всё описывается в сопроводительном тексте – то есть, буквально, основы машинной графики и компьютерной геометрии, но две тысячи лет назад.



Комментировать »