Optimization and Correlation are embarrasingly parallel search processes which can be “shotgunned” with many search methods and starting points. Here is a Google spreadsheet containing links to the graphical output of a serial MOB search job. It shows what would be a typical massively-parallel run a MetaCalculus user might make, not just on a trivial 2D function like this that can show contour graphs, but problems of many dimensions and much greater complexity, simplified by stacking MetaCalculus holons.
With so many (1200+) searches like this, captured in a database, many would converge, as shown, but requiring hardly more elapsed time than a single search. Most engineering textbook-size problems of any complexity, even far-exceeding today’s state of the art, would complete in the blink of an eye like Google searches do now. The planned next release will simplify and fully automate this parallelized optimization, so that this MOB job will then require only a single FIND statement and starting-grid generation as if it were only a single search. It would be fanned out to many processors (or cores) in parallel.
Yet, this shows only a single MetaCalculus holon. Much deeper nesting is practical today than in the PROSE era when run costs of this scope would be prohibitive. Deep nested constrained optimization is practical for pennies now, but would have cost hundreds or thousands of dollars then, as each search level multiplies the number of model-call iterations. This is unplumbed territory of simultaneous optimization of multiple objective functions, constraint sets, and unknown-parameter sets, holding much promise for new modeling vistas.
A truly monumental gain is provided by MOB optimization as the top-level of a problem structure whose output is interfaced through a relational database. It removes the firehose of data like was produced in this MOB run. Even if what is being optimized is a massive simulation, the final output is merely a row of summarizing numbers extracted from a table. Thus it doesn’t matter if the output device is just a cell phone. The key information is just as easy to access from all sectors of society, whether from K-12 classrooms or advanced research labs.
In 2004 the ACM dedicated its September Communications issue to EUD (End-User Development), and advocated “meta-design” as its manifesto.
Meta-design extends the notion of system development to include users in an ongoing process as co-designers, not only at design time but throughout the entire existence of a system.
I used this same concept in a similar appeal at the Aerospace Corporation years ago aimed at extending Fortran via hardware architecture to support automatic differentiation.
Now I am appealing for developers to participate in a modern campaign to extend Fortran beyond its programming paradigm to a higher paradigm of automated modeling. The initial objective is to occupy Linux at the “penthouse level” where modeling and model prototyping by R&D end-users is the priority, not just system programming or even just application programming in the self-limiting professional IT scenario.
I have provisioned Linux VPS servers with Trac-Git managed development and usage laboratory environments for end-user QA and VAR source-code development accessed via Linux USB drives. It is ready for collaboration in open-source co-development of a “NeoFortran” for all platforms.
During the Apollo program, a new modeling calculus of non-linear computation emerged, based on a new understanding of the rules of differential calculus applied as arithmetic rather than algebra. This high-order modeling calculus was congruent with and eventually became an extension of Fortran. The precision of the differential arrays (gradients, Jacobians, and Hessians) evaluated by this exact arithmetic gave rise to very abstract modeling of multidimensional inverse problems by stacking (nesting) them in hierarchies. Thus evolved an iterative-math architecture of Fortran to automate the modeling of combined simulation and optimization applications. It emerged commercially in the time-sharing marketplace as the PROSE modeling language in 1974. It introduced a paradigm of “holon modeling”, aimed at R&D end-users working in do-it-yourself (DIY) mode, prototyping science applications of equations they formulated.
The following example of an optimal design and control problem illustrates this holon paradigm. It contains three holons in a “holarchy” stack, each modeling a whole system problem, including an optimization holon containing a two-point boundary-value holon containing an initial-value holon involving three simultaneous differential equations.
Global all Problem OptDes ! Unconstrained optimization problem Find A in TwoPt by Hera to Maximize Obj End Model TwoPt ! Two point boundary-value problem Y0 = .7 ! Guess for initial condition Find Y0 In Traj by Ajax to Match Y1 Obj = Z/2 + A**2/2 End Model Traj ! Initial-value problem Y = Y0; X = 1; Z = 0; T = 0 ! Initial conditions DT = 0.25; Tf = 1 Initiate Isis for Diff Equations Zdot/Z, Xdot/X, Ydot/Y Of T Step DT to Tf Integrate Diff By Isis Y1 = Y Terminate Diff End Model Diff ! Differential Equations Zdot = X**2 + Y**2 ! Objective differential equation Xdot = -A*X + Y ! State differential equation Ydot = X + A*Y ! Control differential equation End
This is merely a textbook calculus-of-variations problem. Yet it illustrates how such a sophisticated math application can be abstracted to the very-high order essence of a problem definition, as a structured hierarchy of three sub-problem templates, without requiring any knowledge of numerical methods. Its translation automates the generation of a composite iterative solution process, taking advantage of nested algorithmic differentiation of numerical-integration algorithms and differential geometry coordinate transformations, nesting and denesting the boundary-value problem with respect to the optimization problem. It has no input/output statements here, because the referenced solvers (Hera, Ajax, and Isis) have their own built-in report generators, which need no control information in this default case.
This represents the entire program at the modeling paradigm level, written in the FortranCalculus2 language. It is contrasted with the original programming of this application in the Fortran II language where we have the programming paradigm level in the structure of an algorithm, instead of the algorithm being automatically synthesized by the problem structure as above. In this case it is using the quasilinearization method of Bellman and Kalaba.
Although Fortran II represents the state of the programming art more than 50 years ago, and Fortran has made many forward strides since then, the algorithmic flavor of this Fortran II program would be little different if it were written in F95 or F2003. Yet the abstraction represented by the FC2 modeling paradigm is a quantum leap in descriptive scale and automation. Note the more than 5 to 1 reduction in the number of lines of code, and the total separation in problem formulation from any kind of algorithm design.
The FC2 modeling paradigm is an extrapolation of higher math simplification, like the GUI modeling motif of System Dynamics (STELLA, VENSIM, etc.). This SD GUI modeling motif is applying automation to bypass about seven years of mathematical gymnastics of algebra, trigonometry, analytic geometry, differential and integral calculus and differential equations, so that it can be interactively taught in grade school. These two modeling paradigms can be easily merged in the agenda I am proposing, and embarrassingly parallel optimization searching via MetaCalculus can apply system dynamics to tablet computers as portals even more effectively than web searching.
The MC Fortran dialects are the only languages fully supporting MetaCalculus today, but it has a 40-year history, including more than a decade of marketing to Fortune 500 firms in the mainframe time-sharing era. After 1980, however, this market quickly vanished, as development of interactive graphics desktops trumped system-science modeling, starting the detour into staple office workflow software with its high-demand density and immense economy of scale. It reshaped the computer industry while deferring scientific advances another 30 years.
Yet it is a temporary detour, because office software reached its “stratospheric” utility limit by 2000, and like a hammerhead storm cloud has topped out and spread mostly in style to maintain market dominance, because its economic demand is limited by population size. It has taken the path of Paris fashions to periodically turn over consumer demand by changing styles. The same thing is happening with cell phones and will again with tablets. Yet programming is not advancing and Moore’s law has been dammed up by the power wall, forcing software to go parallel.
We tried unsuccessfully to leapfrog this detour by applying PROSE’s MetaCalculus architecture design to hardware during the first PC decade. We built two generations of very-high-level language computer architecture for PC coprocessors, first at the Aerospace Corporation as a "blank slate" host for microcode emulated virtual machines and then at a microcomputer spinoff, IMS (International Meta Systems). IMS microchip fabrication ran into financial difficulties and the MetaCalculus hardware design was sacrificed for a business strategy of emulating other microcomputer chips.
I subsequently re-implemented MetaCalculus, purely in software, as an overloaded Fortran generator for 32-bit 386 PCs, VAX, and Cray machines, with financial assistance from DuPont, a longtime PROSE user.
As Fortran Calculus and FC2 have shown, the MetaCalculus modeling paradigm is a natural self-organizing extension of the Fortran programming motif, which modelers (those who convert science to equations) find natural to the way they think about applying operators to simultaneous variable system models, without having to indulge in numerical analysis, usually foreign to their scientific skill base. In this sense, it is fundamentally different from MATLAB in its intent, seeking a higher expression of mathematics.
Thus I believe it can become a candidate for a new “NeoFortran” modeling-level standard, merging with all of the current programming-level standards, up to and including the current Fortran standard.
The MC Fortran execution environment is a non-interpretive extension of the Fortran runtime system in which formulas execute in two modes, calculus (differential arithmetic) mode and non-calculus (ordinary arithmetic) mode inside overloaded subroutines (called models), according to a mode switch which also specifies the order of differentiation. In these model contexts, double-real cells are bifurcated unions of integer pointers (to derivative data-structures) and floating-point numbers. In calculus context, the real numbers are constants of differentiation, and operator-contained endian-based discrimination logic is used to distinguish the union role (pointers or constants). The EQUIVALENCE statement is used to form the unions. Thus there is no need for calculus type declarations, enabling the two levels of language to blend seamlessly.
My motivation is to occupy Linux at the “penthouse level” of application science with vertical evolution of MetaCalculus wrapper languages and GUIs which generate Fortran execution code. I am seeking developers assisted by end-users in a peer process to re-cycle Fortran applications for optimization via porting them to MC Fortran dialects, and to further extend the modeling features into broadly diversifed vertical markets via evolution of application-specific modeling media extensions of MC Fortran.
During the last 10 years, following another startup experience of using compiler-compilers for WebCode generation, I have been enhancing MetaCalculus Fortran on Linux to support client-server cloud computing. Intending to start a community open-source development of NeoFortran business, I recognized that in this GUI era, a higher stack of “outerware” would be mandated to build upon the NeoFortran “middleware”, and that a higher degree of automation would be required for community collaboration.
The experience of developing very-high-level computer architecture had involved rethinking the challenge of provisioning such a computer with compilers and operating software. The legacy of metacompilers like Tree-Meta, as “highest-level language” (BNF) translation processes, contributed largely to this conception. In the metacompiler-extension theory we conceptualized, the translation-execution process was reduced to an idealized syntax-semantics image (a “metacomputer”). Since metacompilers could compile themselves, they could self-mutate like shape shifters. And since the compiler-interpreter pair (metacomputer) in this architecture was the mutated image, it could evolve as an analog of genetic reproduction, in a process we called “genetic recursion”.
When the Yacc utility of Unix subsequently appeared on the scene, it had a tragic flaw which interupted the genetic recursion it was capable of. Unlike Tree-Meta which had parse-tree “unparsing” rules to complete its code generation, Yacc used C for semantic action code as a direct target of the parse rules. So it sabotaged its own genetic recursion, introducing “surgery” in C instead of grammar “mutation”, thereby requiring round-trip engineering for end-to-end (grammar-to-code) evolution. When GUIs came on the scene a decade or so later, they repeated this same mistake with metaphoric tools like Glade. No one seemed to notice that they were violating the age-old taboo of FORTRAN–“Thou shalt not edit object code”.
Having observed this dual impediment first hand with both compiler compilers and GUI builders, I knew I would have to find a remedy if MetaCalculus was to realize its potential of meeting the highly diversified needs of R&D and education. So I lifted my focus to the higher context of automating round-trip engineering by managing the reversible design “digestion process” of language and GUI translation from metaphoric states (EBNF metalanguages and widget pallets) to execution states (C or Fortran code) using “assembly-line archives” and reconciling the intervening state-changes incrementally using differencing editors like Meld in automated manufacturing stages.
This higher context of automated round-trip engineering fits into the space of what is now called an IDE. So I designed two GUI-based “escalator-IDEs”, one wrapping GUI builders like Glade2, Glade3, and GWT, and the other wrapping compiler-compilers like Yacc, Bison, RecDescent, and DParser. These “interface wrapper” development IDEs are designed for RAD evolution of modeling media (application-specific GUIs and languages) to support diversified end-user DIY modeling above the NeoFortran level.
I also developed a Perl menu-driven IDE for MC Fortran usage and maintenance, to meet the special needs of end-user R&D prototyping and science exploration, as opposed to software development for others. This kind of “richchet design and development” is far more evolutionary than specification-driven software development, and requires data management tools that professional programmers seldom need.
Now I am extending this ensemble further to support parallel MOB searching where massively parallel jobs output to a database which filters global optimization searching so the sorted output can be viewed with tablet computers producing smaller and better summaries than Internet search engines.
I believe the convergence of MetaCalculus Fortran with hardware and the new era of parallel processing can forge a renaissance of the original R&D market-development history of the industry. I am offering this codebase to start a Fortran community project, and I am seeking financial support to establish it. We are planning a crowd funding campaign to support this renaissance.
Fortran was once the foundation platform for higher languages dedicated to end-user modeling. That role was subsequently usurped by the system language C as an assembly-language surrogate, largely for recycling old software. Then C++ extended the OOP fad. But further diversified languages supporting this dubious fad were the primary result rather than modeling automation. End-users were largely excluded. Now we have GUIs to add to that media stack, and parallel processing in which Fortran is the best platform. Using modern Fortran rather than C++ to uccupy Linux and then Windows can be the first step to unifying the mass movements of the software community in a higher “penthouse” focus above operating systems.
Several independent dialects of Fortran have also been created over the years, including:
You can edit this website using the Edit Page link at the bottom of each page. Feel free to use the Sandbox to experiment. The HowTo contains more information on getting started. For questions, see Fortran Wiki discussion.
Round-trip engineering is a necessity for compiler compilers like Yacc that allow or require “bottom-design surgery” of action code to be articulated independently of the “top design mutation” of BNF or EBNF grammar. I had addressed it by creating an “assembly-line archiving” scheme that could maintain intermediate “digestion” or “meta-design” states between top design and bottom design. I produced “manufacturing scripts” in Perl to stage the Meld editor and other multipane Linux editors for end-to-end reconcilation of design changes from any design state (top, bottom, or in between).
Having this necessity with RecDescent, Yacc, and Bison I applied a GUI-controlled architecture as an IDE superstructure called GAEMY
Two versions of GAEMY have been implemented in Ubuntu Linux, and I plan to extend this design into an IDE called MetaGram, which will be used to shepherd Bison, RecDescent, and DParser, among others.
The planned use of MetaGram will be to produce translators and spiritext compilers for various MetaCalculus dialects, including its NeoFortran dialects (interoperable as G95 generators), and “wrapper translators” for MC dialects of Python and other so-called dynamic languages.
Today’s GUI-based mathematical software products are tool benches for numerical analysis, not science modeling, per se. They are reductionistic rather than holistic. Thus they have restricted mathematical software development to a cul-de-sac market of about a million users worldwide. The market leader has no significant presence in K-12 STEM education. Yet System Dynamics, a far simpler simulation methodology, has a growing presence in K-12, as testified by among others, its originator, Jay Forester:
We are developing a foundation for kindergarten through 12 grade education based on system dynamics. It’s much easier to teach system dynamics in grades one through eight than it is any time later, because they have a lot less to unlearn. … By the fifth and sixth grades they can be doing computer simulation models that, for the most part, are now being taught in graduate school.
MetaCalculus simply adds leverage to this scenario. Optimization wrapper GUIs can be implemented supporting System Dynamics for introduction in junior high, especially if the math teachers are already trained in MetaCalculus AutoLabs in college. One can easily imagine the world market growth this innovation can cause, as automation of the scienctific method and optimal-control applications would become commonplace in high schools.
A lesson I have learned in this long journey to advance the Fortran modeling state-of-the-art is that there must be a shared environnment where whole communities of developers and end-users can collaborate in co-development and testing of prototypes as well as ideas. This scenario provides the best working solution. It combines offline and cloud computing with shared standard Linux multiple desktop interactive sessions, pre-configured and common to all users.
In a startup I co-founded in 2001 I invented a tooltip sub-hypertext for wiki-like website compilation of language source-code in-situ documentation and software maintenance. Initially focused on embedded software maintenance markets, the initial focus was the C-language, and a demo website of the Apache2 source code was used as proof of concept, supporting such features as inline macro expansion. Yet my longer-term goal was using it for semantic-intensive languages like MC Fortran. This image illustrates the use of a tooltip with embedded links to standard popups like this.
Standard website navigation and annotation features of the “Spiritext sub-hypertext” that were language-specific could be compiled as an extension of the language translation process. This image illustrates some of those features.
Then, after website generation, application specific annotation could be added by website viewers as permanent footnotes or temporary collaborative notes with emailed retrolinks for dialoging with callaborators.
See this link for examples of Fortran Calculus websites generated by the current Spiritext generator.
Round-trip engineering is a necessity for GUI builders that allow or require “bottom-design surgery” of callback code to be articulated independently of the metaphoric “top design mutation” of the GUI widget pattern. I had a similar problem with compiler compilers, and had addressed it by creating an “assembly-line archiving” scheme that could maintain intermediate “digestion” or “meta-design” states between top design and bottom design. I produced “manufacturing scripts” in Perl to stage the Meld editor and other multipane Linux editors for end-to-end reconcilation of design changes from any design state (top, bottom, or in between). Having this same challenge with Glade2 and Glade3 I applied the same GUI-controlled architecture as an IDE superstructure called Everglade.
Three versions of EverGlade have been developed so far. The third version incorporates the Git version-control system as a subsystem.
The Aerospace Research Computer was an experimental QUAD-RISC mini-computer designed as a WISC (writable instruction-set computer) for high-level-language token-emulation from microcode. It was built at The Aerospace Corporation from 1981 to 1983 to validate a theory of virtual-machine evolution called Metacybernetics, derived from metacompiler theory, to evolve high-performance very-high-level language virtual machines like PROSE. These virtual-machines were intended to be the core CPUs of logic entities called “metacomputers”, which were encapsulated software interpreters extended by hardware, especially hardware for algorithmic differentiation arithmetic.
In MetaCalculus, a holon is an iterative multidimensional calculus process, created dynamically by a template. It is composed of a solution engine as operator and an equations model as operand. The template alphabet contains three operator/operand classes: Optimization, Correlation, and Simulation. This diagram shows three stacked holons in profile, resulting in the nesting of automatic differention.
This diagram is potentially a modeling GUI motif to generate NeoFortran, in which the white boxes are the visible code defining a problem stack, the blue, red, and green boxes are solver engines, and the gray frames highlight differentiation contexts.
This programmed example was taken from the Appendix of the textbook, Quasilinearization and Nonlinear Boundary-Value Problems This is only one of many example problems from this text, which are solved by quasilinearization in a similar unified program structure, where the context is that of the algorithm, not a problem statement.
PROGRAM OPTDES(INPUT,OUTPUT) C DESIGN PROBLEM COMMON N1,KMAX,NP,NMAX,HGRID,CX,T,X ~ Y,U,V,H,PREV,HP,A,B,C,NEQ DIMENSION T(250),W(4,500),H(4,4,500) ~ P(4,500),A(2,2),B(2),C(4),PREV(4) C X, STATE VARIABLE C Y, CONTROL VARIABLE C U(=MU), LAGRANGE MULTIPLIER C V(=A), DESIGN PARAMETER C 1 CALL INPUT 2 CALL START C C K ITERATIONS C 3 DO 19 K=1,KMAX C INITIALIZE DO 5 I =1,250 5 T(I)=0. T(2)=0. T(3)=HGRID T(4)=1. T(9)=1. T(14)=1. N=0 PRINT 111,(T(L),L=4,43) NEC=20 CALL INT(T,NEQ,N1,0.,0.,0.,0.,0.,0.) C INTEGRATE P'S AND H'S STORING GRID VALUES N=0 8 DO 11 N=1,NP N=N+1 X=W(1,N) Y=W(2,N) U=W(3,N) V=W(4,N) CALL INTM L=3 DO 9 I=1,4 DO 9 J=1,4 L=L+1 9 H(I,J,N)=T(L) DO 10 J=1,4 L=L+1 10 P(J,N)=T(L) 11 CONTINUE C 6 PRINT 111,N,(T(L),L=4,43 PRINT 111,N,(H(I,J,N),J=1,4),(P(J,N),J=1,4) 111 FORMAT(1H019XI10,4E20.6/30X4E20.6) IF(N-NMAX)8,7,7 7 PRINT 40,K 40 FORMAT(1H0/65X9HITERATION,I3) C C EVALUATE CONSTANTS C N=NMAX A(1,1)=H(2,2,N) A(2,1)=H(2,3,N) A(1,2)=H(3,2,N) + H(4,2,N) A(2,2)=H(3,3,N) + H(4,3,N) C B(1)=-P(2,N) - CX*H(1,2,N) B(2)=-P(3,N) - CX*H(1,3,N) C DET=A(1,1)*A(2,2) - A(2,1)*A(1,2) G=ABSF(DET) IF(G-.000001)200,200,12 C 200 PRINT 201,DET,((A(I,J),J=1,2),B(I),I=1,2) 201 FORMAT(1H020X12HDETERMINANT=,E16.6/(40X3E20.6)) CALL EXIT 12 C(1)=CX C(2)=(B(1)*A(2,2) - B(2)*A(1,2))/DET C(3)=(B(2)*A(1,1) - B(1)*A(2,1))/DET C(4)=C(3) GRID=0. PRINT 45, GRID,(C(I),I=1,4) 45 FORMAT(1H026XHGRID,14X1HX,19X1HY,18X2HMU,19X1HA/ * 20XF10.4,4E20.6) C C NEW VALUES OF VARIABLES N=0 13 DO 14 M=1,NP N=N+1 DO 14 I=1,4 W(I,N)=P(I,N) DO 14 J=1,4 14 W(I,N)=W(I,N) +C(J)*H(J,I,N) FN=N GRID=FN*HGRID PRINT 50, GRID,(W(I,N),I=1,4) IF(N-NMAX)13,15,15 C C COMPARE C'S, PRESENT AND PREVIOUS 15 DO 16 1,5 G=ABSF(C(I)-PREV(I)) IF(G-.000001)16,16,17 16 CONTINUE GO TO 1 17 DO 18 I=1,4 18 PREV(I)=C(I) C 19 CONTINUE GO TO 1 C 50 FORMAT(20XF10.4,4E20.6) END SUBROUTINE INPUT COMMON N1,KMAX,HGRID,CX,T,X,Y,U,V,W,PREV,H,P,A,B,C DIMENSION T(250),W(4,500),H(4,4,500),P(4,500),A(2,2),B(2),C(4), * PREV(4) C N1, INTEGRATION OPTION C KMAX, NUMBER OF ITERATIONS C NP, NUMBER OF GRIDS BEFORE PRINT-OUT C NMAX, TOTAL NUMBER OF INTEGRATIONS IN INTERVAL C HGRID, GRID SIZE C CX, X(0) C READ 110,N1,KMAX,NP,NMAX,HGRID,CX PRINT ID,N1,KMAX,NP,NMAX,HGRID,CX 110 FORMAT(4I4,2E8.2) 10 FORMAT(1H120X14HDESIGN PROBLEM// 1 38X2HN1,6X4HKMAX,8X2HNP,6X4HNMAX,13X5HHGRID,16X4HX(0)/ 2 30X4I10,2E20.6) RETURN END SUBROUTINE START COMMON N1,KMAX,NP,NMAX,HGRID,CX,T,X,Y,U,V,W,PREV,H,P,A,B,C DIMENSION T(250),W(4,500),H(4,4,500),P(4,500),A(2,2),B(2),C(4), 1 PREV(4) C INITIALLY T=0, X(T)=CX, Y(T)=0. A(T)=0 DO 1 N=1,NMAX W(1,N)=CX W(2,N)=0. W(3,N)=0. 1 W(4,N)=0. C DO 2 I=1,4 2 PREV(I)=W(I,1) C K=0 PRINT 40,K GRID=0. PRINT 45,GRID,(W(I,1),I=1,4) 40 FORMAT(1H0/65X9HITERATION,I3) 45 FORMAT(1H026X4HGRID,14X1HX,19X1HY,18X2HMU,19X1HA/20XF10.4,4E20.6 1 /1H019X22HFOR ALL VALUES OF TIME) RETURN END SUBROUTINE DAUX COMMON N1,KMAX,NP,NMAX,HGRID,CX,T,X,Y,U,V,W,PREV,H,P,A,B,C,NEQ DIMENSION T(250),W(4,500),H(4,4,500),P(4,500),A(2,2),8(2),C(4), 1 PREV(4) C L=20 DO 1 I=1,4 L=L+4 T(L)=-V*T(L-20) + T(L-19) -X*T(L-17) T(L+1)=T(L-20) + V*T(L-19) + Y(T(L-17) T(L+2)=Y*T(L-20) + X*T(L-19) 1 T(L+3)=0. C T(40)=-V*T(20) + T(21) - X*T(23) +V*X T(41)=T(20) + V*T(21) + Y*T(23) - V*Y T(42)=Y*T(20) + X*T(21) - X*Y T(43)=0. RETURN END
The now well-known technique of automatic differentiation was co-invented by TRW in the Apollo program, in a state-estimation modeling context used in post-flight analysis of the spacecraft rocket engines. Nested differentiation contexts allowed automation of the scientific method for solving implicit differential equations matching telemetry data from the propulsion and guidance systems.
This is the meta discussion page with links to individual discussion pages below. Discussion about the wiki itself happens on Fortran Wiki discussion. If you would like to discuss a page called Foo, simply create a new page titled “Foo discussion”.
Be sure to leave your name, and possibly even the date, after your comment or question. This helps others follow the discussion.
Nested lists can be used for threaded discussion.
|Fortran 2003 features||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Compiler Version Number||14||8.1.1||4.7/4.8||14.1||14.0.0||5.3.1||12.4 Beta||4||14.9|
|ISO TR 15580 IEEE Arithmetic||Y||Y||P||N||Y||Y||Y||Y||Y||Y||Y|
|ISO TR 15581 Allocatable Enhancements||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Data enhancements and object orientation||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Parameterized derived types||N||Y||N||N||N||Y||Y||N||N||N||Y|
|Procedures bound by name to a type||N||Y||N||Y||N||Y||Y||Y||Y||N||Y|
|The PASS attribute||Y||Y||N||Y||Y||Y||Y||Y||Y||N||Y|
|Procedures bound to a type as operators||N||Y||N||Y||N||Y||Y||Y||Y||N||Y|
|Overriding a type-bound procedure||N||Y||N||Y||N||Y||Y||Y||Y||N||Y|
|SELECT TYPE construct||N||Y||N||P||N||Y||Y||Y||Y||N||Y|
|Deferred bindings and abstract types||Y||Y||N||Y||N||Y||Y||Y||Y||N||Y|
|Allocatable scalars (12)||?||Y||?||Y||N||Y||Y||Y||Y||N||Y|
|Allocatable character length (12)||?||Y||?||P||N||Y||Y||Y||Y||N||Y|
|Structure constructor changes||Y||Y||Y||Y||N||Y||Y||Y||Y||N||Y|
|Generic procedure interfaces with the same name as a type (32)||?||?||?||? (31)||?||Y||Y||Y||Y||N||Y|
|The allocate statement||P||Y||P||Y||N||Y||Y||Y||Y||N||Y|
|Assignment to an allocatable array||N||Y (2)||N||P||Y||Y||Y (2)||Y||Y||N||Y (2)|
|Transferring an allocation||N||Y||N||Y||N||Y||Y||Y||Y||N||Y|
|More control of access from a module||Y||Y||N||Y||N||Y||Y||Y||Y||N||Y|
|Renaming operators on the USE statement||Y||Y||Y||P||N||Y||Y||Y||Y||N||Y|
|The VOLATILE attribute||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|The IMPORT statement||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Access to the computing environment||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Support for international character sets||P (19)||P (19)||Y||Y||N||P||P (19)||Y||N||N||P (19)|
|Lengths of names and statements||Y||Y||?||Y||Y||Y||Y||Y||Y||Y||Y|
|Binary, octal and hex constants||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Array constructor syntax||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Specification and initialization expressions||Y||Y||Y||P||Y||Y||P||Y||Y||N||Y|
|Changes to intrinsic functions||Y||Y||Y||P (9)||Y||Y||Y||Y||Y||?||Y|
|Controlling IEEE underflow||Y||Y||N||N||Y||Y||Y||Y||Y||Y||Y|
|Another IEEE class value||Y||Y||N||N||Y||Y||Y||Y||Y||Y||Y|
|Derived type input/output||N||Y||N||N||N||Y||Y||N||N||N||Y|
|Asynchronous input/output||Y||Y||Y||Y (10)||N||Y||Y||Y||Y||N||Y|
|Stream access input/output||N||Y||Y||Y||N||Y||Y||Y||Y||N||Y|
|ROUND= specifier||Y||Y||P||P (30)||Y||Y||Y (20)||Y||Y||N||Y|
|DECIMAL= specifier||Y||Y||Y||Y||Y||Y||Y (22)||Y||Y||N||Y|
|SIGN= specifier||Y||Y||Y||Y||Y||Y||Y (21)||Y||Y||N||Y|
|Kind type parameters of integer specifiers||N||Y||?||N||N||Y||Y||Y||Y||N||Y|
|Intrinsic function for newline character||N||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Input and output of IEEE exceptional values||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Comma after a P edit descriptor||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Interoperability with C||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Interoperability of intrinsic types||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Interoperability with C pointers||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Interoperability of derived types||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Interoperability of variables||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Interoperability of procedures||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y||Y|
|Interoperability of global data||Y||Y||Y||Y||Y||Y||Y||Y||Y||N||Y|
Legend: Y = Yes, N = No, P = Partial, ? = Not Known
(2) Optional under flag;
(10) implemented as synchronous I/O;
(19) selected_char_kind only;
(20) plus RC, RD, RN, RP, RU, RZ;
(21) plus BLANK=, DELIM=, PAD=, SIZE=;
(22) plus DC,DP;
(30) only for output.
(31) Partial in the 4.9 development version.
(32) These user-defined functions are not to be confused with a type’s structure constructor, which is generated automatically. Structure constructors have also changed in Fortran 2003, e.g. by treating components with default initialization as optional arguments.
Changes November 2014:
Changes between December 2010 and April 2011:
Cray supports ISO TR 15580 IEEE arithmetic, renaming operators on the USE statement, controlling IEEE underflow, another IEEE class value, and the ROUND= specifier.
GNU supports allocatable character length and partially supports assignment to an allocatable array.
HP supports ISO TR 15580 IEEE arithmetic and lengths of names
IBM supports more control of access from a module, renaming operators on the USE statement, and lengths of names and statements.
Intel added finalization, pointer assignment and other items.
Added new columns for Absoft and PGI compilers.
No changes between August 2010 and December 2010.
Changes between April 2010 and August 2010:
Changes between December 2009 and April 2010:
“Compiler Support for the Fortran 2003 and 2008 Standards” is a series of articles in the ACM Fortran Forum by Ian D. Chivers and Jane Sleightholme. Links to previous revisions are given below:
Fortran Forum 29(3), 26-34, December 2010
After modifying the contents of cells in the table, the following Emacs lisp function can be used to synchronize the cell colors with the cell contents:
(defun fortranwiki-update-status-table () (interactive) (save-excursion (beginning-of-buffer) (replace-regexp "#[0-9a-f]+\">Y" "#bbddbb\">Y") (beginning-of-buffer) (replace-regexp "#[0-9a-f]+\">N" "#ffaaaa\">N") (beginning-of-buffer) (replace-regexp "#[0-9a-f]+\">P" "#ffffdd\">P") (beginning-of-buffer) (replace-regexp "#[0-9a-f]+\">\\?" "#eeeeee\">?")))