ZA Istinski programisti

Naistina istinski programisti,kakvo mislite za tazi statiq:[линк]

Naistina li FORTRAN e po dobur ot ostanalite programni ezici kato C/C++!?!??

Този текст е писан, когато Pascal е бил връх на сладоледа в технологиите за програмиране. Ако замениш FORTRAN със C, Pascal с нещо дето сега е връх на сладоледа и го осъвремениш малко може на някого да стане му забавен. Стига да намериш човек който не е чел стария текст, де.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Kogato nawremeto go chetoh towa, se spukah ot smiah (ako ne se lava mai beshe w "Komputer za was"). Statiata e napisana za da bade zabawna, ne za da bade wiarna...
Za final ste kava samo, che na Fortran pishat naj-weche razni fizici/matematici, pri towa bez da razbirat nistichko ot programirane (prosto go izpolzwat naj-weche za izchislenia).

е, мисля че паралела който правиш е неправилен. фортрана е на практика първият език, и мисля че тоя майтап е за сметка на "прогресорите".
така че по-правилно аналогията да е
фортран <-> паскал
..........................
паскал <-> С
С <-> С++
С++ <-> жаба/ С#

разбира се статията е майтап. аз лично не бих се хванал да споря кой език е по-добър, ясно е че новите езици щом се налагат си имат преимуществата, а и не само това - принципно е глупав подобен спор. и все пак когато четох тая статия още в КВ се смях много, смях се и сега като я четох. майтапите за сметка на "прогресорите" ме кефят, не знам защо. може би защото всички тъпаци които като понаучат малко модни езици, са задължително "прогресори". не ме разбирайте погрешно - това не означава че тези които пишат на С# или жаба са тъпи.

be tuk moje da se natworqt mnogo gluposti sega ;)
istinata e, 4e i do dnes fortran se izpolzwa masowo na golemi ma6ini naj-we4e za razni slojni smetki. sy6to taka ezika postoqnno se e razwiwal, ima i sywsem presni standarti, taka 4e edwa li ima mnogo ob6to sys origina la ot 1963 ;)
skoro gledah testowe za skorost na ispylnenie mejdu razni fortran/c compilatori i trqbwa da ti kaja, 4e na powe4eto testowe fortrana be6e sredno sys 10% po-byrz, a na nqkoj be6e sys nad 50% po-byrz ;) syjalqwam, 4e ne moga da se setq za link-a...

Таз статия съм я чел още в Компютър за вас, ама немога да си спомнякоя година беше... но наистина е ценна от гледна точка че може да си повдигнеш настроението след тежък ден ;-)


Друго си е....

чекиджиата да го лапа, това е статия от преди 5 години. Лайното не може да разбере кой е истински програмист, може само да духа...

Тестовете м/у Фортран и какво са били? По-бърз Фортран от кое? Аз също гледах тестове наскоро (ама и аз не помня къде) и мога да кажа, че отдавна няма разлика в скоростта м/у C++ и Фортран, а преди е бил по-бърз наистина.
А C++ е на светлинни години пред Фортран като език.
Всъщност истината за това че се ползва Фортран е друга. Просто много физици и математици на възраст само тоя език си знаят. Освен това има много написан код на Фортран, който не е за изхвърляне. Превеждал съм код за изчисления от Фортран, през C ( с автоматичен преводач ) на C++. Мога да ти кажа, че е ужасен, защото физиците не могат да програмират. Голяма борба падна тогава и без документация едва ли щях да се справя.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

mnogo dobre si razbral - mejdu fortran i c ;) testowete bqha ot minalata godina na golemi ma6ini - vektorni predimno. a towa, koj ezik kyde e ne sym obsyjdal maj, a!? az pi6a na c++ ne na fortran, no se staraq da byda bezpristrasten w takiwa sporowe za razlika ot nqkoj ;))
otnosno awtomati4nite prewoda4i - ti kakwo o4akwa6? i az sym polzwal maj be6e f2c ili ne6to ot sorta, koda kojto generira6e be6e ujasen, ama ne za6toto fortranskiq be6e ujasen ;).... az ne bih se nael da twyrdq, 4e matematicite i fizicite ne mogat da programirat, no qwno ti znae6 po-dobre ;) moga samo da kaja, 4e znam to4no za kakwi zada4i stawa wypros ;)

ne moga da namerq linka za kojto goworq, sega porowih ama, tc. namerih towa oba4e (ne sym gledal testowete podrobno): [линк]

Не съм искал да се заяждам, просто казвам какво съм чел. Пък и то е очевидно като видиш кода който се генерира, че по-добре няма как да стане, ако ще на ръка да го напишеш на асемблер :-)).
Специално за теста който си постнал(знам че не си го гледал) мога да кажа следното: Аз мога така да го променя C++ кода ( който всъщнос е C кода ), че да стане още по-бавен, но все пак те добре са се справили. Ето някои забележки:
1. Ползвали са за матрица double**, това е глупаво, трябва да се ползва клас съдържащ double* [n*n].
2. Ползвали са за целочислените операции floating функции, на 7-ца не мога даже да го компилирам.
3. От километър се вижда един бъг ( неправилно поставени скоби, вместо
if( fabs(a[ i ][ i ]) <= eps ) return;
пише
if (fabs(a[ i ][ i ] <= eps))

4. Навсякъде се ползва [ i ][ j ] , а което е меко казано неефективно.

В моята библиотека подобни бози няма (защото съм си я писал аз) и ще върви по-бързо или равно на Фортрана.

Всъщност този код ми е познат, явно е бил доста популярен навремето. Точно с матрици се занимавах.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

А така. И кое точно му е неефективното на x[j]?
Същото е като да напишеш *(*(x + i) + j) и точно толкова ефективно.

В случая наистина няма голям проблем, защото представянето е такова. Все пак по-ефективно би било на всеки ред да присвояваш на междинна променлива и да съкратиш i - то от сметката. Има доста обръщения в по-вътрешните цикли.
Ако се ползваше правилното представяне - последователно наредени редове ( не колони като на Фортран ) се сещаш, че в сметката влиза и умножение. Това при положени е че можеш да пуснеш един пойнтер по всички елементи си е живо разточителство. Когато става дума за матрици ти си имаш някаква базова сложност от размерността, но това не значи че ако подобриш доста пъти бързодействието няма да ти е добре. Не е все едно дали чакаш 30 секунди или 3, нали?


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Нещо не разбрах. За представянето на матрица ROWS x COLS обикновено се използва едно от двете:

1. m[ ROWS ][ COLS ] - достъп: m[ i ][ j ], еквивалентно на *(*(m + i) + j).
2. m[ ROWS * COLS ] - достъп: *(m + COLS * i + j).

Освен това за масивите е гарантирано, че елементите им са последователно разположени, така че (с помощта на casts) може да достъпваш елемент по който и да е от двата начина. Струва ми се, че заради умножението втория начин е по-бавен. Освен това не се сещам за различно от горните две представяния на матрица, което да е по-ефективно.

Ех, драги, с това си изказване изтрепа рибата с мистрия.
"Просто много физици и математици на възраст само тоя език си знаят..."
Според мен ФОРТРАН винаги ще го има не защото дърти чичковци само това си знаят, а защото предназначението му е такова. На физика и математика не им е нужно да знаят какво правят тази седмица stdin, stdout, printf() или GetCommandLine(), както и важно ли е данните да са маршалнати през прокси-стъб или директно през typelib. Помисли само защо се използва Delphi, Power Builder или VB дори. ЗАЩОТО е по-лесно. За всеки влак си има пътници. С минимум усилия се постига задачата. А относно бързината - четох някъде, че С# дава дори по-добри резултати от С++ ПРИ ОПРЕДЕЛЕНИ ОБСТОЯТЕЛСТВА. Но всяко едно сравнение е относително. Ти с колко реда ще сметнеш Пи до 7 милионния знак на С++ и с колко реда на ФОРТРАН? Колко класа ще изпишеш на С++ и колко реда на ФОРТРАН? Задачите имат решение. Важна цената на това решение.
Силата на даден език е в областта му на действие. Наистина, не уважавам аскал като език, защото той е език с общо предназначение, както С и С++. Но ФОРТРАН и други подобни на него не са такива.

Мне, не си познал.
Това е статия от 1988 година.

В теста представянето е (1), а аз твърдя, че ако е (2) може да се постигне значително по-добра скорост ( за съжаление ще пострада четимостта малко ).
Просто алгоритъмът не изисква произволен достъп до елементите, затова недостатъкът че има умножение при произволен достъп няма да се прояви. Същото се отнася за всички операции с матрици които мога да се сетя - не изискват произволен достъп.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

не се посещава от истински програмисти - някои са полуистински и пердашат на маймуница като за световно.
Бас държа че не е щото не могат да подкарат кирилицата а просто щото маймуницата повече ги кефи.
Други още по малко истински с ползват кирилица.
Ама ако имаше поне един съвсем истински щеше да си кара на битове. Да си реди нули и единици и толкова.
Кви са тези азбуки?

Искаш да кажеш, че offset-а може да се сметне и/или кешира, така че да не е необходимо всеки път да се изчислява по някой от идиоматичните начини при достъп ?

В такъв случай май не трябва да се използва нито единия от двата метода, вместо това на всяка стъпка от алгоритъма за съответната сметка с матриците трябва да се работи с предварително пресметнатия offset. За съжаление четимостта наистина ще пострада и то не малко.

Btw, ще съм ти благодарен ако сложиш линк-два с нещо подобно. Имам предвид реализация на операции с матрици, която използва оптимизиран начин за достъпване на елементите, на базата на знанието кои точно елементи трябва да се използват.

Моята библиотека така прави, ама за съжаление е недовършена, а в момента нямам компилатор вкъщи. Имам само операциите, които са ми трябвали. Като я довърша някой ден ще я кача на сайта си.
М/у другото в тоя тестов код забелязах нещо, което не ми беше хрумвало:

3. Алокира се цялата памет m*n и се присвоява на а[0], а a[1]...[n-1] се насочват допълнително.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Сравнявал ли си твоята lib с аналогичен FORTRAN код или с някой, използващ valarray?