пятница, 28 ноября 2008 г.

CouchDB

Посмотрел CouchDB топовый проект от Apache -- распределенная документориентированная база данных.
По моему она идеально подходит для задач MathCloud.
Интерфейс REST, формат единственный - JSON, что не страшно, хотя жалко что XML нету.

Поддерживает аттачменты.

Написана на Erlang :)

Надо разбираться и ставить.

вторник, 9 сентября 2008 г.

Условие на загрузку всех сложных видов данных.

Любой сложный параметр (и может вообще любой) может передаваться в виде ссылки.

REST-сервисы должны это распознавать и самостоятельно скачивать

пятница, 27 июня 2008 г.

упал рабочий сервер

http://dcs.isa.ru
Сервер в данный момент в починке, до его оживления в Вебе примеров пока нет.

среда, 4 июня 2008 г.

Коллеги

http://www.hubzero.org/

Буду смотреть, через некоторое время напишу свои мысли.
Вообще их наличие уже говорит что направление "математика в Вебе" - правильное.

вторник, 3 июня 2008 г.

воскресенье, 1 июня 2008 г.

рисунки в стиле Эшера

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

http://dcs.isa.ru/taras/mathnet/applications/escher.html

Пример того, что можно получить: 1 2

пятница, 30 мая 2008 г.

генерация фракталов

Собрал приложение которое генерирует фрактал по двум заданным движениям.

Это мне нужно для своих задачек, плюс для проверки концепций MathCloud

http://dcs.isa.ru/taras/mathnet/applications/reptilies.html


Должен работать под FF и IE.

В CGAL есть функции объединения многоугольников. Надо будет её прикрутить.
А пока фрактал выглядит как папье-маше.

первые собраные шишки

Не получается нормально совмещать IE и SVG.

От SVG отказывается не хочется. Это более удобный формат для математических объектов чем растровые картинки.

По видимому часть приложений будет работать только под FireFox.
Мне кажется проще математикам поставить нужный браузер.
Кроме того это проблема специфичная именно для комбинаторной геометрии, для которой я стараюсь сначала набрать базу сервисов и приложений. А вообще для MathCloud это не обязательно.

В общем часть приложений будет работать только под FF.

пятница, 23 мая 2008 г.

полигоны

Планирую сделать сервисы для работы с решетками:
генератор кристаллографических групп.
действие этими группами на объект (пока только многоугольник).

Из этого в частности можно сделать просмотр разнообразных решеток и разбиений на плоскости.

Еще можно сделать рисунков в стиле Эшера, когда некоторые животные регулярно заполняют плоскость.

Сделал отрисовку многоугольников:
Голый REST: http://dcs.isa.ru/taras/mathnet/polygon2svg.html
Приложение http://dcs.isa.ru/taras/mathnet/points_input/points_polygon.html


Многоугольник задается в следующем формате:
N_points p1x p1y p2x p2y ... pnx pny


Сделал преобразование многоугольника под действием движения:
Голый REST сервис: http://dcs.isa.ru/taras/mathnet/polygontransform.html
движение задается в JSON формате m - матрица, t - параллельный перенос
матрица только транспонированная получилась.

Типов становится все больше... пора заводить описание типов.

четверг, 22 мая 2008 г.

Описание REST-сервисов

В отличие от RPC-систем (CORBA и т.д.), методы в REST зафиксированы, их немного и семантика их общеизвестна. Поэтому основной задачей является описание структур данных, отправляемых этим фиксированным методам и получаемых обратно.
В первом приближении можно обойтись просто схемой данных. Для XML это XML Schema (стандарт, наиболее громоздкий вариант), RELAX NG, Schematron и т.п. Для JSON схема пока только формируется сообществом. По аналогии с XML Schema, JSON Schema оформляется на JSON (см. драфт спецификации). Другие примеры схем для JSON:
  • JSONR - интересен генерацией Web-форм с валидацией;
  • Kwalify - схема для формата YAML, частным случаем которого можно считать JSON, интересен наличием валидаторов на Java и Ruby.
Помимо этого есть стандартные форматы данных в Web, так называемые MIME-типы. Другое дело, что для картинки достаточно MIME-типа, а для JSON нужно еще знать схему содержимого.
Вариант с использованием только схемы данных неудобен тем, что за рамками описания остается то, куда (на какой URL) и какому HTTP-методу какие из описанных структур данных отправляются. То есть описание собственно интерфейса REST-сервиса. Есть два подхода к решению этой проблемы.
Первый (пропагандируемый REST-гуру) - использовать любой удобный и понятный всем разработчикам формат для записи этой информации. Этот формат может быть специфичным для определенной прикладной области. В конце концов, если используются все время одни и те же методы по шаблонным URI, то можно один раз оформить спецификацию такого протокола. То же касается и форматов данных. Пример такого подхода - Atom Publishing Protocol (как и по каким URL вызвать методы) + Atom Syndication Format (формат передаваемых данных). См. также эту статью. Кстати, AtomPub это возможно то, что надо для реализации каталога сервисов. Важно подчеркнуть, что AtomPub-клиенты реализуют, только читая спецификации и не прибегая к средствам генерации кода.
Второй подход (как в RPC и "Web"-сервисах на SOAP) - создается декларативный язык описания интерфейсов (Interface Definition Language, IDL) наподобие CORBA IDL и WSDL. После чего из описаний на этом языке специальным компилятором генерируется код для реализации и вызова сервиса на требуемом языке программирования. Этот код повторяет интерфейс сервиса, обеспечивает контроль типов и скрывает внутри манипуляции с форматами данных (сериализацию). При описании параметров IDL может ссылаться на те же схемы данных. Например, WSDL использует XML Schema. Для REST наиболее известной попыткой создать нечто подобное является Web Application Description Language (WADL).
О том, какой из этих двух подходов лучше для REST, - в следующий раз.

среда, 21 мая 2008 г.

REST База данных

Amazon SimpleDB это конечно хорошо, но платно. А хотелось бы иметь какую нибудь базу данных в которую другие REST сервисы могли предоставлять доступ другим сервисам к каким-то своим данным и т.п. Мне кажется применения для этой базы найдутся.
Натолканулся сегодня на apache couchdb. Она еще сыровата, но и сервисы у нас пока не супер стабильные. Сравнение с simpledb можно посмотреть тут. Базе данных быть.

PS. может быть по адресу couchdb.mathcloud.org?

диаграмма Вороного

Cделал редактор разбиения Вороного, точки теперь задаются не случайно, а редактируются.
http://dcs.isa.ru/taras/mathnet/points_input/points_voronoi.html

Это milestone, ура!

Сервис еще будет доводиться до ума, присылайте пожалуйста свои замечания и пожелания.
Ввод точек пока только из текста.

вторник, 20 мая 2008 г.

PARI/GP

Консольная CAS. Можно будет поприкручивать.

среда, 14 мая 2008 г.

Просмотр точек

Переделал просмотр точек. Теперь должно работать стабильней:

http://dcs.isa.ru/taras/mathnet/points_viewer.html

пример REST приложения

Генерация случайных диаграмм Вороного.

Состоит из следующих компонент:
rbox - генерация случайных точек
qvoronoi - генерация диаграмм Вороного в формате OFF
off2svg - преобразование двумерных данных формата OFF в формат SVG
off2svg может возвращать как сам результат, так и ссылку на SVG- файл. Используется второй вариант.


html страница- REST клиент на AJAX, опрашивающий соответствующие REST сервисы и в конце показывающий конечный результат - SVG файл.


В дальнейшем планируется добавить навигатор a la Google Maps.

Громадная просьба всем тестировать, комментировать, присылать свои предложения по улучшению, какие бы реальные приложения было бы интересно сделать.

qhull

Сделал оболочку к двум пограммам из пакета qhull:

RBOX -генератор случайных точек

Сам сервис здесь:
http://dcs.isa.ru/taras/mathnet/qhull.cgi/=/1.0/rbox

Пример использования:
http://dcs.isa.ru/taras/mathnet/test_rbox.html



qvoronoi - выдает области Вороного в формате OFF

Сервис http://dcs.isa.ru/taras/mathnet/qhull.cgi/=/1.0/voronoi
Пример использования:

http://dcs.isa.ru/taras/mathnet/voronoi_test.html

Кроме этого уже имеется сервис off2svg который переводит диаграмму
в SVG файл.

Из всего этого скоро будет сделано приложение, которое генерирует и показывает диаграмму Вороного.

четверг, 8 мая 2008 г.

CGAL

Большая библиотека алгоритмов вычислительной геометрии http://www.cgal.org/

off2m

На основе программы off2m из пакета antiprism сделан REST-сервис off2m
Тестовая страница лежит здесь.

Сервис преобразует многогранник заданный в формате OFF в код формате Mathematica, который можно просматривать через саму программу и апплет LiveGraphics3D.

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

OpenResty

Ищу уже готовый REST репозиторий файлов. Наткнулся на интересную библиотеку OpenResty.
Развивает её сотрудник Yahoo.cn Агент Жанг.

Это чистая REST библиотека которая позволяет складировать и пользоваться данными.
Результаты выдает в JSON в виде. Есть поддержка авторизации, капч.
Написана на перле, расчитана на взаимодействие с DB Postgres. Создается из расчета работы под высокой нагрузкой.

Для наших целей не хватает загрузки и выгрузки файлов. Однако сервис быстро развивается, и такая функциональность запланирована. Так что возможно скоро вся необходимая функциональность появится.

TODO

Здесь будет вести текущий список того, что желательно сделать в ближайшей и отдаленной перспективе.

  • Прикрутить библиотеку antiprism
  • Прикрутить библиотеку qhull
  • Прикрутить библиотеку polymake
  • Составить список библиотек интересных для интеграции
  • Компонента - просмотр двумерных изображений ( a la google maps)
  • Компонента - просмотр двумерных изображений в формате SVG
  • Универсальный репозиторий математических объектов.
  • Система создания сценариев работы REST приложений.
  • Система "компиляции" сценария в REST -приложение.
  • REST-сервис генерирующий заданные плоские решетки и разбиения.
  • Навигацию по плоскости Лобачевского.
  • REST-сервис генерирующий заданные решетки и разбиения на плоскости Лобачевского.
  • просмотр многогранников
  • сделать Wiki на этом сайте.

среда, 7 мая 2008 г.

Текущее состояние.

Сейчас происходит разведка боем. Создаются некоторые REST-сервисы на уровне proof of concept,
создаются сетевые приложения, собранные из этих REST-сервисов.

Отрабатывается схема устройства этих REST компонент и приложений на их основе.

В качестве примера (осторожно может зависать):
Просмотр FCC решетки.

Здесь можно просматривать некоторое подмножество FCC решетки
среди параметров:
способ вырезания подмножества: шар заданного радиуса или корона.
Радиус шара и короны.

Визуализация:
размер точек
способ окрашивания точек
способ окрашивания ребер (или не рисовать ребра или рисовать в соответствии с потенциалом Леннарда-Джонса).

Внизу есть ссылки на примеры разных комбинаций параметров.

Схема состоит из следующих компонент:
  • FCC-packing.cgi - REST модуль который выдает заданное подмножество FCC решетки ( плотнейшая упаковка в RR^3)
  • grid2m - REST Сервис преобразующий список точек в 3D изображение в формате Mathematica
  • REST Client - html страница которая на AJAX, вызывает соответствующие REST сервисы.
  • LiveGraphics3D - Java-апплет, визуализирующий данные в формате Mathematica.

Какие выводы можно сделать:

  • Идея вполне работоспособна. Эта не абстрактный пример, а вспомогательная система для изучения задач связанных с потенциалом Леннарда-Джонса и некоторый полезный вклад она уже внесла.
  • Проглядывается достаточно универсальная схема интеграции REST-сервисов через AJAX.
  • Перегрузка апплета делается очень жестоко и её надо переделывать.

Концепция MathCloud

Использование математических пакетов можно разделить на две категории:


  1. использование при доказательстве теорем.
  2. как инструмент исследования.

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

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

MathCloud предназначается в первую очередь для решения задач второго типа. Такие задачи характеризуются обычно относительно небольшой вычислительной сложностью и одноразовостью использования. Поэтому главный акцент в MathCloud должен быть на легкости создания подобных программ.

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

Кроме этого результаты должны быть наглядны и среда должна позволять играться - легко перезапускать задачу при различных начальных условиях.

Должна быть возможность легко обмениваться результатами.


Основные приоритеты среды MathCloud:


  • Максимальное повторное использование уже существующих компонент.
  • Простота создания компонент MathCloud, и простота подключения уже существующих библиотек.
  • Простота интеграции различных компонент в распределенное приложение.
  • Интерактивность и визуализация.
  • Взаимодействие людей в системе.

Почему именно REST?

В архитектуре REST есть два существенных преимущества:


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


  • Простота. REST значительно проще других технологий создания распределенных приложений. По нашему мнению это принципиально необходимое качество подобной архитектуры. Это обеспечит простую интеграцию существующих библиотек и широкое вовлечение людей в среду. Мы думаем, что REST является "убийцей" самой популярной на данный момент сервис-ориентированной архитектуры Webservices (SOAP).

Почему сервис-ориентированная архитектура?

Во первых REST это сервис-ориентированная архитектура.

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

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

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

Люди могут пользоваться вашей библиотекой не владея физически ни исходными кодами ни скомпилированными.

Зачем нужна распределенная среда?

Существуют замечательные мощные математические пакеты такие как Mathematica, MATLAB, Mapple и т.п. И если задачу можно решить используя свой любимый математический пакет, то собственно больше ничего и не нужно.

Однако помимо этого существует широкий класс различных математических библиотек, различной степени специализации, вплоть до отдельных программ написанных авторами для собственных нужд. Язык на котором написана та или иная библиотека тоже варьируется. Это может быть библиотека на основе вышеперечисленых пакетов, может быть програма на C, Fortran, Java, Pascal, может быть программа на каком либо специализированном языке программирования Haskell, Parralel Fortran и т.п.
Несмотря на неудобства, такая разнородность объективна, и нет доводов считать, что когда-либо ситуация изменится в лучшую сторону.

Для ряда задач было бы эффективно использовать сразу несколько различных пакетов.
При этом возникает задача интеграции разнородных пакетов между собой.

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

В таких случаях распределенная среда остается единственным способом интеграции разных пакетов между собой.

Что такое MathCloud?

Краткое описание:

MathCloud это математическая распределенная среда на REST архитектуре.

Математическая - значит помогающая при решении математических задач. Как например помогает пакет Mathematica. Помощь может быть разная - помогать при исследовании, выполнять сложные расчеты, создавать иллюстрации для статьи и т.п.

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

REST архитектура - Почитать про REST архитектуру можно например здесь. Эта относительно новая архитектура, которая гораздо проще известной на данный момент Webservices (SOAP) и на наш взгляд гораздо более подходящей для математических задач.


Взаимодействие с пользователем в MathCloud будет в основном идти через Web (через браузер), хотя мы не исключаем использование специальных программ.