🚀 go-pugleaf

Code generating has been an active research area at Kent State for quit
sometime.
GENTRAN (FORTRAN code generator) and GENCRAY (parallel CRAY FORTRAN generator)
are two packages that do what you are looking for. For more information contact
Dr. Paul S. Wang (pwang@cs.kent.edu) and/or  Sanjiva Weerawarana
(saw@cs.purdue.edu)
---------------------------------------------------
Yaser Doleh   <doleh@math-cs.kent.edu>
Department Of Mathematics & Computer Science
Kent State University
Kent - OH 44242

	When I was at Bell Labs, we did something for the biophysics
department. Dan Warner (numerical analysis) modified his stiff ODE
solver. I wrote a compiler which had stoichiometric equations for its
input. The output was Fortran.  That was 10 years ago---it's still in use
by Truman Brown at Fox Chase Cancer Center at U. of Penn. We considered
it a real prototype. BTW-we used Lisp interpreter to process the intermediate
code. Really flexible system.

===============================================================================
Steve (really "D. E.") Stevenson           steve@hubcap.clemson.edu
Department of Computer Science,            (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906


-- 
===============================================================================
Steve (really "D. E.") Stevenson           steve@hubcap.clemson.edu
Department of Computer Science,            (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906

I tried to reply to your request for the data structure survey, but it
bounced. Send me another e-mail note.

steve

-- 
===============================================================================
Steve (really "D. E.") Stevenson           steve@hubcap.clemson.edu
Department of Computer Science,            (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906

>>>>> On 17 Aug 90 10:27:00 GMT, cammerdl@camme.UUCP (R. De Langhe CAMME project) said:
R.> On our site, lots of scientists are developping modeling programs to
R.> simulate all kinds of hydrodynamical systems like oil-slick evolution,
R.> wave-height predictions, etc.
R.> Would it not be much more easy and efficient if these scientists could
R.> use an algebra-like programming language, in which they can easily recognize
R.> errors, or proof correctness of an algorithm, etc. and let some kind of a
R.> source-code generator parse their expressions into C (or FORTRAN) ?

This is certainly one of the weakest areas in the field of "scientific
programming".   

I found a very interesting article in the Journal of Computational
Physics in 1966 describing a package written in Algol which wrote 3D
plasma dynamics programs in Algol.  Since this work was done in
1964-1965, it is a bit shocking that in 25 years such techniques have
made such negligible intrusion into the day-to-day activities of
scientific programmers.

One package that I do know of is ELLPACK, a system for generating
FORTRAN programs for solving elliptic partial differential equations.
I believe that Purdue University has the copyright, and that they are
working on an elliptic PDE expert system based on it.

The introduction of higher-level/object-oriented languages will
presumably make the construction of many programs easier, since a
collection of "building blocks" can be constructed to take care of a
lot of the coding detail.   Ken Wilson's group (then) at Cornell was
using C++ for such a project.  I heard that Wilson left Cornell, but I
don't know where he went, or if the "Gibb's Project" followed him.
--
John D. McCalpin			mccalpin@perelandra.cms.udel.edu
Assistant Professor			mccalpin@vax1.udel.edu
College of Marine Studies, U. Del.	J.MCCALPIN/OMNET

As I understand it, programs such as Mathematica and Maple try to
run directly off of the algebra equations. Both are available for
Crays.

Mathematica is *way* too costly, but Maple is pretty reasonable.

Never having used either, though, I don't know if they're worth the
effort.  Are they?  If not, what's wrong with them?  Too limited
somehow?  Too slow?

-Drew

mccalpin@perelandra.cms.udel.edu (John D. McCalpin) ("jdm>") writes:
in response to cammerdl@camme.UUCP (rdl De Langhe CAMME project) ("rdl>")

rdl> Would it not be much more easy and efficient if these scientists could
rdl> use an algebra-like programming language, in which they can easily 
rdl> recognize errors, or proof correctness of an algorithm, etc. and let some 
rdl> kind of a source-code generator parse their expressions into C 
rdl> (or FORTRAN) ?

jdm> This is certainly one of the weakest areas in the field of "scientific
jdm> programming".   
jdm> 
jdm> I found a very interesting article in the Journal of Computational
jdm> Physics in 1966 describing a package written in Algol which wrote 3D
jdm> plasma dynamics programs in Algol.  Since this work was done in
jdm> 1964-1965, it is a bit shocking that in 25 years such techniques have
jdm> made such negligible intrusion into the day-to-day activities of
jdm> scientific programmers.

Generation of standard Fortran or C code to evaluate an algebraic expression
has been a standard feature of symbolic algebra programs such as MACSYMA 
for at least 15 years.  Mathmatica supports similar functionality.
I have never seen it used much.  Anyone care to speculate on why this is?
 
jdm> The introduction of higher-level/object-oriented languages will
jdm> presumably make the construction of many programs easier, since a
jdm> collection of "building blocks" can be constructed to take care of a
jdm> lot of the coding detail.   Ken Wilson's group (then) at Cornell was
jdm> using C++ for such a project.  I heard that Wilson left Cornell, but I
jdm> don't know where he went, or if the "Gibb's Project" followed him.

I have heard alot of enthusiasm for object oriented programming, but
it seems like you can create incompatible objects almost as easily as
non-shareable libraries.  I hope I am wrong.

jdm> John D. McCalpin			mccalpin@perelandra.cms.udel.edu

David States

...1964-1965, it is a bit shocking that in 25 years such techniques have
...made such negligible intrusion into the day-to-day activities of


Humm, well there are some that use tools ;>

LLNL folks wrote BASIS.

Mohler et al. have derivatives of MATHLIB, see MathWorks

someone or another wrote GAUSS (pc only ?)

MathSoft's MathStation seems very sexy (write WYSIWG text, it
                          computes, or generates fortran code)

Universal Technical Systems, TK Solver Plus

Some interesting things can be done with GPSS too.

Not to sound commerical or anything, but all these goodies are listed
in the Sun Catalyst Guide (2000 application programs, and related
goodies).
--
----------------------------------------------------------------
Keith H. Bierman    kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043

In article <1990Aug17.214800.16650@athena.mit.edu> abennett@athena.mit.edu (Andrew Bennett) writes:



   As I understand it, programs such as Mathematica and Maple try to
   run directly off of the algebra equations. Both are available for
   Crays.

   Mathematica is *way* too costly, but Maple is pretty reasonable.

   Never having used either, though, I don't know if they're worth the
   effort.  Are they?  If not, what's wrong with them?  Too limited
   somehow?  Too slow?

   -Drew

Both are symbolic packages; not necessarily wonderful for numerical
approximations. I defer to those that have run the codes (like the
folks at NCSA) but I don't recall Mathematica on the Cray being a
speed demon, one article suggested that for solving a large gravity
model it was only 4x a Sun (not that Suns are slow ;> but one expects
more from a Cray).

MathStation _sounds_ like a super package. However, I am not currently
involved in the kinds of projects for which it is suited. I look
forward to a NetReview ;>

--
----------------------------------------------------------------
Keith H. Bierman    kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043

-----On 17 Aug 90 22:16:48 GMT, usenet@nlm.nih.gov (David States) said:

David> Generation of standard Fortran or C code to evaluate an
David> algebraic expression has been a standard feature of symbolic
David> algebra programs such as MACSYMA for at least 15 years.
David> Mathmatica supports similar functionality.  I have never seen
David> it used much.  Anyone care to speculate on why this is?

Because they generate extremely inefficient code (at least Mathematica 
does-- I have very little experience with Macsyma).  For instance, I
periodically use Mathematica to generate partial derivatives.  I then
output expressions in some human readable format and edit them 
extensively to turn them into semi-efficent C code.

Part of the problem is that Mathematica's expression simplification
function doesn't work very well at all.  And for generating code, some
techniques should be used, such as common subexpression elimination,
to turn a single algebraic expression into more than one line of code.

Another part of the problem is I dislike the coding style that
Mathematica outputs.  The code requires use of a set of C macros
(supplied), but would make that section of code's style different from
anything else in our program, which is a distinct code maintenance
disadvantage.

Were I using FORTRAN, I'd be much better served by an automatic code
differentiation package, such as NETLIB's JAKEF.

--
Steve Hamm ----------- Motorola Inc. Semiconductor Sector CAD  
                       3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
Ph: (512) 928-6612     Internet:  hamm@austoto.sps.mot.com   
                       UUCP:      ...cs.utexas.edu!oakhill!austoto!hamm

In article <1116@camme.UUCP> cammerdl@camme.UUCP () writes:
>On our site, lots of scientists are developping modeling programs to
>simulate all kinds of hydrodynamical systems like oil-slick evolution,
>wave-height predictions, etc.
>The problem for these guys, as for all scientists using computers I guess,
>is that they are stuck to that little bit of programming languages they
>know : FORTRAN. Creating code that runs under every input data, produces
>results, or even results that might be correct, takes several weeks per
>tiny peace of code.
>I was thinking that the biggest problem for them is : converting their
>(often genious) algebra-solutions for a given model, into some
>programming language like FORTRAN they're not used to 'speak'.
>
>Therefore I'd like to ask for opinions about this problem, and if someone
>has developped or has under development such algebra-syntax parser/code
>generator.

Most symbolic algebra programs have some sort of primitive Fortran
generator; i.e. they can generate one line (plus continuation lines)
of unoptimized Fortran from a scalar expression.  It's easy to do that
much; after all, Fortran was originally designed for that.

Many people have gone a lot further than that.  Grant Cook, I, and
others are involved in one such effort.  For details see Grant Cook's
paper "ALPAL, a Program to Generate Physics Simulation Codes from
Natural Descriptions", in the first issue of International Journal of
Modern Physics C.  The references should help track down some of the
other efforts in this area.

ALPAL is built on Macsyma, and Grant Cook substantially improved
Macsyma code generation capability to support it.  A few of these
extensions are available with the DOE-Macsyma version of Macsyma, from
the National Energy Software Center in Argonne, Illinois 60439, USA.

There are not any advanced codes in this area which exploit the power
of large symbolic algebra programs and which I could recommend as
being freely available, general-purpose, and fully engineered beyond
the research level.
Jeffrey F. Painter			painter@lll-crg.llnl.gov
L-316, Lawrence Livermore Laboratory	415-422-0675, FTS 532-0675
Livermore CA  94550   USA               415-423-7613, FTS 543-7613