找回密码
 注册
Simdroid-非首页
查看: 11907|回复: 104

[10. Others] 【讨论】Fortran 与 C

[复制链接]
发表于 2003-7-13 08:41:08 | 显示全部楼层 |阅读模式 来自 湖北武汉
Fortran 是一种工程语言,所以以前大多数工程程序都是用Fortran来编写的。但是后来出了C语言,我感觉好像Fortran的功能在 C 里面都可以实现,而且C还有一些 Fortran没有的功能。Fortran 与 C 我都用过,也感觉到好像用 C 还是方面一些,不知道为什么现在大型工程软件还是用frotran来编写呢?
我觉得 C 比 Fortran 的方便之处在于:
1)C 有全局变量和局部变量,而 Fortran 没有全局变量的概念。
只能通过common 或函数参数在各个子程序里面传递数据。
而在 C 中由于有了全局变量,各个子程序在任何时候都可以方便的调用。
2)如果需要根据读入数据N来定义一个数组的大小。
在C里面可以通过指针来实现,动态的定义该数组,并且该指针可以定义为全局变量。这样该指针所指的数组也变成了全局变量
现在Fortran90也可以通过指针来定义一个动态数组。但是好像该数组不能放在common语句中,也就不能方便的被其他子程序调用。只能通过函数参数来传递数据。如果子程序需调用这样的数组很多的话,就导致该子程序的虚拟参数过多,调用起来不方便。
以上是我个人的一些看法,望大家一起来探讨一下。

评分

1

查看全部评分

发表于 2003-7-16 21:40:33 | 显示全部楼层 来自 北京

回复: 【讨论】Fortran 与 C

Simdroid开发平台
其实fortran的common函数,起到的作用和C的全局变量指针差不多
 楼主| 发表于 2003-7-18 08:37:30 | 显示全部楼层 来自 湖北武汉

回复: 回复: 【讨论】Fortran 与 C

blast wrote:
其实fortran的common函数,起到的作用和C的全局变量指针差不多

  
如果我需要根据读入的一个变量来定义一个数组的大小,在C中可以通过指针来定义该动态数组,且可以把该指针变量定义为全局变量。
在fortran中可以这样做吗?
发表于 2003-7-18 20:53:12 | 显示全部楼层 来自 北京

回复: 【讨论】Fortran 与 C

以前的TC2.0也不能定义动态数组吧,总是发展的嘛
  
旧的fortran77肯定不能这样,新的不清楚
  
不过这些都是可以回避的。我见过的一个80年代的FEA代码是通过先定义一个大数组,然后自己控制这部分内存。这样只要需要调用的内存不超过定义
极限都可以解决
 楼主| 发表于 2003-7-19 09:15:41 | 显示全部楼层 来自 湖北武汉

回复: 回复: 【讨论】Fortran 与 C

blast wrote:
以前的TC2.0也不能定义动态数组吧,总是发展的嘛
  
旧的fortran77肯定不能这样,新的不清楚
  
不过这些都是可以回避的。我见过的一个80年代的FEA代码是通过先定义一个大数组,然后自己控制这部分内存。这样只要需要调用的内存不超过定义
极限都可以解决

  
在2.0中是可以定义动态数组的,通过calloc,malloc和realloc等函数来实现。
  
我现在正在自己尝试着编写有限元程序,以前的FEA确实是通过先定义一个比较大的数组来编写的。但是我之所以要实现动态数组其目的就是为了实现充分合理的利用内存,特别是在目前单元数很大的情况下,这样就可以提高计算的效率。通过先定义一个大数组确实很方便,但是这样会对内存空间造成很大的浪费。我想根据实际计算时节点数来定义数组的大小,但是,这样的数组不知道怎样才能实现象在C语言中的全局变量一样可以很方便的被其他子函数调用。
发表于 2003-7-19 10:38:17 | 显示全部楼层 来自 河南开封

回复: 【讨论】Fortran 与 C

混合编程吧^_^
其实f90是可以调用windows的api的,VC也是调用api分配内存的,所以我认为f90可以实现动态分配内存,关键是我们不知道^_^:I
发表于 2004-1-10 14:18:23 | 显示全部楼层 来自 辽宁大连

回复: 【讨论】Fortran 与 C

Fortran 90 可以动态开内存 使用 如 定义 real,allocatable::a(:,
确定数组大小N1=1000,N2=30000, allocate(a(n1,n2))
释放内存deallocate(a)

评分

1

查看全部评分

发表于 2004-1-10 18:36:21 | 显示全部楼层 来自 台湾

回复: 【讨论】Fortran 与 C

當你計算量大時,Fortran表現在運算速度上的優點就比C好,一個是call by address,
一個是call by value,速度在計算量大時,就有所區別。
发表于 2004-1-18 06:48:15 | 显示全部楼层 来自 美国

回复: 【讨论】Fortran 与 C

yexm关于fortran和c对比我想还是基于fortran77的对比。其实随着fortran90的实现以及现在fortran2000的进展,这些语言间的差别就变得越来越小。大家都互相借鉴对方的优点来发展自身。
  
关于yexm的两个对比方面,对于动态数组方面现在大家都比较熟悉了。这里我想讨论一下全局变量的问题。全局变量曾经是fortran最大的困扰,解决方法就是common,但common的缺陷也是显而易见的。fortran90的解决方法是module。module提供了一个与任何使用该module的主程序和子程序之间的显式的接口。module中的所有数据结构和/或子程序可以在任何需要的地方使用,同时使用module的好处是编译器可以在编译阶段防止common块使用时可能导致程序崩溃的错误。
  
module由两部分组成。一是定义部分包括变量定义和接口定义。二是自程序部分。示例如下:
  
module mymodule
  
type myvector
      real, dimension(, pointer :: vector
      integer                     :: length
end type myvector
  
interface myminus
      module procedure myminusvector, myminusscalar
end interface
  
contains
  
subroutine myminusvector(inputvector)
!
type (myvector):: inputvector
inputvector%vector = inputvector%vector * -1.
!
end subroutine myminusvector
  
subroutine myminusscalar(inputscalar)
!
real  :: inputscalar
inputscalar = inputscalar * -1.
!
end subroutine myminusscalar
  
end module mymodule
  
module的使用十分简单:
use mymodule

评分

1

查看全部评分

发表于 2004-2-3 15:39:32 | 显示全部楼层 来自 天津

回复: 【讨论】Fortran 与 C

"2)如果需要根据读入数据N来定义一个数组的大小。  
在C里面可以通过指针来实现,动态的定义该数组,并且该指针可以定义为全局变量。这样该指针所指的数组也变成了全局变量  
现在Fortran90也可以通过指针来定义一个动态数组。但是好像该数组不能放在common语句中,也就不能方便的被其他子程序调用。只能通过函数参数来传递数据。如果子程序需调用这样的数组很多的话,就导致该子程序的虚拟参数过多,调用起来不方便。  
以上是我个人的一些看法,望大家一起来探讨一下。"
  
我就曾经做过,要先用POINTER定义指针,
POINTER P
再COMMON
COMMON P
其实更好的解决办法是用像freepu说的用module
发表于 2004-3-27 12:21:50 | 显示全部楼层 来自 河南新乡

回复: 【讨论】Fortran 与 C

很好
发表于 2004-3-28 08:32:08 | 显示全部楼层 来自 江西南昌

回复: 【讨论】Fortran 与 C

我正在用FORTRAN编有限元程序,在一边编写一边调试过程中就发现其速度相对C要快些。
要使用全局变量,在FORTRAN90和VF6.5中只需在MODULE中定义好,在使用到这些变量的主/子程序中只需USE 该MODULE名即可,在任何一个程序中改变了变量的值,那么在任何一处该变量的值就发生了改变,程序调用中无需传递参数或返回参数值。而局部变量则只在子程序中定义,子程序结束该变量也就无效了。
要定义动态数组的话,只需在MODULE中定义迟型数组(只知道数组维数不知道大小),而后在程序中USE 该MODULE名,再给该数组分配空间,实现动态数组的定义。在传统有限元编程中,使用两个预先定义好的整型数组和实型数组,确定实际内存空间需要后还要去检查内存需要是否大于预定义数组大小,没有使用动态分配数组方便。
示例程序(有限元网格信息的获取部分)如下:
MODULE DATA_MODULE
  
INTEGER, POINTER :: EL_NODE(:,       ! 单元组成节点
REAL, POINTER :: ND_XY(:, )     ! 节点坐标
  
   ......
  
END MODULE
  
PROGRAM MAIN
  
  USE DATA_MODULE
      
  CALL INFO_MESH()  ! 获取有限元网格信息
  
   ......
  
END  
  
SUBROUTINE INFO_MESH()
  
    USE DATA_MODULE
  
   ! 确定节点、单元总数
    CALL NUM_ND_EL()  
    ! 分配单元组成节点、节点坐标数组空间
    ALLOCATE (EL_NODE(3, NELEM), ND_XY(2, NNODE))  
    ! 获得节点坐标、单元组成节点信息
    CALL INFO_ND_EL()  
  
END
  
SUBROUTINE NUM_ND_EL()
  
   USE DATA_MODULE
  
   ! 顺序读取节点坐标文件,确定总节点数NNODE
   OPEN (10, DEFAULTFILE='D:/TEST DATA', FILE='NODE1.DAT', ACCESS='SEQUENTIAL', STATUS='OLD', IOSTAT=IV)
   NNODE=0
   1     READ (10, FMT=*, END=2, IOSTAT=IV)  
   ! 在此没有读入数据,每执行READ语句一次,文件指针下移一条记录位置,直至文件结束
   NNODE=NNODE+1  
   GOTO 1
   2     CLOSE(10)
  
   ! 顺序读取单元节点文件,确定总单元数NELEM
   100 OPEN (12, DEFAULTFILE='D:/TEST DATA', FILE='ELEMENT1.DAT', ACCESS='SEQUENTIAL', STATUS='OLD', IOSTAT=IV)
    NELEM=0
   3 READ (12, FMT=*, END=4, IOSTAT=IV)   
    NELEM=NELEM+1
    GOTO 3
    4 CLOSE(12)
  
END
  
SUBROUTINE INFO_ND_EL()
  
  USE DATA_MODULE
  
  OPEN (10, DEFAULTFILE='D:/TEST DATA', FILE='NODE1.DAT', ACCESS='SEQUENTIAL', STATUS='OLD', IOSTAT=IV)
  READ (10, FMT="(I12, 2F12.5)", IOSTAT=IV) (K, (ND_XY(I, J), I=1, 2), J=1, NNODE) ! NNODE为总节点数  
  
  OPEN (12, DEFAULTFILE='D:/TEST DATA', FILE='ELEMENT1.DAT', ACCESS='SEQUENTIAL', STATUS='OLD', IOSTAT=IV)
  READ (12, FMT="(4I8)", IOSTAT=IV) (K, (EL_NODE(I, J), I=1, 3), J=1, NELEM) ! NELEM为总单元数
  
END
发表于 2004-5-27 14:21:05 | 显示全部楼层 来自 天津

回复: 【讨论】Fortran 与 C

Fortran 90 for Science Students
by Dr. John Prentice of Quetzal Associates.
  
--------------------------------------------------------------------------------
[January 1995]
Below is a note I just sent to the chairman of a physics department which requires freshmen to take a programming class offered by the engineering department. That course has traditionally taught Fortran 77, but there is now a push on from the engineering school to switch to teaching C++. As usual, the arguments being mustered revolve around criticisms of Fortran 77 by people who are too out of touch to know much of anything about Fortran 90. In either case, I was asked by one of the senior physics faculty to contribute my two cents worth about what language they should be teaching. The appended note is the one I sent and it summarizes our corporate experience with C++ and some of our feelings about Fortran 90. Others may find this interesting since this question is arising throughout the academic community.  
John  
  
Dr. John K. Prentice
Quetzal Computational Associates
3701 San Mateo N.E., Suite I
Albuquerque, NM 87110-1249 USA
Phone: 505-883-3706
Email: john@quetzalcoatl.com
  
My note to the Physics Department:  
  
One of the physics faculty members mentioned to me that the Engineering school is considering changing Eng 120 to teach C++ instead of Fortran and that you were soliciting comments about this with regard to physics students. Even though I am not associated with the university, I wanted to contribute my thoughts, which come from a commercial as well as a research perspective. Perhaps they will be of some value to you.  
  
As you know, Quetzal Computational Associates specializes in computational science. We currently have projects computational physics, earth sciences, and agriculture for clients which include DoE and DoD laboratories as well as commercial clients as diverse as hazardous waste companies and grain companies. During the last year, we have developed numerical methods and codes based on them for modeling contaminant flow in porous media, modeling the structural mechanics of resonant sonic drilling rigs, modeling bistatic ground penetrator radar propagation in partially saturated soils, modeling solid dynamics at high strain rates, modeling the phenological development of corn and soy beans, modeling solar insolation in the photosynthetically active spectrum based on first principle atmospheric physics, and developed neural networks for the detection of dust clouds from satellite imagery.  
  
One of our largest computational physics projects is the development of advanced methods for modeling solid dynamics based on first principle physics. This is a multi-year, multi-million dollar project. This code numerically solves the partial differential equations for continuum solid dynamics using a hybrid finite volume/finite element technique, coupled to advanced equations of state and constitutive models for the solids and fluids in the calculation. This code and others we work with are huge number crunching codes, a modest 3d simulation will take 100 or more hours of Cray C-90 time to complete a single calculation. By any standard, they are amongst the largest computational physics simulations being done anywhere in the world. In addition, we are on the forefront in the application of parallel computing to these problems. We have projects to develop parallel versions of our codes for a diverse collection of computers, including networks of UNIX workstations, the IBM SP-2, the Cray T3D, and the Intel Paragon.  
  
For all of these projects, we employ Fortran 90 as our main language. We do some development work in Fortran 77, C, and C++, but we are moving away from those languages as quickly as possible. There are many reasons for our choice of Fortran 90, but first let me say a bit about why we are not enthusiastic about C++. The biggest strength of C++ is probably the availability of relatively inexpensive and high quality C++ compilers for PCs. But that is a pretty minor consideration in our business and it is outweighed by the enormous liabilities we have observed with C++. First, we regard C++ as the weakest of the object oriented languages. Objective C is a far more solid and well designed OOPS language, C++ is really some OOPS capability slapped on top of C. C++ is consequently extremely inefficient, inconsistent, overly large, and enormously difficult to program in. The experience of our clients mirrors our own, and in fact many DoE and DoD laboratories are finding that their headlong rush to C++ has been a hideously expensive mistake. I know of several C++ scientific coding projects in the DoE that consumed millions of dollars and tens of man-years, only to be abandoned because the resulting code was enormously inefficient on both traditional serial computers and on their large parallel supercomputers. Similar horror stories abound throughout the programming community at this point. Bill Gates claimed that his biggest mistake in designing their new NT operating system was adopting C++ for the graphics coding, the resulting code took years longer to write than it should have and ran terribly slow. While OOPS is a solid development in the computer science community, I think it is fair to say that C++ is destined to be a passing fad, much like Pascal and Ada before it.  
  
The main reason C++ has attracted the attention it has in the scientific community is because Fortran 77 was a terribly outdated language. The many weaknesses of Fortran 77 were solved with Fortran 90 however. Fortran 90 has every feature in C that is important to scientific programming and most of the features of an object oriented language (it lacks only inheritance and that is likely going to be added in Fortran 2000). However, unlike C and C++, Fortran 90 is designed to generate executable codes that are highly optimized and thus run extremely fast. An example is pointers. Pointers are integral to C and C++ programming and because the compiler cannot determine whether a pointer is aliased, it is impossible for it to determine interprocedural dependencies. The result is a significant degradation in optimization and extremely slow execution speeds (for most scientific codes, C and C++ generally produce code which is commonly an order of magnitude slower than Fortran 90 codes, based on the benchmarks we and others have done). Fortran 90 pointers are designed to give the functionality of pointers, but with restrictions that eliminate issues such as aliasing. From a programming perspective however, an even more important point is that Fortran 90 has more natural ways of expressing the functionality that C and C++ require pointers to express. Because of this, Fortran 90 is a more natural language to program in and the time required for debugging codes is a fraction of that required by C and C++ (C++ is much worse than C, provided you are really employing an OOPS paradigm, since you find yourself spending alot of debug time going up and down inheritance trees). Another important point is that the time required to learn Fortran 90 is much less than the time to learn either C or C++.  
  
Fortran 90 has another major advantage over C or C++. Modern scientific computing, and computing in general, is moving toward the use of parallel computers. Even PCs and workstations now come with multiple processors, so parallelism is something that everyone from an accountant to a physicist is encountering now. A major problem in programming parallel computers however is the linear memory model that is inherent to all procedural programming languages, with the singular exception of Fortran 90. A linear memory model is one that assumes that consecutive elements of an array are consecutive in memory. This was a reasonable assumption on traditional computers, but it is completely incorrect on a parallel computer. Only Fortran 90 has addressed this problem and providing standardized language support for parallelism. This support includes array syntax and many intrinsics for doing array operations varying from reduction operations such as array sums to matrix operations. With the use of Fortran 90 operator overloading and polymorphism, one can significantly extend the number of operations that avoid any reliance on the linear memory model. The fact that Fortran 90 moved away from a linear memory model is the main reason that it has become the base for so many data parallel languages such as Vienna Fortran, Fortran D, CRAFT, and High Performance Fortran. The availability of data parallel dialects of Fortran 90 is an especially large factor in favor of Fortran 90. Compilers for High Performance Fortran, for example, are now coming on the market for virtually every machine out there (including networks of workstations) and writing parallel codes in this language is straightforward. Of particular importance is that porting a Fortran 90 code to High Performance Fortran is extremely straightforward and codes written in High Performance Fortran can be run unaltered on a Fortran 90 compiler (with the exception of one HPF construct, the forall, which is being put into Fortran 95).  
  
My own opinion is that scientists today need to know more than one language or one computing paradigm. And I think it is entirely reasonable that students learn C++ before they graduate, though even more important is that they learn how to program MATLAB and a computer algebra system such as Maple or Macsyma. But the issue is what freshmen should learn as their first language and for that I would recommend Fortran 90 hands down. It is a better language for scientific programming and is both easier to learn and use than the alternatives. It is also much more likely to be the language students will be employing in their jobs upon graduation and it is the most promising route currently developing for the programming of parallel computers.
发表于 2004-8-20 03:08:10 | 显示全部楼层 来自 重庆万州区

回复: 【讨论】Fortran 与 C

刚刚做了一个程序,里面有个公共的模块,呵呵。挺方便的
发表于 2004-8-26 10:12:31 | 显示全部楼层 来自 山东东营

回复: 【讨论】Fortran 与 C

我没有使用过FORTRAN,一直以来都在使用C。
据我所知,FORTRAN在科学计算方面功能很强,速度也比较快,但是在图形可视化方面则比较薄弱,基本上没有该功能;而C在这方面有较大突破。
C在程序设计方面采用结构化方式,程序阅读较为方便;而FORTRAN则不然,给阅读程序带来了较大困难。
发表于 2005-7-25 22:58:02 | 显示全部楼层 来自 上海交通大学

Re:【讨论】Fortran 与 C

那么到底对新手来说,用那种语言来编FEM程序更容易上手呢?
发表于 2005-7-25 22:59:44 | 显示全部楼层 来自 上海交通大学

Re:【讨论】Fortran 与 C

我是一个新手,请问再学习和尝试自己编FEM程序,各位前辈有没有什么好的建议呀〉?谢谢!
发表于 2005-7-26 17:33:24 | 显示全部楼层 来自 上海黄浦区

Re:【讨论】Fortran 与 C

最讨厌fortran的common语句和goto

c和fortran在数值计算领域最大的区别就是数组的存取方式:一个是行格式而另一个是列格式
发表于 2005-7-27 09:30:18 | 显示全部楼层 来自 北京

Re:【讨论】Fortran 与 C

呵呵,一石激起千层浪,继续继续,道理不说不明,理不辨不清

其实随着FORTRAN语言发展,它本身吸收了不少其他语言的特点,象楼主所说的一些东西,在FORTRAN95里好像基本都支持了,子程序采用动态数组只需使用模块就行。

早期,为什么使用FORTRAN比C多是因为,前者出现较早,基本上成为了工程界通用语言,拥有的代码遗产比较多,尤其是科学计算领域特别多,而且当时FORTRAN的计算效率远远快于C,不会FORTRAN在大型工程计算领域几乎寸步难行;现在各种语言都优化发展了,好像网上也有二者速度比对的文章,有机会大家可以看看,其实语言是一种习惯、一个工具,最重要的是解决问题,无所谓谁会那种工具就如何如何的,有人曾提议过想对FORTRAN代码进行改写,好像没人感兴趣,而且我想也不太可能,因为改写之后,用户群多大都存在疑问。

使用语言在于用其长,对症下药即可,现在多种语言混和编程也不是技术含量多高的问题,建议大家试一试,呵呵

有人说FORTRAN中没有画图的模块,这也不对,其实还是有的,用起来也不是太难,只是大家不常用罢了,有兴趣可以试试。

前面有人问FEM用那种,我觉得入门着用FORTRAN要容易一些,因为你拥有的源代码资源将会很多的。

我觉得单纯的讨论,那种语言熟优孰劣是没有意义的,合理运用该语言发挥长处,挖掘其潜能,用它实现你精妙的编程思想,这才是正途。

上面是我的一家之言,肯定有不当之处,欢迎大家探讨,也欢迎拍砖。

评分

1

查看全部评分

发表于 2005-7-28 18:28:37 | 显示全部楼层 来自 黑龙江哈尔滨

Re:【讨论】Fortran 与 C

高手不少~!向你们请教了~!呵呵~!
您需要登录后才可以回帖 登录 | 注册

本版积分规则

Archiver|小黑屋|联系我们|仿真互动网 ( 京ICP备15048925号-7 )

GMT+8, 2024-3-29 21:12 , Processed in 0.075316 second(s), 15 queries , Gzip On, MemCache On.

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表