Lifting Fortran for EUD and modeling automation

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.

MetaCalculus and NeoFortran

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.

MetaCalculus Hardware Experimentation

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.

Fortran Calculus – The NeoFortran Prototype

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.

Automation laboratories and apparatus to occupy Linux

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.