- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
double cCompositeBlock::determinant4x4(double *d){ // WARNING It's not logically connected with class.
return d[3]*d[6]*d[9]*d[12] -d[2]*d[7]*d[9]*d[12]-
d[3]*d[5]*d[10]*d[12] +d[1]*d[7]*d[10]*d[12]+
d[2]*d[5]*d[11]*d[12] -d[1]*d[6]*d[11]*d[12]-
d[3]*d[6]*d[8]*d[13] +d[2]*d[7]*d[8]*d[13]+
d[3]*d[4]*d[10]*d[13] -d[0]*d[7]*d[10]*d[13]-
d[2]*d[4]*d[11]*d[13] +d[0]*d[6]*d[11]*d[13]+
d[3]*d[5]*d[8]*d[14] -d[1]*d[7]*d[8]*d[14]-
d[3]*d[4]*d[9]*d[14] +d[0]*d[7]*d[9]*d[14]+
d[1]*d[4]*d[11]*d[14] -d[0]*d[5]*d[11]*d[14]-
d[2]*d[5]*d[8]*d[15] +d[1]*d[6]*d[8]*d[15]+
d[2]*d[4]*d[9]*d[15] -d[0]*d[6]*d[9]*d[15]-
d[1]*d[4]*d[10]*d[15] +d[0]*d[5]*d[10]*d[15];
}
Follow us!
http://govnokod.ru/8707
http://ideone.com/m64iM
я еще видел обратную матрицу в таком виде. это быстро. это нормально. без этого 3д графика не шевелится.
Увидел азиатскую фамилию - сомнения отпали. Этот алмаз шлифовали фланелевой тряпочкой и голыми руками.
Поэтому я искренне считаю, что такой китайский говнокод стоит дороже
Нет, с этим повезло, но трехэлементные векторы он свелосипедил.
http://ideone.com/Ojau68
А разве нельзя сделать
Алсо, таким copy можно скопировать из результата умножения матриц флоатов в транспонированную матрицу даблов. Типа снизить потери точности при умножении большого количества матриц.
Весьма забавно было наблюдать, как компилятор жрёт память и дохнет на компиляции вычисления определителя 8x8. Ищу компилятор x64, хочу больше зрелищ!
конечно, если к элементу матрицы обращаться как a.template at<row, col>()
8 гигов хватит? Домой вернусь - попробую собрать.
По оценке методом псевдонаучного тыка - должно хватить :) Вижуал студио сделал мне дебажный бинарник около восьми мегов для матриц 6x6, интересно, что будет с матрицами больших размеров.
> Домой вернусь - попробую собрать.
А чем, если не секрет? Тоже хочу себе продвинутый тулчейн :)
> try {
я в таких случая использую function-try блоки, так на один отступ меньше:Только не используйте их в деструкторах, пожалуйста.
Да они там какие-то совсем уж бесполезные... Либо убить прогу нахрен, либо перевбросить другое допустимое исключение. Больше вариантов то и нет...
Угу, в конструкторах и деструкторах у function-try блоков другая семантика, не как для обычных функций.
С деструкторами, кмк, у стандартизаторов тут фейл получился. Хотя, может я просто чего не осилил.
Герб Саттер тоже не осилил:
Мораль No1. Обработчик try-блока конструктора пригоден только для трансляции исключения, сгенерированного в конструкторе базового подобъекта или подобъекта-члена (а также, возможно, для соответствующего занесения информации в журнальный файл или каких-то других побочных действий в ответ на генерацию исключения). Ни в каких других целях обработчик служить не может.
Мораль No2. Try-блоки деструкторов практического применения не имеют, поскольку деструкторы не должны генерировать исключения.
Мораль No3. Все остальные try-блоки функций практического применения не имеют. Try-блок обычной функции не может перехватить что-то, что не может перехватить обычный try-блок в теле функции.
2: 0.2s, 40MB
3: 0.3s, 50MB
4: 0.7s, 90MB
5: 2.8s, 290MB
6: 38s, 1.3GB
7: in progress...
Хм, может и мне попробовать, если студия завалялась. Хотя, если она не может в 64, не надо пробовать.
но он с виндой и даже без студии
2x2 - 1391 ms
3x3 - 1631 ms
4x4 - 2406 ms
5x5 - 8202 ms
6x6 - 175956 ms
7x7 - терпение пока не кончилось, уже больше часа
Память посмотреть не смог, но 7x7 стабильно держится около 2 гигов.
Мда, я и не представлял, что одна маленькая ссылка сожжёт столько киловатт энергии :)
main.cpp(102): fatal error C1060: compiler is out of heap space
Вспомнилась именно эта цитата: http://www.bash.org/?919561
У меня i5 1.7ГГц, но он могильный, так что деление чисел на два не даст адекватного сравнения.
Я ещё проверял на совместимость со стандартом через MinGW, он компилировал ощутимо медленнее, в 1.3-1.5 раз.
g++ -O2
2x2 - 0m0.481s
3x3 - 0m0.621s
4x4 - 0m1.231s
5x5 - 0m4.813s
6x6 - 1m7.868s
И деление времени на отношение частот тоже даёт адекватную оценку.
Надо пробовать сведение к треугольному виду, у него будет че-то типа O(n^3).
И вообще: этот мозг нуждается в лучшем снабжении кислородом!
ГК растёт, ГК расширяется. Каждый день - новый юзерскрипт или тонны сгенерированного бреда. Надо думать о будущем, надо готовиться.
Пример из жизни: помогал другу реализовать МНК. У меня на хаскеле все отлично считалось (по счастливой случайности строчки положил как надо). А у него строчки были в обратном порядке - точность улетела к хуям, в ответе полный мусор, не имеющий никакого отношения к реальному ответу.