Control structures in programming languages: from goto to algebraic effects
Книга Ксавье Леруа исследует эволюцию управляющих конструкций в языках программирования, от ранних операторов goto до современных алгебраических эффектов. Работа представляет собой историческое путешествие по дизайну языков, уделяя особое внимание механизмам контроля выполнения программ. Книга охватывает структурированное программирование 1960-х, генераторы и корутины в императивных языках, а также продолжения и операторы контроля в функциональных языках.
Книга разделена на четыре части: управляющие конструкции для императивных языков, операторы контроля для функциональных языков, от исключений к алгебраическим эффектам и обработчикам, а также рассуждения о контроле и эффектах. Особую ценность представляют многочисленные примеры кода на разных языках — от Fortran и Algol 60 до OCaml и Haskell. Работа сочетает историю, практические примеры и теорию, предлагая оригинальный сравнительный взгляд на языки программирования и обширное введение в алгебраические эффекты — современную область исследований в PL.
Комментарии (29)
- Критика исключений как "glorified come from", сравнение с POSIX сигналами и setjmp/longjmp.
- Дискуссия о checked исключениях в Java vs подход "ошибки как данные" для ожидаемых сбоев.
- Вопрос производительности алгебраических эффектов и ответ: реализация возможна через монады, оптимизирована в OCaml 5.
- Упоминание Xavier Leroy как автора CompCert, LinuxThreads и ключевой фигуры OCaml/Rocq.
- Шутка про INTERCAL и "come from" как пример необычного синтаксиса.
GNU Octave Meets JupyterLite: Compute Anywhere, Anytime
Команда Jupyter представила Xeus-Octave - новый kernel для JupyterLite, позволяющий запускать GNU Octave прямо в браузере. GNU Octave - бесплатный аналог MATLAB, теперь доступный без установки благодаря компиляции в WebAssembly. Для решения технических вызовов потребовался специальный инструмент на базе LLVM Flang и Emscripten для компиляции Fortran-кода, а также реализация BLAS/LAPACK, где выбор пал на Netlib LAPACK из-за меньших сложностей сборки.
Ключевым препятствием стало обширное использование блоков общих символов Fortran во внутренних библиотеках Octave, таких как odepack. Версия LLVM v20 на момент тестирования не поддерживала общую символьную линковку для WebAssembly, что потребовало дополнительных усилий для преодоления этого ограничения.
Комментарии (39)
- JupyterLite позволяет в браузере запускать ядра C++, Python, R, Lua, JavaScript и др. без серверной части.
- Octave и MATLAB — это два разных инструмента, и хотя Octave стремится к совместимости, он не является «клоном» MATLAB.
- Сообщество подчеркивает, что Octave — это полноценный язык для численных вычислений, а не просто «бесплатная замена MATLAB».
- Пользователи отмечают, что Octave и MATLAB различаются в деталях, но для базовых задач они взаимозаменимы.
- Обсуждение подняло вопрос о том, что Octave может быть полезен как встраиваемая библиотека, но это требует дополнительной работы.
Translating a Fortran F-16 Simulator to Unity3D
Перевод симулятора F-16 из Fortran в Unity3D потребовал адаптации аэрокосмических конвенций под игровой движок. Модель полёта, основанная на данных аэродинамических труб и реализованная через дюжину таблиц поиска и математических уравнений, изначально использовала правостороннюю систему координат с осью X вперёд, Y вправо и Z вниз — в отличие от левостороннего Z-вверх подхода Unity. Ключевой задачей стало корректное преобразование осей и знаков без потери физической точности.
Процесс включал интерполяцию многомерных таблиц, расчёт тяги двигателя, аэродинамических сил и моментов, а также реализацию системы управления полётом с PID-контроллерами и ограничителями перегрузки. Несмотря на профессиональный бэкграунд в аэрокосмической отрасли, автор отмечает сложность верификации такой модели без доступа к реальным лётным данным. Готовый симулятор доступен на itch.io, демонстрируя практический компромисс между академической точностью и игровой доступностью.
Комментарии (111)
- Участники обсуждают опыт работы с FORTRAN и его применение в аэрокосмической симуляции, включая исторические примеры и личные воспоминания.
- Поднимаются вопросы о единицах измерения (например, узлы, слагы) и их конвертации, с критикой подхода автора и предложениями использовать метрическую систему.
- Обсуждаются технические особенности языков программирования, такие как произвольные индексы массивов в FORTRAN и их аналоги в других языках.
- Упоминаются альтернативные реализации симуляторов на JavaScript и Clojure, а также ссылки на открытые проекты вроде Falcon BMS.
- Затрагиваются темы игровой ностальгии, сложностей моделирования физики и юмористические комментарии о единицах измерения (например, поронкусема).
Is Fortran better than Python for teaching basics of numerical linear algebra?
Современный Fortran может быть предпочтительнее Python для обучения основам численной линейной алгебры из-за строгой типизации и явного управления памятью, что помогает студентам лучше понять внутреннюю работу алгоритмов. В Python студенты часто полагаются на готовые функции вроде np.linalg.solve, что скрывает детали реализации и приводит к ошибкам, связанным с динамической типизацией и неправильной индексацией массивов. Например, путаница между списками и массивами NumPy или неявное приведение типов могут затруднить отладку.
Fortran, напротив, требует чёткого объявления переменных и размеров массивов, что снижает риски ошибок и заставляет студентов продумывать структуру данных. Это особенно важно для таких задач, как метод Гаусса-Зейделя или метод наименьших квадратов, где понимание циклов и операций с матрицами критично. Хотя Python с его экосистемой удобен для сложных проектов, Fortran обеспечивает более прозрачный переход от математических формул к коду, укрепляя фундаментальные навыки.
Комментарии (102)
- Обсуждается выбор языка для преподавания численных методов и линейной алгебры (Python, Fortran, Julia, C++ и др.), где Fortran хвалят за производительность и удобство для математики, а Python — за распространённость и простоту.
- Критикуется чрезмерно объектно-ориентированный подход в C++ для научных вычислений, а также сложности и "бородатость" некоторых языков (например, Fortran) для новичков.
- Поднимается вопрос о важности баланса между теоретической "чистотой" языка и его практической полезностью для будущей работы студентов.
- Отмечаются преимущества Julia и MATLAB/Octave для обучения благодаря близости их синтаксиса к математической нотации и удобным инструментам.
- Упоминаются проблемы с ошибками в Python (например, типизация и сообщения об ошибках), а также сложности отладки в сравнении с другими языками.
Why is Japan still investing in custom floating point accelerators?
- Япония продолжает финансировать Pezy Computing, создающую энергоэффективные математические ускорители SC4S/SC5, способные заменить GPU в HPC и ИИ.
- SC4S: 2 048 ядер, 8 TFLOPS FP64, 200 Вт, 40 нм; SC5: 16 384 ядер, 64 TFLOPS FP64, 400 Вт, 7 нм; оба используют SIMD и обходятся без HBM, охлаждаясь жидкостью.
- Ускорители уже стоят в 6-8 системах ТОП500; пиковая энергоэффективность 32 GFLOPS/Вт.
- Драйверы OpenCL/CUDA-аналог ZCL, компиляторы Fortran/C++ готовы; в 2026-2027 ждут SC6 (128 TFLOPS FP64, 7 нм) и SC7 (E级, 3 нм).
- Цель: 10× экономия энергии и долгая независимость от NVIDIA/Intel.
Комментарии (74)
- Япония развивает собственные HPC-акселераторы (Pezy и др.), ориентированные на FP64 и традиционные суперкомпьютерные задачи, а не на ИИ-низкоточность.
- Эти чипы создаются под кластеры с жидкостным охлаждением и продаются не поштучно, а целыми стойками.
- Производительность FP64 у Pezy конкурентна с NVIDIA, но энергоэффективность и программное окружение NVIDIA пока непревзойдены.
- Японские компании и государство инвестируют в HPC-экосистему, чтобы сохранить технологический суверенитет и не зависеть от американских GPU.
- Участники обсуждают, насколько целесообразно переключение на альтернативные форматы чисел (posits) и почему правительства продолжают финансировать «собственных лошадей» несмотря на риск провала.
Who Invented Backpropagation?
Кто изобрел обратное распространение ошибки (backpropagation)
Современный backpropagation (BP) впервые опубликовал в 1970 г. финский магистрант Сеппо Линнайнмаа [BP1][R7]; 2020 г. отмечали 50-летие метода. Предшественник — работа Келли 1960 г. [BPA].
BP — это обратный режим автоматического дифференцирования: стоимость вычисления градиента примерно равна стоимости прямого прохода. Линнайнмаа дал алгоритм для произвольных разреженных сетей и привёл код на FORTRAN; все современные фреймворки (TensorFlow и др.) опираются на его метод.
В 1960-е уже применяли цепное правило Лейбница для градиентного спуска в многослойных системах (Келли, Брайсон, Дрейфус и др.), но без учёта эффективности для разреженных сетей.
Первое применение BP к обучению весов нейросетей — Дрейфус 1973 г.; первое NN-специфическое описание — Вербос 1982 г. [BP2] (в диссертации 1974 г. его ещё нет).
Уже в 1967 г. Амари с учеником Сайто обучал пятислойный перцептрон SGD, получая внутренние представления; это было глубокое обучение задолго до 1980-х. Параллельно Ивахненко строил глубокие сети GMDH (с 1965 г.).
К 1985 г. вычисления подешевели в 1000 раз; Румелхарт и др. показали, что BP формирует полезные скрытые представления.
Комментарии (86)
- Суть спора: кто «изобрёл» backpropagation — Хинтон/Румелхарт (1980-е) или она была раньше в теории управления и автоматическом дифференцировании (1960-е, Kelley, Amari и др.).
- Большинство участников считают, что это лишь эффективное применение цепного правила, которое переоткрывалось множество раз.
- Юрген Шмидхубер подаётся как главный «скептик», обвиняющий академическое сообщество в игнорировании более ранних работ.
- Некоторые подчеркивают, что решающим стало не само «изобретение», а переход к GPU и масштабируемым фреймворкам в 2010-х.