- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
function det5(var a:atab):double;
{FUNKCIYA VYCHISLYAET OPREDELITEL MATRITSY 5-go PORYADKA a}
begin
det5:=
+a[1,1]*a[2,2]*a[3,3]*a[4,4]*a[5,5]-a[1,2]*a[2,1]*a[3,3]*a[4,4]*a[5,5]
+a[1,3]*a[2,1]*a[3,2]*a[4,4]*a[5,5]-a[1,1]*a[2,3]*a[3,2]*a[4,4]*a[5,5]
-a[1,3]*a[2,2]*a[3,1]*a[4,4]*a[5,5]+a[1,2]*a[2,3]*a[3,1]*a[4,4]*a[5,5]
-a[1,4]*a[2,1]*a[3,2]*a[4,3]*a[5,5]+a[1,1]*a[2,4]*a[3,2]*a[4,3]*a[5,5]
-a[1,1]*a[2,2]*a[3,4]*a[4,3]*a[5,5]+a[1,4]*a[2,2]*a[3,1]*a[4,3]*a[5,5]
-a[1,2]*a[2,4]*a[3,1]*a[4,3]*a[5,5]+a[1,2]*a[2,1]*a[3,4]*a[4,3]*a[5,5]
-a[1,4]*a[2,3]*a[3,1]*a[4,2]*a[5,5]+a[1,3]*a[2,4]*a[3,1]*a[4,2]*a[5,5]
.............................................
end;
все.
Понятно, что 120 слагаемых по 4 умножения считать не стоит, но можно это записать чуток пооптимальнее.
Треугольником 54 умножения и 10 делений, ну и ещё выбор максимального элемента.
Короче, лобовой метод сосёт.
Экспоненциальный рост такой экпоненциальный
я по два раза не повторяю
f[i] - proizvodnye dy[i]/dt,
SJUDA VCTAVITE SVOI URAVNENIYA
SLEDI ZA PEREDACHEI ZNACHENIJ ! !
}
всяки крестики-черточки -- против паскальной идеи
Rascal
Modula 2
<(O.o)?
^_______________________^
Может Вирт одумается и пойдёт в сторону ФП?
Развитие этой линейки паскалоподобных языков шло с каждым новым языком - к упрощению.
Это следствие из его главного "постулата": «Делай просто, насколько возможно, но не проще этого».
По этому Haskell ему не понравится, если посмотреть его функционально-математический не humanfrendly синтаксис.
Вирт выразил своё негодование по поводу Ады и Delphi, тк они все время усложняются и теряет свою простоту и стройность.
Макаки, которых долго обучать ФЯП? Макаки не нужны. Предлагаю их всех уволить или отправить в сопутствующие или не мейнстримные области.
Они работают медленнее при выполнении на одном-двух ядрах и потребляют значительно больше памяти, чем c++ аналоги.
Я сам не фанат сверхбыстрых вычислений, я уверен, что корректная, стабильная и удобная работа приложения важнее производительности.
Взять хотя бы Python. В среднем он существеннее медленнее многих функциональных языков. Но на нём написано много отличного софта, тормознутости которого я лично не замечаю. Я лично не замечаю тормозов в работе emerge или yum, их скорость работы меня вполне устраивает.
А вот тормознутость maven меня бесит. Я уверен, что он медленно работает либо из-за кривой архитектуры, либо из-за кривых рук наших CMщиков. Причём первое более вероятно.
Пусть фанаты c++ бьют себя пяткой в грудь и обвиняют ФЯП в тормознутости и огромном потреблении памяти. Я уверен, что бенефит от правильного алгоритма значительно важнее бенефита от более быстрой среды выполнения.
>стабильная и удобная работа приложения важнее производительности.
Расскажи это девам x264.
http://x264dev.multimedia.cx/archives/360
After a full 6 hours, 8 frames had encoded. Yes, at this rate, it would take a full two weeks to encode 10 seconds of HD video. On a Core i7. This is not merely slow; this is over 1000 times slower than x264 on “placebo” mode. This is so slow that it is not merely impractical; it is impossible to even test. This encoder is apparently designed for some sort of hypothetical future computer from space. And word from other developers is that the Intel proposal is even slower.
>пишем на сях(++)
Снова мимо.
http://x264dev.multimedia.cx/archives/201
http://x264dev.multimedia.cx/archives/149
http://x264dev.multimedia.cx/archives/8
That’s about 3 kilobytes of assembly functions… which are run a few times each at the end of every single call. Since the total amount of code that ends up calling can well exceed 32 kilobytes, every single time our RD calls finish, we evict 1-2 kilobytes of data from the instruction cache.
If we look at the code, we find that the SSD functions are completely unrolled; rolling them up saves a great deal of binary size and actually increases performance, despite checkasm’s benching feature telling us the functions got slower: because in real situations, the cost of high code size is greater than the cost of the few instructions involved in loop overhead.
К вопросу о том, что циклы понижают производительность.
Не, блог интересный, почитаю на досуге.
Я его раньше до дыр зачитивал.
Очень жаль, что Джейсон больше не графоманит.
С играми, вроде как, пока прокатывает. Одна из причин, кстати, почему ПК лучше, чем х-ящик.
Унылые хххГумно которые учат новые слова? хххГумно не нужны. Предлагаю их всех забанить или отправить на башорг.