Основные требования

Метания, которые мы претерпели и продолжаем претерпевать с архитектурой JInterval проистекают (как обычно) из желания удовлетворить многие конфликтующие требования:

1. Обеспечить относительный комфорт в кодировании для пользователя при использовании библиотеки в первую очередь за счет прозрачности общей архитектуры. Этому, конечно, здорово мешает природная синтаксическая невыразительность Java, то же отсутствие перегружаемых операторов. Поэтому у меня тоже возникали мысли о двухэтажной конструкции по типу "C-шное ядро/С++-ный интерфейс". В этом смысле я тоже присматривал (пока что не очень глубоко в них окунаясь) языки-кандидаты с "гуманным " синтаксисом и реализацией поверх JVM: Groovy, Ruby и т.п. Так что я очень обрадовался, когда прочел Ваши мысли о Scala и Fortress. Повыбираем. Может даже этот выбор не обязан быть единственным. Однако движение в этом направлении - развития надстроек, - на мой взгляд, не должно снимать озабоченности о том, чтобы и Java-фундамент для этих надстроек был спроектирован красиво и удобно (насколько это возможно).

2. Обеспечить гибкость и расширяемость библиотеки в смысле различных арифметик.

Сейчас у нас есть (правда, местами не совсем полные и не настолько чистые, как Ваши) реализации IR*, KR. К ним еще должны добавиться комплексные арифметики. С одной стороны, многие арифметики естественно обладают общими чертами и есть соблазн как-то это родство обобщить в стандартизованых интерфейсах. С другой стороны, это родство может быть весьма косвенным и в этом случае эти интерфейсы теряют смысл. Здесь у нас пока неопределенность.

3. Обеспечить гибкость в выборе базового типа для концов интервалов.

Изначальный настрой на гибкость в этом смысле был слегка поколеблен после столкновений с мнениями вроде "А кому вообще нужны какие-то базовые типы кроме double или, в крайнем случае, IEEE-стандартизованных типов?". Здесь Ваши эксперименты с BigBinary меня весьма порадовали, как косвенная поддержка взглядов, альтернативных цитированным.

4. Обеспечить гибкость в выборе политик округления.

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

5. Обеспечить производительность вычислений.

Этот момент нас занимал в предыдущий год, пожалуй, более остальных. Проведен ряд экспериментов, показавших неравноценность (в смысле производительности) различных синтаксических конструкций в Java (например, сходного кода, основанного на использовании а) абстрактных классов и б) интерфейсов и т.п.). Кроме того, хотелось оценить производительность PureJava-вычислений на фоне native С- или Fortran-кода. Наши результаты (для x86) говорят о том, что разница, если и есть, то очень невелика. Это, а также результаты различных обсуждений, привели нас к мысли не сосредоточиваться (по крайней мере, на первых порах) на реализации native-версий для различных платформ, а заняться разработкой переносимого чисто JVM-ного кода, который в первую очередь задает интерфейс взаимодействия с библиотекой. Конечно этот стандартный интерфейс не исключает его дальнейшей реализации путем использования дополнительных native-запчастей. Опять-таки я отметил про себя, что Ваши усилия по сравнению производительности различных вариантов взаимодействия с native-кодом на различных платформах существенно расширяют наши взгляды на этот вопрос и должны быть учтены в архитектуре и JVM-ного ядра. В частности, любопытна идея со стековой машиной, которая дает не только более эффективный вариант взаимодействия с внешними библиотеками, но может отчасти и повлиять на стиль общения с библиотекой пользователя.

6. Обеспечить возможность естественного наращивания и надстраивания высокоуровневого функционала

Не хотелось бы, чтобы библиотека оказалась еще одной низкоуровневой реализацией арифметик, а давала бы конечному пользователю "решалки" содержательных задач. Поэтому выстраивание нижних функциональных слоев должно производиться с учетом этого требования. Что касается принципиальной схемы разделения слоев, которую Вы могли видеть в слайдах, С.П.Шарый предложил добавить слой "три с половиной" - некий аналог BLAS (по его роли). Такой слой был бы востребован на верхних уровнях и предлагал бы эффективные реализации "популярных" интервальных операций линейной алгебры и некоторые прочие).

7. Обеспечить переносимость библиотеки

Собственно одним из мотивов разрабатывать именно Java-библиотеку для нас было желание создать инструменты, которые могли бы работать на максимально широком наборе платформ. С привязкой к конкретной платформе(-мам) во многом утрачивается смысл писать на Java, JVM. Поэтому улучшения, привносимые native-добавками, конечно, очень серьезно могут повлиять на производительность вычислений, но все-таки они должны быть именно расширениями, добавками.

Конечно, хочется избежать фанатизма в попытках учесть все эти требования. Ясно, что объять необъятное еще никому не удавалось и поэтому, может быть, способ взаимоувязки противоречивых требований во многом должен состоять в умеривании аппетитов по многим фронтам. Вопрос только в том, где разумные границы и чем мы готовы жертвовать в первую очередь, а чем - в последнюю. Для меня здесь приоритеты (на данный момент, и это не является незыблемой позицией) распределяются так (в порядке убывания):

Библиотека должна быть:

1) понятна и удобна пользователю (иначе насколько бы замечательной в остальных смыслах она бы ни была, вряд ли ею кто-то станет пользоваться);

2) гибка к расширению как в смысле арифметик, так и в смысле функционала;

3) гибка в отношении базовых типов и связанных с ними политик округления;

4) переносима;

5) высокопроизводительна.

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

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

А еще меня заботят чисто организационные моменты, которые тем более важными становятся, чем быстрее растет количество участников проекта. К сожалению, у меня нет опыта участия в больших open-source проектах, которые ведутся большими сообществами, и в которых имеются как инструментальная (хостинг проекта и т.п.), так и организационная платформа для взаимодействия сообщества, выработки, документирования и реализации решений и т.п. Тем не менее хотелось бы как-то упорядочить эти моменты, воспользовавшись какими-то готовыми рецептами. Одна из горящих потребностей этого плана - формальные правила, регламентирующие стиль кодирования (Вы могли видеть в исходниках к чему приводит их отсутствие). Нет ли у Вас каких-то опыта/рекомендаций на этот счет?