LINUX.ORG.RU

Ответ на: комментарий от Reset

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

Dudraug ★★★★★
()
Ответ на: комментарий от annulen

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

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

уже сделали давно. Если важна скорость, используй BLAS и LAPACK (желательно от вендора CPU), если ООП - Eigen2 (хотя они пишут, что у них скорость сопоставима, правда рарзреженные матрицы пока поддерживаются экспериментально)

annulen ★★★★★
()
Ответ на: комментарий от annulen

Когда написано dgemm(a, b, c) то сразу ясно что тут происходит, а вот что делает c = a * b ? Тут куча скрытых неочевидных действий, особенно меня беспокоит то, что будет стоять за операцией присваивания.

Reset ★★★★★
()
Ответ на: комментарий от Reset

>Да можно всё что угодно написать с нуля под себя, но нафига это надо, если уже есть STL ?

В Qt взяли и написали свои контейнеры с б.&ш.^W^W быстро работающие и с COW. Profit!

annulen ★★★★★
()

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

И вот берём матрицы...что мы имеем? Общедоступное железо, которое хорошо работает со скалярами и зачаточно с векторами ( операции со 128/256 - битными кусками данных, SSE, не? ) и есть числодробилки векторные ( Cray жив, не? )...про видеокарты забыл. Подо всё это можно сделать работу с матрицами...

Я бы не рисковал запихивать это в стандарт... Многопоточность как бы тоже.

m4n71k0r
()
Ответ на: комментарий от m4n71k0r

> Многопоточность как бы тоже

многопоточность наконец-то таки уже запихнули( только сам стандарт осталось принять )

ahonimous
()
Ответ на: комментарий от Zodd

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

Не выходить за границы массивов — штатная ситуация, а вот если вылазишь, значит где-то херни набыдлокодил. В этом смысле assert и UB эквивалентны: причина не в срабатывании/отсутствии контроля, а в кривых руках пользователя библиотеки.

linuxfan
()
Ответ на: комментарий от m4n71k0r

Многопоточность как бы тоже.

Насколько я знаю запихнут.

Dudraug ★★★★★
()
Ответ на: комментарий от ahonimous

Да, я читаю иногда драфты C++...всё больше ужасает

Напоминает предложения по улучшению Perl ))))) «more perlish Perl»(c)

Если вводить многопоточность, то почему бы не ввести coroutine? Тогда многие производители игр, например, задумались бы, прежде чем использовать скриптовые языки вместе с C++.

m4n71k0r
()
Ответ на: комментарий от m4n71k0r

Многопоточность по сути уже норма, слишком часто используется она.

Ну будет, так будет. Если кого-то не устроит, то есть виндовые треды, posix, qt, glib.

Dudraug ★★★★★
()
Ответ на: комментарий от grusha

>Сам я работаю в международной хардварной компании, пишу на Си, никакого ООП.

Хардварной — в смысле, занимаетесь embedded-программированием? С этого и стоило начинать:)

V_L_A_D ★★
()
Ответ на: комментарий от Reset

Когда написано dgemm(a, b, c) то сразу ясно что тут происходит, а вот что делает c = a * b ? Тут куча скрытых неочевидных действий, особенно меня беспокоит то, что будет стоять за операцией присваивания.

Вот пример использования моего велосипеда:

dK = ~B*Dep*B;
dK*=k1(m,1)*k1(n,1)*k1(l,1)*det;
K+=dK;

Что тут непонятного?

Zodd ★★★★★
() автор топика
Ответ на: комментарий от linuxfan

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

Zodd ★★★★★
() автор топика
Ответ на: комментарий от Zodd

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

Zodd ★★★★★
() автор топика
Ответ на: комментарий от annulen

Сам бывший фортранщик (:

А Eigen посмотрю.

З.ы. описа'лся

Zodd ★★★★★
() автор топика
Ответ на: комментарий от Zodd

То есть оно создает новую матрицу? В 99% реальных алгоритмов такое поведение не нужно и даже вредно.

Reset ★★★★★
()
Ответ на: комментарий от V_L_A_D

> Хардварной — в смысле, занимаетесь embedded-программированием?

Embedded в смысле не под писюки, но в т.ч. и довольно высокоуровневым.

grusha
()

> [c++] Почему в с++ нету

Потому что не нужно.

anonymous
()
Ответ на: комментарий от Reset

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

Zodd ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.