Недавно услышал о CDF — он бы мог многое перенести на клиента.
Хотя лично я предпочел бы более многоуровневые архитектуры. Даже браузер разделил бы на части, по образу Opera mini. Значительную часть вычислений можно было бы выполнять на proxy.
В моих задачах эффективности javascript обычно хватает. Но сам язык на столько громоздок и ужасен, что писать я на нем не могу.
А эффективные языки, типа Scala, Clojure или Haskell кроме того еще и удобны. И я готов смириться с потерей производительности, лишь бы не писать на js.
Правда, пока программирование клиента мне удавалось спихивать на других. Но что так будет всегда я не уверен и пытаюсь разобраться с альтернативами.
Если вызов виртуальный, можно последовательность команд invoke и return выполнить в другом порядке — сначала освободить фрейм вызывающего метода, а потом создать фрейм вызываемого. То есть инлайнить вообще не обязательно.
Пусть у нас функция x, описанная в файле x.scala, последним оператором вызывает вызывает функцию y, описанную в y.scala. Когда компилятор обрабатывает x.scala ему нужен только интерфейс y. Вытаскивание кода функции y, что бы ее заинлайнить в x, усложнит сборку.
А если это вызов виртуального метода другого объекта? Или не виртуального, но из другого модуля компиляции? На уровне JVM это можно соптимизировать, на уровне языка сложнее.
Последнее время весь десктоп, который я вижу сделан поверх Eclipse. Включая дорогущие проприетарные софтины.
Кстати, о разных JVMах. А есть ли среди них какой-нибудь оптимизирующий хвостовые вызовы? Я вынужден переходить с функциональных языков на JVMные и некоторые привычки меня сильно подводят. А моделью безопасности Java я все равно не пользуюсь, так как весь код могу контролировать.
Значит что многие задачи, для которых хотелось применять Prolog, но в силу особенностей этого языка не получалось, должны хорошо решаться с помощью программирования в ограничениях. Но пока получается не сильно лучше.
Выписать метрику, в котором это отображение будет сжимающим не сложно, но и в рамках данной статьи не интересно.
Решать надо, потому что определение записано в виде уравнения, а не в виде алгоритма генерации новых элементов. В общем виде такие уравнения решаются с помощью оператора неподвижной точки y f = f (y f).
Гауссган как такой пример не подойдет?
Преподавать у меня плохо получалось — объяснить алгебраические типы Haskell школьникам я не смог. Теперь боюсь, что школьникам будет слишком сложно.
Но попробовать было бы интересно.
Дополнительные степени свободы упрощают поиск маневра, который позволит избежать аварийной ситуации. Так идти по одномерному канату опаснее, чем по плоскости :-).
Правда, у воздушного средства отсутствует возможность просто остановиться…
Идеальным решением и для самолетов, и для автомобилей, было бы совместное управление всем потоком — через автоматическую диспетчерскую или распределенную по участникам движения систему. Так как частных летающих штучек пока не много, внедрить такое в воздухе будет проще.
Да, классика. Знать его надо хотя бы для общего развития.
Только на нем с отрицательными утверждениями сложно работать. Сейчас надежда на «программирование в ограничениях».
Топология, на пальцах, это возможность определить, что последовательность объектов сходится к некому новому объекту.
Пределом последовательности последовательностей будет такая последовательность, которая в каждой позиции отличается только от конечного числа исходных.
Неподвижной точкой называют решение уравнения x = f(x) по x. Если на множестве допустимых x определена топология, то может повезти и вычисляя f(f(.....f(f(x0))....)) мы будем приближаться в решению уравнения.
В данном случае для вычисления первых N элементов последовательности f(x) нам достаточно N-1 элемента последовательности x. Тогда выбрав правильную первоначальную (с конечной длиной) последовательность и применяя к ней функцию в цикле, мы будем получать все новые и новые элементы исходной последовательности.
Хотя обычному программисту это знать не обязательно, только для математического доказательства правильности программ.
А между вызовом встроенной и пользовательской функцией разница заметна? Сейчас проверить не могу, но предпологаю, что пользовательские функции будут проигрывать замыканиям не столь сильно.
IMHO, грань между программированием и моделированием очень тонкая, если вообще существует. Та же модель может управлять реальным устройством. Или не реальным, а торговать на бирже, например.
С именованием у меня проблемы. Как придумаю нормальные имена обещаю исправить :-).
l[lh][12] — это длины реек.
co — коэфициент зависимости тока через катушку и ускорением снаряда. sp — скорость.
Гауссган в этой модели ускоряет постоянный магнит. При расстоянии до соленоида большем 0.2 сила притяжения обратно пропорциональна четверной степени (как между двумя диполями). Если растояние становится меньше, сила пропорциональна расстоянию (длине не втянутой части магнита). Катушка подключена к источнику постоянной ЭДС с некоторым внутренним сопротивлением.
На этой модели был замечен интересный эффект — снаряд отскакивал от катушки, создавая там большую ЭДС, чем у внешнего питания.
Хотя лично я предпочел бы более многоуровневые архитектуры. Даже браузер разделил бы на части, по образу Opera mini. Значительную часть вычислений можно было бы выполнять на proxy.
А эффективные языки, типа Scala, Clojure или Haskell кроме того еще и удобны. И я готов смириться с потерей производительности, лишь бы не писать на js.
Правда, пока программирование клиента мне удавалось спихивать на других. Но что так будет всегда я не уверен и пытаюсь разобраться с альтернативами.
Пусть у нас функция x, описанная в файле x.scala, последним оператором вызывает вызывает функцию y, описанную в y.scala. Когда компилятор обрабатывает x.scala ему нужен только интерфейс y. Вытаскивание кода функции y, что бы ее заинлайнить в x, усложнит сборку.
Scala это умеет не всегда, к сожалению.
Кстати, о разных JVMах. А есть ли среди них какой-нибудь оптимизирующий хвостовые вызовы? Я вынужден переходить с функциональных языков на JVMные и некоторые привычки меня сильно подводят. А моделью безопасности Java я все равно не пользуюсь, так как весь код могу контролировать.
Странно, что 1 медленнее чем 2.
То, что 5 так тормозит, неприятно, но будем учитывать.
Решать надо, потому что определение записано в виде уравнения, а не в виде алгоритма генерации новых элементов. В общем виде такие уравнения решаются с помощью оператора неподвижной точки y f = f (y f).
Преподавать у меня плохо получалось — объяснить алгебраические типы Haskell школьникам я не смог. Теперь боюсь, что школьникам будет слишком сложно.
Но попробовать было бы интересно.
Правда, у воздушного средства отсутствует возможность просто остановиться…
Идеальным решением и для самолетов, и для автомобилей, было бы совместное управление всем потоком — через автоматическую диспетчерскую или распределенную по участникам движения систему. Так как частных летающих штучек пока не много, внедрить такое в воздухе будет проще.
Только на нем с отрицательными утверждениями сложно работать. Сейчас надежда на «программирование в ограничениях».
Пределом последовательности последовательностей будет такая последовательность, которая в каждой позиции отличается только от конечного числа исходных.
Неподвижной точкой называют решение уравнения x = f(x) по x. Если на множестве допустимых x определена топология, то может повезти и вычисляя f(f(.....f(f(x0))....)) мы будем приближаться в решению уравнения.
В данном случае для вычисления первых N элементов последовательности f(x) нам достаточно N-1 элемента последовательности x. Тогда выбрав правильную первоначальную (с конечной длиной) последовательность и применяя к ней функцию в цикле, мы будем получать все новые и новые элементы исходной последовательности.
Хотя обычному программисту это знать не обязательно, только для математического доказательства правильности программ.
Эту модель я быстро наборосал, что бы оценить сложность управления таким манипулятором.
С именованием у меня проблемы. Как придумаю нормальные имена обещаю исправить :-).
l[lh][12] — это длины реек.
co — коэфициент зависимости тока через катушку и ускорением снаряда. sp — скорость.
Гауссган в этой модели ускоряет постоянный магнит. При расстоянии до соленоида большем 0.2 сила притяжения обратно пропорциональна четверной степени (как между двумя диполями). Если растояние становится меньше, сила пропорциональна расстоянию (длине не втянутой части магнита). Катушка подключена к источнику постоянной ЭДС с некоторым внутренним сопротивлением.
На этой модели был замечен интересный эффект — снаряд отскакивал от катушки, создавая там большую ЭДС, чем у внешнего питания.