Насчёт сверхпроводника. Там у него какая-то особая структура, которая создаёт хитрое магнитное поле? Просто магнитики стремились находиться над ним в одном месте, как в «яме». Или какое-то другое этому объяснение?
Непосредственно в данном примере — пока никак. Но на мой взгляд, это чисто технические трудности. Мне кажется, что вполне возможно тем или иным способом реализовать объёмный сенсор, который будет реагировать на жесты руки пользователя в определённом пространстве (вспоминаем кинект).
Статья интересная, спасибо.
Реализация стека (вернее, односвязного списка) с помощью стека вызовов — весьма известная техника функционального программирования. Кстати, не так давно была ещё одна статья на эту тему, с примерами на Scheme и Javascript: habrahabr.ru/post/176233/ В ней, правда, немного другая техника, но на мой взгляд очень похоже.
Спасибо за статью.
У меня в планах тоже написать статью по Hakyll, in-depth можно сказать. Я его довольно основательно подогнал под себя. Внутри он устроен очень интересно и гибко, одно удовольствие его конфигурить)
Насчёт генерации и регистрации одиночных фотонов. Генерация одного фотона это на самом деле нетривиально (недавняя статья), поэтому, кстати, изначально двухщелевой опыт провели на электронах, и только впоследствии на фотонах. А насчёт регистрации — используется вполне себе обычная качественная фотоплёнка, как для фотонов, так и для электронов — см. картинку здесь.
Тот опыт, который вы хотели повторить, то есть двухщелевой опыт с источником света, дающим много фотонов, называется опытом Юнга и был проведён ещё в начале 19 века. Я очень сомневаюсь, что вы смогли прорезать в фольге полосы толщиной максимум микрометр. Плюс для наблюдения интерференции источник света должен испускать когенертный свет, например, это может быть лазер. Без этого интерференционные полосы вы наблюдать не сможете.
Про перенос даты не могу не согласиться, хотя, наверное, я имею в виду немного другое. Я следил за JDK8 внимательно только с конца прошлого года, и там в списке майлстоунов было написано, что релиз (General Availability) будет в мае-июне. Однако около конца февраля-начала марта дата релиза сдвинулась на сентябрь…
И ещё странно, что в самом JDK8 лямбды есть уже давно, но нет библиотеки потоков для работы с коллекциями. Зато есть отдельная сборка, в которой эти библиотеки есть.
Неправда. Java 8 даёт возможность использования замыканий вполне себе официально: jdk8.java.net/lambda/
По небольшому опыту использования JDK8 могу сразу сказать, что джава очень много приобрела с поддержкой лямбд.
Извините, а разве набла — это не математический язык? Дивергенция и скалярное умножение на набла суть одно и то же, разве нет? По крайней мере, при заданной системе координат.
Ну в таком случае она слегка странная и я не знаю на кого рассчитанная, потому что, мне кажется, вопросы о том, откуда, собственно, взялись числа, которыми модель оперирует, лежат на поверхности. Без ответа на них получается просто какая-то магия — взяли пару чисел с потолка, перемножили их на другие числа с того же потолка и ВНЕЗАПНО получили корректный в экспериментальном плане результат. Странно это.
Тем не менее, статья интересная и познавательная. Интересно почитать, что там будет дальше.
Я понимаю. Однако это возвращает нас к исходному вопросу — почему числа, на которые производится умножение состояний (да и сами состояния тогда) именно такие? В случае с одним фотоном это вроде бы объясняется непосредственным «поворотом» самого фотона, ну или его траектории. А в случае с двумя фотонами?
То есть, получается, что такой выбор коэффициентов, на которые происходит умножение на зеркалах, это всего лишь повороты на плоскости. Ок, спасибо, я подозревал это, но мне показалось, что это слишком просто.
Сейчас ещё раз перечитал статью. В самом начале у нас опыт уже с двумя фотонами, и для них также отражение означает умножение на -i. Но это же два фотона, они отражаются в разные стороны. Если их как целое рассматривать, то здесь нет одного поворота. Или я чего-то ещё не понимаю?
Хотел спросить ещё в предыдущей статье, но тогда не мог из-за ридонли.
Почему в статях выбраны именно такие начальные значения комплексных амплитуд, и почему отражение от зеркала/прохождение сквозь зеркало фотонов описывается умножением именно на такие величины? Например, почему отражение от зеркала — это именно i (или -i?), а не, допустим, -1? Я уверен, что у этих значений есть вполне конкретное объяснение, но в статье автор, судя по всему, намеренно его не даёт, а придумать, как поискать в гугле на эту тему, я не могу.
Еще вопрос об interopobillity. Это конечно здорово что язык JVM-ный и что можно использовать многие JVM библиотеки, но согласитесь, лучше всегда иметь idiomatic обертку, а не пулять null-и направо и налево. А поскольку язык, по понятным причинам, не на широкого пользователя, то такие обертки придется писать Вам самому, на каждый чих.
Обёртки на каждый чих придётся писать только если у вас либо много легаси-кода на джаве, с которым необходимо взаимодействовать, либо если у вас в проекте используется очень много java-библиотек, к которым никто ещё не написал обёртки. Не могу сказать, что это случай большинства проектов. Как правило, в проектах используются либо pure Clojure-библиотеки (та же Compojure или, например, Hiccup), либо уже готовые и обычно достаточно качественные обёртки (например, clj-time для Joda Time или Ring для Jetty).
При этом, если действительно будет нужно, писать обёртки для библиотек в Clojure не то что не сложно, а очень просто. Во-первых, это всё же не взаимодействие на бинарном уровне, как между компилируемыми языками, а в рамках одной платформы. Во-вторых, интероп в Clojure очень хорошо продуман. Прямо из Clojure можно генерировать обычные классы практически любой сложности, а те ограничения, что есть, абсолютно несущественны для обеспечения интерфейса к библиотекам. Можно сказать, что Clojure предоставляет настолько широкие возможности для взаимодействия с объектно-ориентированной средой Java, насколько это вообще возможно для не-ОО языка. В самых распространённых случаях создание класса, реализующего какой-нибудь интерфейс для сторонней библиотеки выглядит так, как реализация протокола в примере кода в посте.
Также если сама библиотека на Java сделана хорошо, то к ней и обёртки не особо могут быть нужны. Вызов методов синтаксически почти не отличается от вызовов функций, поэтому можно использовать непосредственно саму библиотеку, без обёрток.
Clojure — язык общего назначения, применять его можно куда угодно. На нём можно писать и полноценные вебсайты (причём очень удобно и просто, гораздо проще чем, например, с использованием Java-фреймворков), и довольно сложные вычисления (я писал на нём несколько не самых простых лаб по вычислительной математике, пришлось, правда, использовать много низкоуровневой магии чтобы была достаточная производительность, но ничего чересчур сложного там нет).
Интересный факт: в Clojure нет огромного стандартного стека для веб-приложений, такого, как, например, JSF+EJB3+сервлеты в джаве (хотя никто не мешает писать сервлеты на Clojure — я пробовал, и это гораздо лучше, чем на джаве). Хоть в джаве и есть много фреймворков для создания веб-приложений, но все они так или иначе основаны на JavaEE (за очень редкими исключениями), и все они достаточно объёмны и тяжеловесны и тащат огромное множество зависимостей вплоть до ещё более объёмных серверов приложений. Вместо этого в Clojure есть несколько слабо связанных слоёв, представленных одной или несколькими наиболее используемыми библиотеками, которые можно комбинировать в любом порядке. При этом каждая библиотека по отдельности минимальна по размеру и очень проста в использовании. Типичная структура веб-приложения на Clojure — Ring как HTTP-платформа (то есть слой общения с сетью, как правило, с использованием Jetty) + Compojure для роутинга запросов и в качестве основы для написания middleware + sqlkorma для абстракции работы с БД. По вкусу — один из множества шаблонизаторов (Enlive, Hiccup и другие). Простейшее standalone-приложение состоит из 2 файлов — project.clj для сборки Leiningen'ом и один файл с кодом обработчика HTTP-запросов, всё вместе — не более сотни строк. При этом общую структуру даже при развитии проекта практически невозможно испортить — пространства имён в качестве единицы инкапсуляции дают очень большую гибкость в построении и развитии архитектуры.
Также я вообще не видел, где можно так же удобно писать GUI-программы, как на Clojure, если только вы не испытываете отвращения к Swing — с помощью потрясающей библиотеки Seesaw. Seesaw предоставляет декларативное описание интерфейсов плюс очень здорово спроектированый набор функций и протоколов для работы практически со всеми функциями Swing, а также много всяких дополнительных мелочей, вроде базовой реализации FRP (Functional Reactive Programming) для интерфейсов — декларативное описание потоков данных в интерфейсе и реакций на события. Я думал, что на Swing невозможно писать GUI без боли, а оказывается, что на Swing можно писать GUI с большим удовольствием)
Я бы ещё добавил, что в прямом соответствии с идеологией «Simple made easy» в Clojure просто потрясающе сделан интерфейс взаимодействия с коллекциями данных и вообще со структурами. Все коллекции обрабатываются единообразно за счёт абстракции «последовательности». Для доступа к элементам последовательностей есть много функций, обычных и высшего порядка, которые позволяют получить желаемый результат вне зависимости от того, работают ли они со списком, вектором или множеством (а иногда и словарём). Близкая к этому тема — ленивые коллекции, которые используются повсюду в языке. Они тоже являются «последовательностями», поэтому работа с ними не отличается от работы, например, с вектором, но при этом у них ленивая семантика.
Вообще стандартная библиотека Clojure великолепна. Особенно если сравнить её с библиотекой, например, Common Lisp. Единообразие, логичность и принцип наименьшего удивления во все поля, при этом мощность не страдает.
Странно. Несколько страниц одного блога вордпресс, который я читаю, отображаются как заблокированные.
Примерно процентов десять. Никакого паттерна в блокировке не заметно…
Насчёт сверхпроводника. Там у него какая-то особая структура, которая создаёт хитрое магнитное поле? Просто магнитики стремились находиться над ним в одном месте, как в «яме». Или какое-то другое этому объяснение?
Assertion `!close(fd)' failed, на арче 3.8.7zsh: killed ./semtex.Вспомнились hud'ы у Чен Хо.
Реализация стека (вернее, односвязного списка) с помощью стека вызовов — весьма известная техника функционального программирования. Кстати, не так давно была ещё одна статья на эту тему, с примерами на Scheme и Javascript: habrahabr.ru/post/176233/ В ней, правда, немного другая техника, но на мой взгляд очень похоже.
У меня в планах тоже написать статью по Hakyll, in-depth можно сказать. Я его довольно основательно подогнал под себя. Внутри он устроен очень интересно и гибко, одно удовольствие его конфигурить)
Тот опыт, который вы хотели повторить, то есть двухщелевой опыт с источником света, дающим много фотонов, называется опытом Юнга и был проведён ещё в начале 19 века. Я очень сомневаюсь, что вы смогли прорезать в фольге полосы толщиной максимум микрометр. Плюс для наблюдения интерференции источник света должен испускать когенертный свет, например, это может быть лазер. Без этого интерференционные полосы вы наблюдать не сможете.
И ещё странно, что в самом JDK8 лямбды есть уже давно, но нет библиотеки потоков для работы с коллекциями. Зато есть отдельная сборка, в которой эти библиотеки есть.
Неправда. Java 8 даёт возможность использования замыканий вполне себе официально: jdk8.java.net/lambda/
По небольшому опыту использования JDK8 могу сразу сказать, что джава очень много приобрела с поддержкой лямбд.
Тем не менее, статья интересная и познавательная. Интересно почитать, что там будет дальше.
Сейчас ещё раз перечитал статью. В самом начале у нас опыт уже с двумя фотонами, и для них также отражение означает умножение на -i. Но это же два фотона, они отражаются в разные стороны. Если их как целое рассматривать, то здесь нет одного поворота. Или я чего-то ещё не понимаю?
Почему в статях выбраны именно такие начальные значения комплексных амплитуд, и почему отражение от зеркала/прохождение сквозь зеркало фотонов описывается умножением именно на такие величины? Например, почему отражение от зеркала — это именно i (или -i?), а не, допустим, -1? Я уверен, что у этих значений есть вполне конкретное объяснение, но в статье автор, судя по всему, намеренно его не даёт, а придумать, как поискать в гугле на эту тему, я не могу.
Обёртки на каждый чих придётся писать только если у вас либо много легаси-кода на джаве, с которым необходимо взаимодействовать, либо если у вас в проекте используется очень много java-библиотек, к которым никто ещё не написал обёртки. Не могу сказать, что это случай большинства проектов. Как правило, в проектах используются либо pure Clojure-библиотеки (та же Compojure или, например, Hiccup), либо уже готовые и обычно достаточно качественные обёртки (например, clj-time для Joda Time или Ring для Jetty).
При этом, если действительно будет нужно, писать обёртки для библиотек в Clojure не то что не сложно, а очень просто. Во-первых, это всё же не взаимодействие на бинарном уровне, как между компилируемыми языками, а в рамках одной платформы. Во-вторых, интероп в Clojure очень хорошо продуман. Прямо из Clojure можно генерировать обычные классы практически любой сложности, а те ограничения, что есть, абсолютно несущественны для обеспечения интерфейса к библиотекам. Можно сказать, что Clojure предоставляет настолько широкие возможности для взаимодействия с объектно-ориентированной средой Java, насколько это вообще возможно для не-ОО языка. В самых распространённых случаях создание класса, реализующего какой-нибудь интерфейс для сторонней библиотеки выглядит так, как реализация протокола в примере кода в посте.
Также если сама библиотека на Java сделана хорошо, то к ней и обёртки не особо могут быть нужны. Вызов методов синтаксически почти не отличается от вызовов функций, поэтому можно использовать непосредственно саму библиотеку, без обёрток.
Интересный факт: в Clojure нет огромного стандартного стека для веб-приложений, такого, как, например, JSF+EJB3+сервлеты в джаве (хотя никто не мешает писать сервлеты на Clojure — я пробовал, и это гораздо лучше, чем на джаве). Хоть в джаве и есть много фреймворков для создания веб-приложений, но все они так или иначе основаны на JavaEE (за очень редкими исключениями), и все они достаточно объёмны и тяжеловесны и тащат огромное множество зависимостей вплоть до ещё более объёмных серверов приложений. Вместо этого в Clojure есть несколько слабо связанных слоёв, представленных одной или несколькими наиболее используемыми библиотеками, которые можно комбинировать в любом порядке. При этом каждая библиотека по отдельности минимальна по размеру и очень проста в использовании. Типичная структура веб-приложения на Clojure — Ring как HTTP-платформа (то есть слой общения с сетью, как правило, с использованием Jetty) + Compojure для роутинга запросов и в качестве основы для написания middleware + sqlkorma для абстракции работы с БД. По вкусу — один из множества шаблонизаторов (Enlive, Hiccup и другие). Простейшее standalone-приложение состоит из 2 файлов — project.clj для сборки Leiningen'ом и один файл с кодом обработчика HTTP-запросов, всё вместе — не более сотни строк. При этом общую структуру даже при развитии проекта практически невозможно испортить — пространства имён в качестве единицы инкапсуляции дают очень большую гибкость в построении и развитии архитектуры.
Также я вообще не видел, где можно так же удобно писать GUI-программы, как на Clojure, если только вы не испытываете отвращения к Swing — с помощью потрясающей библиотеки Seesaw. Seesaw предоставляет декларативное описание интерфейсов плюс очень здорово спроектированый набор функций и протоколов для работы практически со всеми функциями Swing, а также много всяких дополнительных мелочей, вроде базовой реализации FRP (Functional Reactive Programming) для интерфейсов — декларативное описание потоков данных в интерфейсе и реакций на события. Я думал, что на Swing невозможно писать GUI без боли, а оказывается, что на Swing можно писать GUI с большим удовольствием)
Я бы ещё добавил, что в прямом соответствии с идеологией «Simple made easy» в Clojure просто потрясающе сделан интерфейс взаимодействия с коллекциями данных и вообще со структурами. Все коллекции обрабатываются единообразно за счёт абстракции «последовательности». Для доступа к элементам последовательностей есть много функций, обычных и высшего порядка, которые позволяют получить желаемый результат вне зависимости от того, работают ли они со списком, вектором или множеством (а иногда и словарём). Близкая к этому тема — ленивые коллекции, которые используются повсюду в языке. Они тоже являются «последовательностями», поэтому работа с ними не отличается от работы, например, с вектором, но при этом у них ленивая семантика.
Вообще стандартная библиотека Clojure великолепна. Особенно если сравнить её с библиотекой, например, Common Lisp. Единообразие, логичность и принцип наименьшего удивления во все поля, при этом мощность не страдает.
Примерно процентов десять. Никакого паттерна в блокировке не заметно…