Большинство записок об осуществлении включены в документацию по каждой функции или распределению. Эти примечания носят более общий характер и в большей степени отражают используемую общую философию осуществления.

Implementation philosophy

"Сначала будь прав, потом будь быстр"

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

Итак, наш приоритет - это точность.

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

(Это также требовало больших усилий процессора - была определенная опасность расплавленного пластика, сливающегося с нижней части ноутбука JM, поэтому вместо этого двухъядерный рабочий стол PAB был занят на 50% для days расчета некоторых таблиц тестовых значений!)

Для конкретного RealType, скажем float или ДП, может быть возможно найти аппроксимации для некоторых функций, которые проще и, следовательно, быстрее, но менее точны (возможно, потому, что нет рафинирующих итераций, например, при расчете инверсных функций).

Если они достаточно точны, чтобы быть «подходными для его цели», то пользователь может заменить свою специализацию.

Например, есть аппроксимации, относящиеся к временам, когда вычисления были lot дороже:

H Goldberg and H Levie, Approximate Formulas for percentage points and normalisation of t and chi squared, Ann. Math. Stat., 17(4), 216 - 225 (Dec 1946).

A H Carter, Approximations to percentage points of the z- Distribution, Biometrika 34(2), 352 - 358 (Dec 1947).

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

Accuracy and Representation of Test Values

Для того, чтобы быть достаточно точным для как можно большего количества реальных типов, постоянные значения присваиваются 50 десятичным цифрам, если таковые имеются (хотя многие источники доказали только точность около 64-битной двойной точности). Значения определяются как длинные двойные типы путем добавления L, если они точно не являются репрезентативными, например, целых чисел или бинарных фракций, таких как 0.125. Это позволяет избежать риска потери точности преобразования из двойного, по умолчанию типа. Значения используются после static_cast<RealType>(1.2345L) для предоставления соответствующей RealType для спотовых испытаний.

Функции, возвращающие константы, такие как куртоз, например, пишутся как

static_cast<RealType>(-3)/5;

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

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

static_cast<RealType>(1)/3;

Если функция очень чувствительна к изменениям в вводе, указывая неактуальное значение как ввод (например, 0.1) может выбросить результат на заметное количество: 0.1f «неправильно» на ~1e-7, например (потому что 0.1 не имеет точного бинарного представления). Именно поэтому точные бинарные значения - половинки, четвертины и восьмые и т.д. - используются в тестовом коде вместе с случайной долей a/b с b мощность двух (для обеспечения того, чтобы результат был точно репрезентативным бинарным значением).

Tolerance of Tests

Допуски должны быть установлены до максимума:

В противном случае, когда длинный двойник имеет больше цифр, чем данные теста, то никакое количество настройки толерантности на основе эпсилона не будет работать.

Общая проблема заключается в том, когда допуски подходят для реализации, например, Microsoft VS. NET, где двойные и длинные двойные имеют одинаковый размер: тесты терпят неудачу в других системах, где длинный двойник более точен, чем двойные. Проверьте сначала, что суффикс L присутствует, а затем, что допуск достаточно велик.

Handling Unsuitable Arguments

В Errors in Mathematical Special Functions, J. Marraffino & M. Paterno предлагается, чтобы сигнализация доменной ошибки была обязательной, когда аргумент даст математически неопределенный результат.

Грубо говоря, если функция идет к + бесконечности, а затем возникает «круглый спин» с - бесконечность, она НЕ определяется.

Эта реализация, как полагают, соответствует этим предложениям и помогает совместимости с ISO/IEC 9899:1999 Языки программирования - C и с Draft Technical Report on C++ Library Extensions, 2005-06-24, раздел 5.2.1, пункт 5. См. также domain_error.

См. policy reference для деталей политики обработки ошибок, которая должна позволить пользователю выполнять любую из этих рекомендаций, а также другое поведение.

См. error handling для подробного объяснения механизма и error_handling example и error_handling_example.cpp

	Caution
	Если вы позволяете бросить, но не имеете " пробного блока " , то программа будет прекращена с явным исключением и, вероятно, прервана. Поэтому для получения пользы от полезных сообщений об ошибках рекомендуется использовать все исключения и, используя Try&catch. Однако для простоты это не делается для большинства примеров.

Handling of Functions that are Not Mathematically defined

Функции, которые математически не определены, как Cauchy, не могут компилироваться по умолчанию. политика позволяет контролировать это.

Если политика заключается в том, чтобы разрешить неопределенные функции, то вызов их бросает ошибку домена по умолчанию. Но политика ошибок может быть установлена, чтобы не бросить, и вместо этого вернуть NaN. Например,

#define BOOST_MATH_DOMAIN_ERROR_POLICY ignore_error

появляется перед первым Boost включают, затем, если нереализованная функция называется, среднее (cauchy<>()) возвратит std::numeric_limits< T>::quiet_NaN().

	Warning
	Если std::numeric_limits<T>::has_quiet_NaN является ложным (например, если T является пользователем типа без поддержки NaN), то исключение всегда будет выброшено, когда возникает ошибка домена. Поэтому настоятельно рекомендуется делать исключения.

Median of distributions

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

Однако полезная численная аппроксимация для распространения dist доступна, как обычно, как функция участника, не являющегося членом, медиана с использованием median(dist), которая может быть оценена (в отсутствие аналитической формулы) путем вызова

quantile(dist, 0.5) (это определение математическое).

Mean, Median и Skew, Paul T von Hippel

Описательная статистика,

и

Mathematica Basic Statistics. дайте больше деталей, в частности, для дискретных дистрибутивов.

Handling of Floating-Point Infinity

Некоторые функции и распределения хорошо определены с + или - бесконечность как аргумент(ы), но после некоторых экспериментов с обращением с бесконечными аргументами в качестве особых случаев мы пришли к выводу, что было обычно более полезно запретить это, и вместо этого вернуть результат domain_error.

Рассмотрение бесконечности как особых случаев дополнительно сложно, потому что, в отличие от встроенных типов на большинстве - но не на всех платформах, не все пользовательские-определенные типы специализированы для обеспечения std::цифровые_ограничения<РеалType>:: бесконечность() и возвратит ноль, а не любое представление бесконечности.

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

Однако в нескольких случаях, например, в обычном режиме, когда мы чувствовали это очевидным, мы разрешили аргумент(ы) быть бесконечностью, при условии, что бесконечность будет реализована для RealType на эту реализацию, и она поддерживается и проверяется распределением.

Диапазон для этих дистрибутивов установлен на бесконечность, если поддерживается платформой, (по тестированию std::нумерные_ограничения<RealType>::has_infinity) еще максимальное значение, предусмотренное для RealType на Boost.Math.

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

Пока что мы не установили поддержка() функции (только диапазон) на том основании, что PDF является неинтересным/нулевой для бесконечностей.

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

Overflow, underflow, denorm может обрабатываться с помощью политики error обработок.

Мы также пытались поймать граничные случаи, когда математическая спецификация приведет к разделению на ноль или переполнению и сигнализирует об этом аналогично. То, что происходит на (и рядом), полюса могут контролироваться через политику error погрузочно-разгрузочных операций.

Scale, Shape and Location

Мы рассмотрели возможность добавления местоположения и шкалы в список функций, например:

template <class RealType>
inline RealType scale(const triangular_distribution<RealType>& dist)
{
  RealType lower = dist.lower();
  RealType mode = dist.mode();
  RealType upper = dist.upper();
  RealType result;  // of checks.
  if(false == detail::check_triangular(BOOST_CURRENT_FUNCTION, lower, mode, upper, &result))
  {
    return result;
  }
  return (upper - lower);
}

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

Notes on Implementation of Specific Functions & Distributions

Rational Approximations Used

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

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

Наши собственные приближения были разработаны либо для дополнительной точности (например, для поддержки 128-битных длинных двойников), либо потому, что методы литературы были недоступны или под лицензией, не совместимой с BSL. Наш кодекс Ремеза, как известно, дает хорошее согласие с литературными результатами в довольно простых «игровых» случаях. Все приближения были проверены на конвергенции и чтобы убедиться, что они не были плохо кондиционированы (коэффициенты могут дать теоретически хорошее решение, но полученная рациональная функция может быть несовместимой с фиксированной точностью).

Рекомендование с использованием различных ремеций вполне может привести к различным коэффициентам: хорошо известно, что проблема плохо поставлена в целом, и наша реализация Ремеза часто нашла широкую и неопределенную миниму для многих из этих приближений (конечно, для простых «игроков» примеров, таких как приближение exp минима хорошо определена, и коэффициенты должны согласовываться независимо от того, чья реализация Ремеза используется). Это не должно в целом влиять на обоснованность аппроксимаций: есть хорошая литература, поддерживающая идею о том, что коэффициенты могут быть «по ошибке» без обязательно отрицательного воздействия на результат. Обратите внимание, что «в ошибке» имеет особое значение в этом контексте, см. «Приблизительное построение рациональных приближений и эффект автокоррекции ошибок»., Григорий Литвинов, eprint arXiv:math/0101042. Поэтому коэффициенты все еще необходимо точно рассчитать, даже если они могут быть в ошибке по сравнению с «истинным» решением minimax.

Representation of Mathematical Constants

Макро BOOST_DEFINE_MATH_CONSTANT в константах. hpp используется для обеспечения высоких констант точности математических функций и дистрибутивов, так как важно обеспечить значения равномерно для как встроенных поплавковых, двойных и длинных двойных типов, так и для Пользователей Определенных типов в Boost.Multiprecision, как cpp_dec_float.

Чтобы разрешить расчеты в этом Math ToolKit и его тестах (и в других местах) примерно на 100 десятичных цифрах с типом NTL::RR, очевидно, необходимо определить константы с этой точностью.

Тем не менее, некоторые компиляторы не принимают строки десятичных цифр, пока это. Таким образом, константа разделена на две части, причем 1-я содержит по крайней мере длинную двойную точность, и 2-й ноль, если он не нужен или не известен. 3-я часть позволяет предоставить экспоненту, если это необходимо (использовать ноль, если таковой отсутствует), - другие два параметра могут содержать только десятичные цифры (и знак и десятичная точка), и не могут включать экспонент, подобный 1.234E99 (или след F или L). Вторая цифровая строка используется только в том случае, если T является типом, определяемым пользователем, когда константа преобразуется в длинный строковый буквальный и lexical_casted в тип T. (Это необходимо, потому что вы не можете использовать числовую константу, поскольку даже длинный двойной может не иметь достаточного количества цифр).

Например, pi определяется:

BOOST_DEFINE_MATH_CONSTANT(pi,
  3.141592653589793238462643383279502884197169399375105820974944,
  5923078164062862089986280348253421170679821480865132823066470938446095505,
  0)

И использовал таким образом:

using namespace boost::math::constants;
double diameter = 1.;
double radius = diameter * pi<double>();
or boost::math::constants::pi<NTL::RR>()

Обратите внимание, что необходимо (если это неудобно) четко указать тип.

Так что вы не можете писать

double p = boost::math::constants::pi<>();  // could not deduce template argument for 'T'

Вы также не можете писать:

double p = boost::math::constants::pi; // Context does not allow for disambiguation of overloaded function
double p = boost::math::constants::pi(); // Context does not allow for disambiguation of overloaded function

Thread safety

Отчетность об ошибке путем установки errno уже должна быть резьбой безопасной (в противном случае ни одна из математических функций std lib не будет резьбой безопасной?). Если включить сообщение об ошибках через исключения, errno все равно останется неиспользуемым.

Для нормального использования C ++, Boost.Math static const константы теперь резьба-безопасны для встроенных типов реального числа: float, ДП и long ДП все ниточки безопасны.

Для User_ defined types, например, cpp_dec_float, Boost. Математика также должна быть резьбой безопасной (хотя мы не уверены, как строго доказать это).

(Сохранность чтения получила внимание в пересмотре стандарта C++11, поэтому, надеюсь, все компиляторы в какой-то момент поступят правильно.)

Sources of Test Data

Мы нашли большое количество источников тестовых данных. Мы предположили, что это «известное добро», если они согласны с результатами нашего теста и только консультировались с другими источниками для их 'vote' в случае серьезных разногласий. Точность, фактическая и заявленная, очень сильно варьируется. Только функции Wolfram Mathematica обеспечили более высокую точность, чем C++ двойной (64-битная плавающая точка) и были расценены как наиболее надежный источник. Проект R для статистического вычисления предоставил самый широкий спектр дистрибутивов, но обычное распространение Intel X86 использует 64-но удвоится, поэтому наше использование было ограничено точностью от 15 до 17 десятичных цифр.

Полезным индексом источников является: Web-ориентированные педагогические ресурсы в вероятности и статистике

Статлет: Является ли Javascript приложением, которое рассчитывает и замышляет распределение вероятностей, и предоставляет наиболее полный диапазон дистрибутивов:

Он вычисляет pdf, cdf, выжившего, выжившего в журнале, опасность, хвостовые зоны и критические значения для 5 значений хвоста.

Это также единственный независимый источник, найденный для распределения Weibull; к сожалению, он страдает от очень низкой точности в районах, где основная специальная функция, как известно, трудно реализовать.

Testing for Invalid Parameters to Functions and Constructors

После того, как выяснилось, что некоторые «плохие» параметры (например, NaN) не бросали domain_error исключение, как они должны, функцию

check_out_of_range (в test_out_of_range.hpp) был разработан JM для проверки (с использованием Boost. Тест BOOST_CHECK_THROW макрос), который плохие параметры передали конструкторам и функциям, бросает domain_error исключения.

Использование check_out_of_range< DistributionType >(list--парамы>; Там, где список параметров действует параметры, из которых может быть построен дистрибутив - т.е. такое же количество аргов передается на функцию, как передаются распределителю.

Значения параметров не важны, но должны быть valid для прохождения проверок конструктора; значения по умолчанию подходят, но должны быть прямо предусмотрены, например:

check_out_of_range<extreme_value_distribution<RealType> >(1, 2);

Проводятся следующие проверки:

но делает не проверить конечные, но не диапазонные параметры для конструктора, потому что они специфичны для каждого распределения, например:

BOOST_CHECK_THROW(pdf(pareto_distribution<RealType>(0, 1), 0), std::domain_error);
BOOST_CHECK_THROW(pdf(pareto_distribution<RealType>(1, 0), 0), std::domain_error);

scale и shape параметры являются > 0, проверяя, что domain_error исключение выбрасывается, если они являются == 0.

(Использование функции check_out_of_range может означать, что некоторые предыдущие тесты теперь избыточны.

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

Creating and Managing the Equations

Уравнения, которые вписываются в одну строку, наиболее легко могут быть получены с помощью кода Quickbook с использованием шаблонов для символов Unicode Greek и Unicode Math. Все греческое письмо и небольшой набор символов Матема доступны на /boost-path/libs/math/doc/sf_and_dist/html4_symbols.qbk

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

Основным источником уравнений сейчас является MathML: см. файлы *.mml в libs/math/doc/sf_and_dist/equations/.

Они наиболее легко редактируются редактором GUI, таким как Mathcast, обратите внимание, что редактор уравнений, поставляемый с Open Office, в настоящее время использует эти файлы и не должен использоваться в настоящее время.

Преобразование в SVG было достигнуто с использованием SVGMath и командной строки, такой как:

$for file in *.mml; do
>/cygdrive/c/Python25/python.exe 'C:\download\open\SVGMath-0.3.1\math2svg.py' \
>>$file > $(basename $file .mml).svg
>done

См. также раздел «Использование Python для запуска Inkscape» и «Использование Inkscape для преобразования масштабируемых векторных файлов SVG в портативный сетевой графический PNG».

Обратите внимание, что SVGMath требует, чтобы ммл-файлы были not обернуты в обертку XHTML XML - это добавлено Mathcast по умолчанию - один обходной путь состоит в том, чтобы скопировать существующий ммл-файл и затем редактировать его с Mathcast: существующий формат должен быть сохранен. Это ошибка в XML-парсере, используемом SVGMath, о котором автор знает.

При необходимости обертка XHTML может быть удалена с:

cat filename | tr -d "\r\n" | sed -e 's/.*\(<math[^>]*>.*</math>\).*/\1/' > newfile

Настройка шрифтов для SVGMath в настоящее время довольно сложна, настройка шрифта системы Windows XP JM аналогична файлу настройки образца, предоставленному SVGMath, но с:

    <!-- Double-struck -->
    <mathvariant name="double-struck" family="Mathematica7, Lucida Sans Unicode"/>

изменено на:

    <!-- Double-struck -->
    <mathvariant name="double-struck" family="Lucida Sans Unicode"/>

Обратите внимание, что в отличие от файла с выборкой конфигурации, поставляемого с SVGMath, это не использует шрифт Mathematica 7, поскольку в нем отсутствует достаточная информация Unicode для использования с SVGMath или XEP "как есть".

Также обратите внимание, что SVG-файлы в репозитории почти наверняка специфичны для Windows, поскольку они ссылаются на различные фоны Windows.

PNG-файлы могут быть созданы из SVG с использованием Batik и такой команды, как:

java -jar 'C:\download\open\batik-1.7\batik-rasterizer.jar' -dpi 120 *.svg

Или с помощью Inkscape (File, Export bitmap, Drawing tab, bitmap size (default size, 100 dpi), Filename (default)

или с помощью Cygwin:

for file in *.svg; do
  /cygdrive/c/progra~1/Inkscape/inkscape -d 120 -e $(cygpath -a -w $(basename $file .svg).png) $(cygpath -a -w $file);
done

Использование BASH

# Convert single SVG to PNG file.
# /c/progra~1/Inkscape/inkscape -d 120 -e a.png a.svg

или конвертировать Все файлы в папке SVG-PNG.

for file in *.svg; do
/c/progra~1/Inkscape/inkscape -d 120 -e $(basename $file .svg).png $file
done

В настоящее время Inkscape, похоже, создает лучшие PNG.

PDF генерируется в \pdf\math. pdf с помощью команды из скорлупы или командного окна с текущим каталогом \math_toolkit\libs\math\doc\sf_and_dist, как правило:

bjam -a pdf >math_pdf.log

Обратите внимание, что XEP должен быть настроен на использовать и встраивать любые шрифты, используемые уравнениями SVG (почти наверняка редактируя образец xep.xml, предоставленный установкой XEP). Если вы не сделаете этого, вы получите предупреждения XEP в файле журнала, как

[warning]could not find any font family matching "Times New Roman"; replaced by Helvetica

(html является по умолчанию, поэтому он генерируется на libs\math\doc\html\index.html с помощью командной строки >bjam -a > matrix_toolkit.docs.log).

<!-- Sample configuration for Windows TrueType fonts.  -->

предоставляется в загрузке xep.xml, но шрифты Windows TrueType комментируются.

JM's XEP config file \xep\xep.xml имеет следующий раздел конфигурации шрифта:

    <font-group xml:base="file:/C:/Windows/Fonts/" label="Windows TrueType" embed="true" subset="true">
      <font-family name="Arial">
        <font><font-data ttf="arial.ttf"/></font>
        <font style="oblique"><font-data ttf="ariali.ttf"/></font>
        <font weight="bold"><font-data ttf="arialbd.ttf"/></font>
        <font weight="bold" style="oblique"><font-data ttf="arialbi.ttf"/></font>
      </font-family>
      <font-family name="Times New Roman" ligatures="&#xFB01; &#xFB02;">
        <font><font-data ttf="times.ttf"/></font>
        <font style="italic"><font-data ttf="timesi.ttf"/></font>
        <font weight="bold"><font-data ttf="timesbd.ttf"/></font>
        <font weight="bold" style="italic"><font-data ttf="timesbi.ttf"/></font>
      </font-family>
      <font-family name="Courier New">
        <font><font-data ttf="cour.ttf"/></font>
        <font style="oblique"><font-data ttf="couri.ttf"/></font>
        <font weight="bold"><font-data ttf="courbd.ttf"/></font>
        <font weight="bold" style="oblique"><font-data ttf="courbi.ttf"/></font>
      </font-family>
      <font-family name="Tahoma" embed="true">
        <font><font-data ttf="tahoma.ttf"/></font>
        <font weight="bold"><font-data ttf="tahomabd.ttf"/></font>
      </font-family>
      <font-family name="Verdana" embed="true">
        <font><font-data ttf="verdana.ttf"/></font>
        <font style="oblique"><font-data ttf="verdanai.ttf"/></font>
        <font weight="bold"><font-data ttf="verdanab.ttf"/></font>
        <font weight="bold" style="oblique"><font-data ttf="verdanaz.ttf"/></font>
      </font-family>
      <font-family name="Palatino" embed="true" ligatures="&#xFB00; &#xFB01; &#xFB02; &#xFB03; &#xFB04;">
        <font><font-data ttf="pala.ttf"/></font>
        <font style="italic"><font-data ttf="palai.ttf"/></font>
        <font weight="bold"><font-data ttf="palab.ttf"/></font>
        <font weight="bold" style="italic"><font-data ttf="palabi.ttf"/></font>
      </font-family>
    <font-family name="Lucida Sans Unicode">
         <!-- <font><font-data ttf="lsansuni.ttf"><font> -->
         <!-- actually called l_10646.ttf on Windows 2000 and Vista Sp1 -->
         <font><font-data ttf="l_10646.ttf"></font>
    </font-family>

PAB пришлось изменить его, потому что шрифт Lucida Sans Unicode имел другое имя. Другие изменения, скорее всего, потребуется, если вы не используете Windows.

XZ написал свои уравнения, используя почитаемый Latex, JM преобразовал их в MathML, используя mxlatex. Этот процесс в настоящее время является ненадежным и требует некоторого ручного вмешательства: следовательно, источник Latex не считается жизнеспособным способом автоматического производства SVG-версий уравнений.

Акции встроены в источник быстрой книги с использованием шаблона equation, определенного в математике.qbk. Это вывод Docbook XML, который выглядит как:

<inlinemediaobject>
<imageobject role="html">
<imagedata fileref="../equations/myfile.png"></imagedata>
</imageobject>
<imageobject role="print">
<imagedata fileref="../equations/myfile.svg"></imagedata>
</imageobject>
</inlinemediaobject>

Математика ML в настоящее время не присутствует в выводе Docbook или в сгенерированном HTML: это требует дальнейшего исследования.

Producing Graphs

Графики были произведены в формате SVG, а затем преобразованы в PNG, используя тот же процесс, что и уравнения.

Программы /libs/math/doc/sf_and_dist/.