- 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;
TarasB 22.11.2011 16:17 # +3
Lure Of Chaos 22.11.2011 16:18 # +6
все.
TarasB 22.11.2011 16:24 # +12
gegMOPO4 22.11.2011 16:39 # +8
7ion 22.11.2011 19:00 # +6
gegMOPO4 22.11.2011 21:35 # +1
bugmenot 22.11.2011 21:47 # +4
KirAmp 22.11.2011 22:10 # 0
jabber 22.11.2011 22:13 # 0
KirAmp 22.11.2011 22:16 # 0
guest 22.11.2011 22:19 # +2
jabber 22.11.2011 22:47 # 0
7ion 22.11.2011 23:09 # −2
jokz 22.11.2011 16:38 # 0
roman-kashitsyn 22.11.2011 16:40 # +3
1_and_0 22.11.2011 16:56 # +1
guest 22.11.2011 17:05 # 0
TarasB 22.11.2011 17:34 # 0
akaDElpher 23.11.2011 16:08 # 0
TarasB 23.11.2011 16:21 # +1
Понятно, что 120 слагаемых по 4 умножения считать не стоит, но можно это записать чуток пооптимальнее.
greno 23.11.2011 21:10 # 0
TarasB 24.11.2011 11:24 # 0
Треугольником 54 умножения и 10 делений, ну и ещё выбор максимального элемента.
TarasB 24.11.2011 11:54 # 0
Короче, лобовой метод сосёт.
roman-kashitsyn 24.11.2011 12:00 # +1
Экспоненциальный рост такой экпоненциальный
TarasB 24.11.2011 12:08 # −1
guest 25.11.2011 22:13 # 0
TarasB 26.11.2011 14:52 # 0
greno 23.11.2011 21:10 # 0
Lure Of Chaos 23.11.2011 23:25 # +3
я по два раза не повторяю
TarasGovno 24.11.2011 16:35 # +2
dos_ 24.11.2011 18:53 # +2
gegMOPO4 24.11.2011 19:51 # +1
lucidfoxGovno 24.11.2011 22:24 # −3
eth0 22.11.2011 17:43 # +4
guestGovno 23.11.2011 07:09 # +1
eth0 23.11.2011 17:56 # 0
dotnetdeveloper 22.11.2011 22:21 # +1
f[i] - proizvodnye dy[i]/dt,
SJUDA VCTAVITE SVOI URAVNENIYA
SLEDI ZA PEREDACHEI ZNACHENIJ ! !
}
Govnocoder#0xFF 23.11.2011 18:48 # +1
AxisPod 23.11.2011 06:34 # 0
greno 23.11.2011 08:51 # +3
TarasB 23.11.2011 09:25 # +3
3.14159265 23.11.2011 16:30 # +2
roman-kashitsyn 24.11.2011 19:05 # +2
bugmenot 24.11.2011 19:17 # 0
всяки крестики-черточки -- против паскальной идеи
roman-kashitsyn 24.11.2011 19:48 # +3
bugmenot 24.11.2011 20:00 # +5
Rascal
Modula 2
lucidfoxGovno 24.11.2011 20:12 # +1
roman-kashitsyn 24.11.2011 20:16 # +3
lucidfoxGovno 24.11.2011 20:18 # −2
<(O.o)?
jabber 24.11.2011 20:20 # +1
Govnocoder#0xFF 24.11.2011 21:02 # +1
bugmenot 24.11.2011 22:54 # +2
lucidfoxGovno 24.11.2011 23:14 # 0
^_______________________^
roman-kashitsyn 24.11.2011 20:22 # +1
Может Вирт одумается и пойдёт в сторону ФП?
lucidfoxGovno 24.11.2011 20:43 # 0
Развитие этой линейки паскалоподобных языков шло с каждым новым языком - к упрощению.
Это следствие из его главного "постулата": «Делай просто, насколько возможно, но не проще этого».
По этому Haskell ему не понравится, если посмотреть его функционально-математический не humanfrendly синтаксис.
Вирт выразил своё негодование по поводу Ады и Delphi, тк они все время усложняются и теряет свою простоту и стройность.
lucidfoxGovno 24.11.2011 20:49 # −3
Макаки, которых долго обучать ФЯП? Макаки не нужны. Предлагаю их всех уволить или отправить в сопутствующие или не мейнстримные области.
TarasB 25.11.2011 09:05 # 0
roman-kashitsyn 25.11.2011 09:12 # 0
Они работают медленнее при выполнении на одном-двух ядрах и потребляют значительно больше памяти, чем c++ аналоги.
lucidfoxGovno 25.11.2011 09:40 # −2
roman-kashitsyn 25.11.2011 10:15 # 0
Я сам не фанат сверхбыстрых вычислений, я уверен, что корректная, стабильная и удобная работа приложения важнее производительности.
Взять хотя бы Python. В среднем он существеннее медленнее многих функциональных языков. Но на нём написано много отличного софта, тормознутости которого я лично не замечаю. Я лично не замечаю тормозов в работе emerge или yum, их скорость работы меня вполне устраивает.
А вот тормознутость maven меня бесит. Я уверен, что он медленно работает либо из-за кривой архитектуры, либо из-за кривых рук наших CMщиков. Причём первое более вероятно.
Пусть фанаты c++ бьют себя пяткой в грудь и обвиняют ФЯП в тормознутости и огромном потреблении памяти. Я уверен, что бенефит от правильного алгоритма значительно важнее бенефита от более быстрой среды выполнения.
roman-kashitsyn 25.11.2011 10:22 # +1
TarasB 25.11.2011 11:34 # +2
3.14159265 26.11.2011 15:23 # +1
>стабильная и удобная работа приложения важнее производительности.
Расскажи это девам x264.
http://x264dev.multimedia.cx/archives/360
roman-kashitsyn 26.11.2011 15:29 # +1
3.14159265 26.11.2011 15:32 # +2
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
3.14159265 26.11.2011 15:38 # +2
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.
К вопросу о том, что циклы понижают производительность.
roman-kashitsyn 26.11.2011 15:45 # 0
Не, блог интересный, почитаю на досуге.
3.14159265 26.11.2011 16:50 # 0
Я его раньше до дыр зачитивал.
Очень жаль, что Джейсон больше не графоманит.
guest 25.11.2011 21:38 # 0
eth0 25.11.2011 22:07 # 0
С играми, вроде как, пока прокатывает. Одна из причин, кстати, почему ПК лучше, чем х-ящик.
lucidfoxGovno 25.11.2011 22:08 # −3
3.14159265 26.11.2011 15:25 # +1
Унылые хххГумно которые учат новые слова? хххГумно не нужны. Предлагаю их всех забанить или отправить на башорг.
lucidfoxGovno 26.11.2011 22:33 # −3
gegMOPO4 23.11.2011 13:38 # +3
guest8 09.04.2019 12:11 # −999