Fortran Source, Fall 1998

Volume 14, Issue 2
FALL 1998

FEATURES
Make Way for LF95!
Fortran Productivity Tools for Windows
Porting to LF90 or LF95 from Other Platforms

DEPARTMENTS
CEO's Letter
New ISV Products
News Briefs
   Fortran Workshops
    Essential LF90 v4.0 Released
   Fortran Discussions
    IMSL Compatibility
   The Lahey COEX Advantage!
   Free Fortran
Q&A
 

Field tests show that Lahey/Fujitsu Fortran 95, LF95, is as solid as any compiler we've ever released. It generates fast code, diagnoses problems as well as or better than LF90, and offers new porting features such as quad-precision data types and VAX structures.

New in LF95! Faster execution speed. Intrinsic, quad-precision data types. Full Fortran 95 support. More non-standard, legacy features. Fujitsu command-line debugger. C-language support in Lahey ED. Faster compile speed.  Pro edition includes: Fujitsu C compiler. New Visual Analyzer v2.0. Scientific Subroutine Library. Unlimited phone support.

New Pro Edition
LF95 is available in two editions: LF95 PRO and LF95. Both editions offer the following new features: faster execution speed for most programs that use Fortran 90 features; intrinsic, quad-precision data types; full Fortran 95 support; more support for non-standard, legacy features, including Hollerith data and VAX structures; FDB, the Fujitsu command-line debugger; C-language support in Lahey ED; and faster compile speed. LF95 PRO includes all of LF95 and adds the Fujitsu C Language System, Visual Analyzer, and Scientific Subroutine Library, and unlimited phone support (in addition to the free, unlimited e-mail, fax, and postal mail support included with LF95).

How does LF95 differ from LF90?
LF95's new technology does cause some incompatibility with LF90. Here's what we found:

• List directed output is formatted differently.
• GETENV( ) is now a subroutine with two arguments instead of a function with one.
• MODTABLE.TXT no longer exists; modules generate .obj files instead of .lib files.
• Module object files must be included on the LF95 command line whenever the module is USE'd.
• Modules with names longer than 8 characters can be compiled only on drives/volumes that support long filenames.
• You must use -nomap when compiling files that have spaces in their names.
• There's a limit of 50 files open concurrently. This includes the preconnected units 0, 5, and 6.
• You can't control line width and page length in cross reference and listing files.
• -nsav is now the default. Specify -sav if you need it.
• You can't create DOS and Win32s apps.
• -winconsole is the default (and -win32s isn't available).
• LF95 uses -dal by default; LF90 used -ndal. Automatic deallocation is standard in Fortran 95.
• -ap switch isn't available.
• Compile-time global procedure interface checking isn't performed.
• -pca switch isn't available.
• -syn switch isn't available. Use -c, compile only, or run your code through Visual Analyzer.
• -tpp and -t3 optimization switches aren't available. Use -tp and -t4 respectively.
• -wrap switch isn't available. Use the horizontal scroll bar to view long messages.
• -o3 switch isn't available. Global optimization is now handled with -o1.
• -f90 switch isn't available. Use -f95.
• -vax switch isn't available. The VAX and IBM extensions are now intrinsic. If you have name clashes use the EXTERNAL attribute on user-defined procedures that share the same names.
• Argument consistency checking is done at run-time. LF90 did it at compile-time.
• Support for Lahey's non-standard namelist format isn't available.
• Sharing modes aren't available for the ACTION= specifier. Default behavior is DENYNONE.
• BREAK, NBREAK, and INTRUP intrinsics aren't available.
• LF95 uses a different unformatted sequential file format. Convert files with SEQUNF.F90.
• LF95 doesn't support Lahey direct file headers. Convert files with HDRSTRIP.F90.
• Pentium-flaw detection isn't available.
• Compile-time argument checking for transcendental intrinsics (e.g., SIN, LOG, etc.) is done at run-time in LF95.
• LISK is not included. Move to WiSK or Winteracter (or continue to use LF90).

Pricing
The list price of LF95 PRO is US$795. LF95 is US$595. Through January 31, 1999, we're offering a competitive upgrade to LF95 PRO for US$595 and to LF95 for US$395. You can update to LF95 PRO from LF90 v4.5 for US$195 or from earlier versions of LF90 for US$295. Call Lahey or your local reseller and order today!

RealWin v2.0
Indowsway Software
July 1998 - Indowsway Software is pleased to announce the release of RealWin v2.0. RealWin helps Fortran programmers create full-featured Windows applications. Following are some of the key new features:

Dialog Box enhancements
Use built-in real, double precision, integer, hexadecimal, octal, and binary automatic edit boxes with adjustable increment, range checking, and formatting. Write custom edit boxes and do your own syntax and range checking in Fortran. Spinners, trackbars, scrollbars, progress bars, and multi-column edit boxes are now available. Specify colors, fonts, bitmaps, and icons to dress up your dialog boxes. Put a standalone button or other dialog item anywhere on the screen.

Bitmap capabilities
Draw images to bitmaps or create bitmaps from arrays. Let RealWin automatically display a bitmap in a window with automatic scrolling, save it to a file, or print it. These and other new bitmap features support easy graphing, animation, scrolling, screen capture, and interactive drawing.

Over 100 new features
Version 2.0 includes new interfaces to the Windows registry, clipboard, and help system and many more Windows utility routines.

Visit www.indowsway.com/home.htm for details, demos, and a free evaluation version.

GINO-F Bundle v4.2
Bradly Associates Ltd.
GINO-F Bundle is a collectin of portable graphics and GUI development tools offering programmers everything fromsimple line drawings to complex, fully-interactive, three-dimensional diagrams.

The new GINO-F Bundle is now available as an F90 binding as well as the familiar F77 binding. The F90 binding includes long, descriptive names, derived types, pre-defined constants, and optional arguments. The F90 versions of GINO are supplied with a completely new set of documentation and on-line help files, but also include the F77 short-name interface for those customers who wish to run existing programs.

The majority of new functionality in v4.2 has gone into GINOMENU, including new features such as:

MDI windows
GINOMENU applications can now produce MDI (Multiple Document Interface) windows as well as SDI. MDI applications consist of an MDI master window containing MDI child windows, which are constrained within the master client area. Applications take on a more professional appearance using MDI nd GINOMENU has the added benefit of being able to mix MDI and SDI windows within the same application, if required.

Text and value entry grids
The most popular enhancement request has been the addition of text/value grids offering spreadsheet functionality. The grids offer full cut, copy and paste ability with the Windows clipboard or other Windows applications and additional programmable control is given over cell width and height, cell background color, cell text color and grid axes labels.

Sticky widgets
GINOMENU widgets can now have an origin in any one of nine control points, with the added option that a widget can be "stuck" to its parent relative to that origin. This allows for auto-expanding widgets and widgets that are always visible regardless of the user re-sizing its parent window.

Visit www.bradassoc.co.uk for details.

Winteracter v2.0
Interactive Software Services Ltd.
Winteracter is a Win32 user-interface and graphics package comprising visual development tools and a library of more than 300 callable routines.

Winteracter v2.0 will be available on November 27th. In addition to adding LF95 support, major new features will include:

Program Wizard
Provides a quick start to building new Winteracter applications with just a few mouse clicks.

Calcomp HCBS, Lahey Video Graphics, and Graphoria compatibility layer
A set of routines supplied in source form which simplify porting of legacy graphics code.

Editor routine
Convert any Winteracter window into a text editor or viewer. Supports up to 1MB of text.

Upgraded grid (spreadsheet/array) handling
Adds support for menu cells, read-only cells, and run-time column layout redefinition.

Text file printing routine
Print a text file via any of Winteracter's drivers including Print Manager. Control number of rows/columns per page and start/end pages.

These are just some of the many features in this 6-monthly update. Further details of these and other new v2.0 features will be posted at the Interactive Software Services Ltd. web site, www.demon.co.uk /issltd, on the release date.

The problems encountered most frequently when porting code to LF90 or LF95 from another platform are those concerning file I/O and floating point operations.

Let's start with files. Different Fortran compilers use different conventions for unformatted (binary) file output formats; they are not standardized. They also use different conventions for marking the start and end of records. This is why files containing the same "data" written by programs from different compilers will have different sizes and different contents.

Lahey file formats are described in Appendix A of the LF90 and LF95 User's Guide, and in Chapter One of the Language Reference (see the section on "Input/Output").

In addition, data can be stored in either "big endian" or "little endian" format in a file, depending on the machine architecture on which the program is run. On PC/Intel architectures, data is stored in "little endian" form, where the low-order byte is followed by the high-order byte (the "little end" comes first, hence "little endian" -- at least that's the way I see it). Machines built with the DEC architecture (VAX, Alpha, etc.) use the "big endian" form. The reason for this is that file contents reflect the way data is stored internally in RAM.

Converting unformatted files with LF90 or LF95 usually involves opening the file using the specifier ACCESS="TRANSPARENT" (a nonstandard Lahey extension), which allows the file to be read a byte at a time with no assumptions about headers or record delimiters. This allows one to have the same degree of control as when handling files in the C language. For an example of this technique, see the file SEQUNF.F90, provided in the LF90 and LF95 installations.

The big-endian/little-endian problem applies equally to formatted and unformatted files. There are several techniques for dealing with this situation. One way would be to write a program that opens the file with transparent access, reads data into a 2-byte integer (kind=2 for LF90), and swaps the bytes using the ISHFTC( ) intrinsic. Another way would be to use an operating system utility such as the Unix DD utility. Transferring the file over a network using FTP in binary mode would also swap the bytes as necessary. Here is a sample Fortran program for performing the byte swap:

   Program byte_swap
   integer (kind=2) myword
   open (unit=11,file='infile',access='transparent',err=50)
   open (unit=12,file='outfile',access='transparent')
10 read (11,end=50) myword
   myword = ishftc(myword,8,16)
   write (12) myword
   goto 10
50 stop
   end program

Now that we've covered the common issues related to file I/O, we can discuss floating-point operations. It turns out that floating-point, base-10 operations carried out on machines with binary (base-2) architectures and finite precision don't always turn out the way we would intuitively expect them. This is a fairly deep topic in itself, and is the subject of an excellent paper by Bruce Bush, itled "The Perils of Floating Point," available at www.lahey.com/float.htm. We can, however, discuss here the more common issues that pertain to porting.

As a rule, different compilers and architectures will differ slightly in their representation and manipulation of floating-point values, namely in the number of bits used to represent the values and in the round-off behavior associated with certain operations. Lahey compilers use the IEEE format for representing floating-point numbers, which is required for using the Intel numeric coprocessor (i.e., a single-precision REAL uses bits 0-23 for the mantissa, bits 24-30 for the exponent, and bit 31 for the sign). Some compilers also perform code optimization, which can also introduce slight differences. The end result of this phenomenon is that results of numerical calculations may differ noticeably from expected values, or that a program's logical flow may be altered inexplicably.

When numerical results are different, it is usually because calculations are carried near a point of instability (i.e., the intermediate results approach the limits of the machine's precision), and the effect is amplified by subsequent calculations. This indicates that the calculation should be modified to accommodate the finite precision of the machine. In general, it is possible to avoid instabilities and potential bifurcation points by making use of mathematical identities and re-ordering of calculations. One example that comes to mind is the inverse Radon transform, used in reconstructing CAT-scan images. The formula for the inverse transform involves a singularity, while the actual numeric calculation makes use of back-projection combined with a filter (convolution or Fourier transform).

Certain intrinsic functions can produce large differences in output based on small differences in input. For example, suppose you are converting dollars and cents float values to integer by multiplying by 100.0 and using the INT( ) function. Because certain floating-point values cannot be represented exactly in binary, there will be cases where the result is truncated downward and the result is 1 less than the expected value. This particular example is an insidious case, because you cannot see what is happening unless you print the intermediate result in its full precision. This example is based on an actual tech support case, where the program ran fine on an older mainframe, but produced wrong results when run on an Intel-based machine, regardless of which compiler was used. The solution was to use NINT( ) rather than INT( ).

The more common result of differences in numerical precision is the case where the program's logical flow is altered due to comparison of floating-point values in an IF statement. This is the rationale behind a commonly witnessed warning in Lahey compilers:

WARNING: Floating-point comparisons for equality may produce inconsistent results.

Ideally, one should correct this situation by changing the offending expression to a comparison for inequality with a machine- and magnitude-dependent epsilon value (see Bruce Bush's paper for explanation). However, most of us are too busy or under too much pressure to pursue such a remedy. The alternative, often just as effective, is to truncate the extra precision of intermediate results by compiling with the -ap switch (not available in LF95) and, in some cases, turning off optimization by compiling with -o0.

In 1995, Lahey became aware of Fujitsu's quality in the first review of Fortran 90 implementations; the review appeared in the May-June issue of Fortran Journal. In reviews that have followed, Fujitsu has been among the leaders, if not the leader, in quality. While Lahey has been working with Fujitsu to create LF95, they have strengthened this perception.

Lahey has a Fortran suite of more than 8,000 tests. We have run those tests and Fujitsu is fixing any reported problems. Therefore, if you have been using LF90 for your Fortran programs and have reported bugs, you can have high assurance that your programs will execute correctly. License LF95 with confidence.

Porting
One of the problems with porting older programs to Fortran 90 is answering the question, "How much is it going to cost?" "We don't know," is the only reliable answer Lahey can give. It occurred to me to share two porting experiences I've had. My goal is to give you an idea what happened and how Lahey does its porting business and some idea of costs. Remember, every job is different.

1) Approximately 1,800 source files, each a program unit less than 250 lines, poorly documented, spaghetti code, much of it written prior to FORTRAN 77. The problem was to get the code up and running on the PC by September. An important, known problem going in was the use of Hollerith data, especially in initialization.

Because the program units were small, it was "easy" to get a fixed-price proposal with a schedule to get every source file in meaningfully better shape with respect to Fortran 90. Lahey included in its fixed-price proposal: A) Modernize and clean up the code. B) Identify and inventory remaining problems, including possibly-buggy code. C) Submit a fixed-price proposal with schedule to solve B. D) Visit the site for a week to review A, present B, and discuss C. During this first phase, there was no intent to solve the Hollerith data problem except in the most local circumstances and agreed-upon date, while still possible, was not committed to.

Lahey was not awarded this contract. It was awarded to someone who agreed to solve the Hollerith problem by September for approximately three times the Lahey quote (not an excessive amount in my judgment). Later we were told that it might have turned out better if the contract had been awarded to Lahey.

2) Bill sent me 27 files containing code (11), data (9), and Job Control Language (7), plus the output from successful runs (very important). The documentation consisted of a pencil sketch of the job flow and how the JCL, Fortran source, and data files plus intermediate files were connected, plus an occasional comment in the code. Bill agreed to allocate $1,000 at-a-time; he would evaluate progress after I had spent at most $1,000 and decide how much, if anything, he wanted to invest in the next session. We agreed to a finish date.

Bill and I finished the project on time. I created four source files containing a total of 1,216 lines, eliminated every system dependency but one, added Fortran I/O statements for every file, made the direct access file I/O Fortran standard, modernized and cleaned up the code, fixed two bugs, did a little code commenting, and created a DOS batch file to run the job.

Bill and I agreed to do a second port. I created four source files (a total of 923 lines) whose code was highly similar to the first. The total cost for both ports was $6,500.

If you are considering porting Fortran code to the PC, I hope the above examples will encourage you to discuss your project with Lahey -- I enjoy porting. It's worth noting that except for system code (which can usually be minimized), ported Fortran code that executes in DOS can be compiled and executed elsewhere.

I'll be gone until early November to lead workshops in Reston, Virginia, U.S.A.; outside London, England; and in Munich, Germany. I lead the November workshop in Reno. It would be nice to meet you along the way.

Regards,
Tom

Speakeasy
Speakeasy is a user-friendly, high-level computational tool. Speakeasy provides an easy way to perform over 1,000 operations collectively designed to satisfy the needs of students, statisticians, economists, engineers, and scientists. These operations are evoked using basic words from the user's entire natural mathematical vocabulary.

Speakeasy supports all standard types of structured objects -- scalars, 1-D and 2-D arrays, vectors, matrices, sets, and time series. Speakeasy solves arithmetic expressions using these objects.

Speakeasy's high-level language is well suited to the development of powerful, customized applications. Using the intuitive Speakeasy language, non-programmers can develop new operations and applications with mouse-driven front ends. Speakeasy is compatible with LF90.

Speakeasy Computing Corporation
224 South Michigan Avenue
Chicago, IL 60604
312-427-2400
312-427-4777 Fax
family@speak-easy.com

Orbit Works
Orbit Works is a PC-based collection of tools for earth spacecraft mission design, planning, operations, and analyses. Orbit Works provides tools for spacecraft constellation orbit design, earth coverage and gap statistics, mutual visibility constraints, ground station visibility studies, spacecraft-target pass geometry, graphical display of instrument swaths, and correlation of geo-location and operations. Orbit Works is compatible with LF90.

Ridge Technology
1867 Park Road NW
Washington, DC 20010
202-232-1441
ridgetech@erols.com

Please check www.lahey.com for the latest information on Lahey ISV products. If you are interested in becoming a Lahey ISV or know of a product that should be listed, please contact:

ISV Coordinator
702-831-2500
702-831-8123 Fax
sales@lahey.com

News Briefs
Fortran Workshops
by Karen Colbert

Learning Fortran 90/95 has never been better. Our traveling team of trainers, Joe Chirieleison, Tom Lahey, and Tim Zeisloft will hit the road this fall with a full lineup of Fortran 90/95 Workshops. Workshop sessions are hands-on; you work through porting one of your own FORTRAN 77 programs to Fortran 90/95 using Tom Lahey's porting recipe. The Workshop is a three-day, intensive training program with time to implement new techniques in class and share ideas with fellow participants. The remaining Fall/Winter workshop schedule is as follows:

• November 9-11, 1998 - Reno, Nevada (Joe Chirieleison, Tom Lahey, Tim Zeisloft)
• February 3-5, 1999 - Huntsville, Alabama (Tom Lahey, Tim Zeisloft, Joe Chirieleison)

Fortran Discussions
For current news and e-mail discussions about Fortran, read the comp.lang.fortran news posts or go to www.mailbase.ac.uk/lists-a-e/comp-fortran-90 and subscribe to the comp-fortran-90 mailbase.

IMSL Compatibility
We're still working on it. We're not taking any more orders until we're sure of the release date. We apologize for the delay. When released the LF90/95-compatible IMSL Fortran 90 MP Library will be available for US$625 standalone or as a US$300 add-on if purchased at the same time as LF90 or LF95.

If you don't need IMSL's procedure-name compatibility, try Fujitsu's Scientific Subroutine Library, included with LF95 PRO.

The Lahey

Advantage!
COEX (Corporate Exxpress) is an annual subscription service providing regular updates to LF95 PRO. COEX takes the worry out of software maintenance and ensures you use the latest version of LF95 PRO. COEX subscribers receive updates automatically. No phone calls, e-mail, faxes, purchase orders, or hassles. Each COEX update contains the most current version of LF95 PRO, including any new or updated manuals. The subscription fee of US$300 covers all shipping and handling. Annual renewal is US$249.

LF95 PRO COEX subscription holders receive a 10% discount on all Productivity Tools and Fortran 90/95 Workshops.
Stay up-to-date. Get COEX!

Free Fortran
by Karen Colbert

Nothing is free these days - or is it? To perpetuate the use of Fortran at universities and elsewhere, Lahey has put a free, downloadable version of our educational compiler, Essential Lahey Fortran 90, on our web site.

Essential Lahey Fortran 90 is for students, teachers, scientists, and engineers who want to write programs using the modern features of Fortran 90. Essential Lahey Fortran 90 removes obsolescent Fortran 90 features (arithmetic IF and assigned GO TO, for example). It eliminates clutter such as the optional comma after a DO statement. Essential Lahey Fortran 90 imposes requirements where the Fortran 90 standard grants options (for example, IMPLICIT NONE is required in every program unit). And, Essential Lahey Fortran 90 eliminates storage association (COMMON, EQUIVALENCE, and implicit procedure interfaces). Essential Lahey Fortran 90 programs are easily maintained and run under the full Lahey Fortran 90, Lahey/Fujitsu Fortran 95, or any other compiler that supports the Fortran 90 standard.

Help us spread the word - tell everyone about the free Fortran language system!

Q&A
Here are answers to questions users have asked us over the past six months. Remember to check our FAQ page - your answer might be just a mouse click away!

Q: Are Lahey Fortrans Year 2000-compliant?
A: All Lahey Fortran compilers will function properly in the year 2000 and beyond. The compilers don't use 2-digit years in their internal operation. The Lahey compiler you have today will continue to function properly into the 21st century.

However, Lahey compilers do offer a date subroutine called DATE( ), which returns the current system date in MM/DD/YY format. If you have code that calls DATE( ), and that code assumes that the century is 1900, you may have Year 2000 problems. To help, Lahey Fortran 90 issues a warning that DATE( ) doesn't return a 4-digit year.

Lahey/Fujitsu Fortran 95, Lahey Fortran 90, and Essential Lahey Fortran 90 include the Fortran 95 standard DATE_AND_TIME subroutine. DATE_AND_TIME returns a 4-digit year. We recommend changing all code that uses DATE to use DATE_AND_TIME instead. DATE_AND_TIME is not included with our FORTRAN 77 compiler, EM/32. We recommend that EM/32 owners upgrade to LF95.

Q: Is there any way to reduce the size of Windows executables created by LF90?
A: If your programs have large, uninitialized common blocks, you can shrink the executables by using the following case-sensitive switch on the LF90 command line:

-reclass seg _lc_COMMONBLOCK BSS

lf90 myprog.for -reclass seg _lc_MYCOMMON BSS

program myprog
common /mycommon/ x(1000000)
end

In a future patch, LF90 will automatically place uninitialized common blocks in the BSS segment so you won't have to use this switch. LF95 doesn't have this problem.

Q: When running in ED4W I get the error, "Can't find SAIGPIPE.386 in SYSTEM.INI file."
A: Add the following line to the [386Enh] section of your SYSTEM.INI file:

DEVICE=<path>\SAIGPIPE.386

Q: When calling a Lahey-compiled DLL from a Visual Basic program, I receive a run-time error saying the DLL cannot be found even though the DLL is where it should be. How can I fix this?
A: This VB run-time error can occur when the DLL requires more memory than is available on the computer. Try making more hard disk space available for virtual memory.

Q: How can I pass an array of strings from Visual Basic to Fortran?
A: Due to the differences in the way strings are represented in Visual Basic and Fortran, you cannot pass an array of strings from VB to Fortran via subroutine argument and expect to receive a meaningful result. If passing the data via file is too slow, you may want to consider passing the data via a pipe (a feature of the Windows operating system). See Dan Appleman's Visual Basic 5.0 Programmer's Guide to the Win32 API. (Bookcode vis_basc_w32, 1540 pages, ISBN 1562764462.)

Q: Does LF90 work on Windows 98?
A: Yes. However, there's a bit of a problem with an older version of Lahey ED and long filenames. Lahey ED v3.72, which shipped with LF90 v4.0, supported long filenames under Windows 95 and NT4, but not under Windows 98 and NT5 beta. Lahey ED v3.80, which ships with LF90 v4.5 and LF95 v5.0, supports long filenames under Windows 95, 98, NT4, and NT5.

Q: When compiled with LF95 and the -chk switch, my code runs much more slowly than when compiled with LF90. Why?
A: If you use the -chk on production code you will find the executable runs very slowly. Recompilation without -chk can increase execution speed by a factor of 10