Аттракцион повышенной точности

[spamsink]

Когда в 1967 году советским вычислительным математикам досталась очень большая (аж до 192 Кб адресуемой памяти, на более ранних, которые они могли видеть, было меньше 50 Кб) очень быстрая (аж до миллиона операций в секунду, на более ранних - не больше 50 тысяч) вычислительная машина, они тут же захотели сделать себе библиотеку программ, полезных для повседневной работы.

Программой №1 была "прокрутка" - выполнение программы по одной команде и печать адреса и кода каждой команды и значений используемых в ней регистров на АЦПУ. При программировании в машинных кодах - незаменимая вещь.
Программами №2 и №3 были "автокод" (ассемблер) и "программа стыковки". Тоже дело полезное для повседневной работы.
А вот программой №4 была "печать с форматом". Программа печатает в формате, утвержденном нормоконтролем, программы с адресами команд и названиями кодов операций. Кстати о приоритетах.

Дальше шли:

• перемножение матриц
  
• решение системы линейных алгебраических уравнений
  
• вычисление определенных интегралов по формуле Симпсона
  
• "упорядочение массива" (то ли слово "сортировка" тогда ещё не придумали, то ли конкретно "упорядочение" значило сохранение исходного массива нетронутым, а запись результата в другой массив - каким алгоритмом это делалось, ещё предстоит разобраться; чует моё сердце, что пузырьком - машина-то быстрая, а массивы маленькие)
  
• ассоциативный (по маске и значению) поиск слова в массиве
  
• поиск максимального числа в массиве (поиска минимального не нажили)
  
• решение системы дифференциальных уравнений 1-го порядка методом Рунге-Кутта
  
• слияние двух массивов ([a, b, c, ...], [d, e, f, ...] -> [a, d, b, e, c, f, ...] - зачем бы это так уж часто было нужно?)
  
• обращение матрицы
  
• квадратичная интерполяция
  
• буферизация ввода-вывода на внешние носители
  
• пакетный отладчик с весьма развитым скриптовым языком
  

Всё, пожалуй, вполне предсказуемо. Если сейчас кого спросить, какие (под)программы должны были входить в стандартный инструментарий вычислительного математика ~60 лет назад, то примерно это и получится.

А сразу за ними в наборе была стандартная программа "увеличение точности" (хотя, казалось бы, 40 бит мантиссы должно быть достаточно для большинства применений). Насколько я понимаю, если у кого результаты вычислений оказывались бессмысленными из-за потери точности при вычислениях с плавающей точкой,
то рекомендовалось не сразу заморачиваться выяснениями, как исправить алгоритм, чтобы ликвидировать потерю точности, а сначала выяснить, становится ли хоть сколь-нибудь лучше при увеличении точности.

Но как? Тут тебе не Фортран, где можно объявить переменные DOUBLE PRECISION вместо REAL, и не C++, родной.

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

Работало это, понятное дело, гораздо медленнее, чем могло бы при использовании библиотеки повышенной точности с отдельными вызовами, но, по-видимому, народ устраивало.

Comments

[juan_gandhi]

Ха, какой интересный подход!

А всё потому, что форта у людей не было. (Но были перфокарты.)

[spamsink]

До изобретения форта оставалось 3 года. Хотя, казалось бы, на БЭСМ-6, которая была, в сущности, практически стековой машиной, сам бог велел независимо догадаться. Ан не догадались.

И при программировании в кодах/на ассемблере стеком пользоваться очень не любили. Потому что никогда не знаешь, сколько в нём ещё места осталось, вдруг переполнится. Лучше везде рабочих ячеек (с именами РАЯ, РАЯ1, РАЯ2 и т. п.) поназаводить, никогда не помнить, какая где в какой момент занята, и при изменении/дополнении кода заводить дополнительные.

[juan_gandhi]

Да там такая система адресации и длина слова, что Агамирзян весь утрахался, адаптируя форт.

[spamsink]

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

[sobriquet9]

Забавно, что никакой статистики нет вообще. Даже захудалой логистической регрессии нет. Может быть, предполагалось считать самостоятельно Ньютоном-Рафсоном, так и этого тоже нет, опять сделай сам.

Про метод Симпсона тоже интересно. Меня ему учили, вместе с Ньютоном-Котесом, но с какими-то непонятными оговорками вроде "на практике трапеций достаточно". А потом выяснилось, что даже трапеции не нужны и всё сложное считают ещё тупее, Монте-Карлом.

[spamsink]

На этом уровне реализации (вызов "стандартной программы" с помощью ОС) есть только то, что хотели иметь буквально в первые год-два, когда реально программировали только в восьмеричных кодах или на упомянутом автокоде с птичьим языком.
А потом появились Алгол-60 (доморощенный, первоначально аж на БЭСМ-4) и Фортран (транскодированный с CDC 1604, так что полностью совместимый), нормальная система программирования с объектными модулями и загрузчиком, в т.ч. динамическим и оверлейным, из ОИЯИ в CERN съездили, всю их библиотеку оттуда привезли, и потребность в механизме "стандартных программ" для вычислительных нужд практически отпала.

Для Монте-Карла быстрые машины нужны.