Вектор, Матрица, Класс алгебры Дизайн

Question

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

То, что я принимаю во внимание, компилятор теперь потрясающий, я знаю, что не могу быть умнее этого компилятора, но я хочу помочь ему по максимуму. C ++ 11 приносит хорошие вещи, такие как семантика перемещения и другие вещи, такие как std :: tuple ....

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

Где я немного потерялся и мне нужно больше информации:

А) Должны ли данные быть: value_type [Rows * Cols] (простой массив c) или value_type * (размещается в куче размером Rows * Cols) или использовать что-то вроде станд :: кортеж

B) Также Наследование или состав / агрегация Я мог бы иметь базовый класс шаблона для данных или сделать это с помощью композиции / агрегирования

C) Я видел 3 макета данных

• структура и объединение (как в этой статье http://www.gamasutra.com/view/feature/4248/designing_fast_crossplatform_simd_.php)
• простая переменная-член
• другой использовал статический указатель на член вместо объединения. (http://www.gamedev.net/topic/261920-a-slick-trick-in-c/)

D) Также в статье о gamasutra (которая кажется старой и компилятор лучше) Он говорит, что в классе не должно быть перегрузки операторов, и вместо этого следует использовать глобальную функцию. Например, функция crossProduct, чтобы сделать ее не членом вместо функции-члена.

У меня есть все эти вопросы, я знаю, что есть много. Как вы относитесь к ним, особенно к А и С.

Edit:

Спасибо всем за ответ на вопрос А, я должен сказать, что в данный момент мой самый большой вопрос связан с пунктом С, извините, я знаю, что это не ясно. Пункт с действительно о дизайне классов. Я видел 2 варианта (типа три, если вы рассматриваете этот статический трюк http://www.gamedev.net/topic/261920-a-slick-trick-in-c/), который я мог бы иметь для Vector4 в качестве примера, я мог бы иметь члены x, y, z и w общедоступными, или я мог бы также сделать союз с эти члены и массив, или я мог бы иметь только массив и иметь функции X (), Y (), Z (), W () для аксессора. И наконец, есть статический трюк, который я предоставил ссылку чуть выше, но я предпочел бы, чтобы x, y, z и w были статическими, а массив был бы членом данных.

Answer 1

См. Блиц ++ .Также см. Его страницу " О ", чтобы получить представление об этом.Это одна из самых популярных промышленных математических библиотек, написанных на C ++.Хотя вы не спрашивали, к какой библиотеке обращаться, я цитирую это главным образом потому, что вы можете извлечь уроки из некоторых вариантов дизайна, сделанных в этой библиотеке.Вы можете найти понимание по самым интересующим вас вопросам.

Answer 2

Для небольшой матрицы 4x4 я бы избегал динамического выделения памяти в куче ... простого одномерного массива, который можно индексировать как двумерный массив, должно быть достаточно (т. Е. Значение упорядоченной пары (x, y) будет be matrix_array[COLUMNS * y + x]), особенно учитывая, что загрузка любого отдельного значения в массиве также приведет к сохранению смежных значений в строке кэша процессора, ускоряя доступ к любым смежным элементам. Загрузка кеша также может происходить с выделенной кучей памятью, но главная причина избежать выделения кучи, если это возможно для небольших матриц, состоит в том, что для многих последовательных математических операций вам потребуется возвращать временные, а без ссылок на r-значения вы ' в конечном итоге мы сделаем много вызовов new и delete внутри конструкторов копирования этих временных файлов, что значительно замедлит работу по сравнению с быстрым распределением памяти в стеке.

Во-вторых, я бы предложил вам использовать шаблонный подход, поскольку это позволит вам определить вашу матрицу не только для простых типов данных типа double и т. Д., Но и для любых вторичных составных типов, которые вы можете решите определить позже или импортировать из другой библиотеки, такой как рациональные числа, комплексные числа и т. д. Если вы решите добавить перегрузки операторов, это действительно ваше дело ... некоторым людям это не нравится, потому что это «скрывает» сложность того, что может происходить под капотом (то есть A * B для doubles будет гораздо проще, чем A * B для 4x4 matrix<double>). С другой стороны, это может значительно упростить объем кода, который вы пишете для сложных математических операций.