К вопросу о числодробильнях

нехорошо лицензию нарушать

Какую лицензию?

Там скорее всего typedef long integer, а long != int. Если бы ты собирал это как Си код, а не как Си++, то скорее всего прокатило бы.

Код из Numerical Recipes является собственность издателства, его нельзя использовать в распространяемых приложениях http://www.nr.com/aboutNR3license.html

You may, under this license, transfer precompiled, executable applications incorporating the code to other, unlicensed, persons, providing that (i) the application is noncommercial (i.e., does not involve the selling or licensing of the application for a fee), and (ii) the application was first developed, compiled, and successfully run by you, and (iii) the code is bound into the application in such a manner that it cannot be accessed as individual routines and cannot practicably be unbound and used in other programs.

Так что, я могу использовать этот код в ограниченных уникальных программных продуктах. Этот софт я не продаю. Функции из NR не могут быть активированы отдельно от общей программы или использоваться в другом софте. И, кстати, в комментариях к используемой функции указано «Public domain»...

А к чертям с матерями катятся такие лицензии.

То же разложение Холецкого это пятьдесят строк очевидного кода, какие у них могут быть права на единственно возможную реализацию алгоритма, известного с начала прошлого века? Пусть даже и с распараллеливанием.

>То же разложение Холецкого это пятьдесят строк очевидного кода, какие у них могут быть права на единственно возможную реализацию алгоритма, известного с начала прошлого века?

возьми NewMat или Eigen

>Так что, я могу использовать этот код в ограниченных уникальных программных продуктах. Этот софт я не продаю.

ну если у тебя есть Institutional Subscriber License, то да

>>возьми NewMat или Eigen

Я знаю что есть альтернативы. Но городить объездные пути только из-за того, что на веками совместно строившейся общедоступной дороге научного знания какая-то сиюминутная борзая мразота обнесла участок копирайтами - не собираюсь.

90-й фортран конечно не сахар, однако с задачами справляется.

Перегрузки функций как делать?

man interface

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

Не понятно, о чем вы? или о передаче параметров по ссылке?

Да.

>>Не понятно, о чем вы? или о передаче параметров по ссылке?

Да

intent(in/out)

Если я правильно вас понял

Прочитал невнимательно. Я говорил про увеличение числа передаваемых параметров:

function f1(a,b,c) integer a,b,c ...

function f2(a,b,c) integer a,b,c integer f1 ...

function fn(a,b,c) integer a,b,c integer f1 ... integer fn

// Схематично

о том, что в классическом фортране нет структур, поэтому не редкость когда в функцию передается несколько десятков аргументов

Использовал lapack, cgal

работал на С и на C++. Всё ок, нарекания были только на gcc :)

2 Zodd : function f1(a,b,c) integer a,b,c ...

function f2(a,b,c) integer a,b,c integer f1 ...

function fn(a,b,c) integer a,b,c integer f1 ... integer fn

sorry, но никак не пойму, чего вы хотите

2 Reset:

о том, что в классическом фортране нет структур, поэтому не редкость >когда в функцию передается несколько десятков аргументов

В каких ситуациях для передачи аргументов нужны структуры? И, еще, что вы подразумеваете под «классическим фортраном»?

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

ну то, что ты убогий, и так понятно

В каких ситуациях для передачи аргументов нужны структуры?

ты библиотеки распространенные посмотри, там значащих аргументов всего несколько, остальное все всякие work'и и другие незначащие параметры, которые в Си обычно заворачивают в структуру в такой форме

my_super_puper_lib_hdl = new_lib_hdl();
calc_smth(my_super_puper_lib_hdl, result, argument1, argument2);
free_lib_hdl(my_super_puper_lib_hdl);

И, еще, что вы подразумеваете под «классическим фортраном»?

77й конечно же

А вот и ушибленные на всю голову подтянулись. Советую посмотреть как красиво и понятно в blas'е сделано умножение матриц и сравнить с этим убожеством.

советую захавать пургена, так будет больше материала для бросков

> советую захавать пургена, так будет больше материала для бросков

вам надо открыть рубрику - «советы бывалых»

OpenCL C, по суровости фортран не дотягивает

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

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

>> И, еще, что вы подразумеваете под «классическим фортраном»?

77й конечно же

Ну и зачем с этим убожеством иметь дело? Компилируется, и Бох с ним

Ну и зачем с этим убожеством иметь дело?

А затем, что на нем написано 99% промышленных числодробильных библиотек, поэтому приходится иметь дело.

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

subroutine K_Mat(r0,z0,Xi0,Eta0,B,D,l,NDef,ElNode, K)

integer l,NDef,ElNode

integer m,n,i,j,kf

double precision r0(ElNode),z0(ElNode),Xi,Eta,Xi0(ElNode),Eta0(ElNode),B(NDef,3*ElNode),D(NDef,NDef),K((3*ElNode)**2)

double precision k1(4),k2(4),Ykb(2,2),det,s,r

double precision dK(3*ElNode,3*ElNode),K2D(3*ElNode,3*ElNode)
...

Если уж говорить про фортран. То уже есть 2003-й (в каком состоянии не знаю) и спецификации 2007. Так что он еще не умер, Intel его все пилит.

Если я правильно понял, то проблема возникает, когда достаточно высокоуровневую процедуру (для фортрана) впихивают в другие функции. Тогда ССЗБ, фортран - чисто императивный язык, передача вспомогательныз массивов не проблема, а причина ускорения. Конструкция - функция от функции от функции совершенно не в тему. Если у вас функционализм головного мозга, то попробуйте лечиться.

А что вы предлагаете делать, если в процедуру надо передать много различных параметров и матриц, и все они нужны?

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

>>Обертка пишется тривиально. Функцию в h'нике обзываешь с подчеркиванием, а все данные в функцию передаешь по указателю. Например, если в фортране было void f (integer), то в Си пишешь void f_(int *)

Возможно, мне скоро тоже придется иметь с этим дело, так что.. В lapack есть варианты функций с комплексными переменными, прокатит ли так же написать обертку для этих функций в С?

Работать с комплексными переменными у меня не было необходимости. Но надо глянуть как f2c делает и сделать по аналогии.

>>Работать с комплексными переменными у меня не было необходимости. Но надо глянуть как f2c делает и сделать по аналогии.

Спасибо, гляну. А то эрмитовы матрицы будут, и изобретать велосипеды не хотелось бы.

>А что вы предлагаете делать, если в процедуру надо передать много различных параметров и матриц, и все они нужны?

К.О.: передавать.

функции от функций

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