Subject: NA-NET distribution message

From: [email-masked]
Date: Sun, 9 Apr 89 22:47:39 PDT

NA Digest   Sunday, April 9, 1989   Volume 89 : Issue 14

Today's Editor: Cleve Moler

Today's Topics:

     Vectorized Cyclic Reduction Routines
     Registration Fee at Computational ODE Conference
     Formation of Numerical C Extensions Group (NCEG)
     Mini-Conference on Preconditioned Conjugate Gradient Methods
     Wanted: Scientific Images and Image Sequences
     Extended Precision Inner Products on MC168881

-------------------------------------------------------

From: Michael Page <[email-masked]>
Date: Mon, 3 Apr 89 12:43:13 EST
Subject: Vectorized Cyclic Reduction Routines

Vectorised Cyclic Reduction Routines

I am currently moving some fluid dynamics code from a VAX to a Cray X-MP/1
and would like to know of the availability of any public-domain (or cheap)
vectorised code for solving Poisson's equation directly using cyclic reduction. 
Equivalently, I am after a routine to solve a block-triadiagonal matrix of 
the form

a(i)x(i-1,j) + b(i)x(i,j) + c(i)x(i+1,j) 
             + d(j)x(i,j-1) + e(j)x(i,j) + f(j)x(i,j+1) = g(i,j),

which is vectorised for a Cray.  I am aware of the BLKTRI routine, from the
NCAR library, but do not have access to a vectorised version (also, I'm told
there is a bug deep within it which leads to slightly inaccurate results).

Any assistance or suggestions would be appreciated, to save me from reinventing
the wheel.  Please mail responses to 

[email-masked] (or [email-masked] if .AU isn't defined)

but *please* don't send code before checking with me first.

Michael Page
Department of Mathematics, Monash University, Melbourne, Australia.

------------------------------

From: Hans J. Stetter <[email-masked]>
Date: 04 APR 89 16:18:12
Subject: Registration Fee at Computational ODE Conference

    The Conference on Computational Ordinary Differential Equations, Imperial
College, London, 3 - 7 July 1989, has been planned and prepared as the out-
standing event in the area for 1989. A wide and representative attendance is
to be expected.
    Recently, the registration forms for the conference have been sent out;
accordingly, the conference fee for the event is 185 British pounds, i.e.
approximately 320 US dollars or nearly 600 DM. It is true that this includes
refreshments and lunches during the conference; but not everybody will wish
to have a set lunch anyway. For members of the IMA there is a discount, for
late registrants there are fines.
     This registration fee is an order of magnitude above that of previous
Numerical ODE Conferences, it is more than four times the fee charged at this
year's Dundee Conference, and about twice what has been and will be charged at
huge international conferences like ICIAM.
     This fee will seriously limit participation of interested scientists from
Europe; in my department, it will halve the number of people that can attend.
I believe that the NA community should not accept this outrageous fee without
protest as it may set an example for further meetings. ( Note also that the
conference will be held on university premises.)
     I am looking forward to receiving comments and suggestions for proper
action.
     Hans J. Stetter,  [email-masked]

------------------------------

From: Rex Jaeschke <[email-masked]>
Date: 5 Apr 89 03:16:38 GMT
Subject: Formation of Numerical C Extensions Group (NCEG)

Recently, I formed a Numerical C Extensions Group (NCEG) to add extra 
support to the C language and library for numerical applications. 
Quite a few of the major players in this area have agreed to attend 
the first meeting to be hosted by Cray Research on May 10-11.  I
would appreciate any feedback on the proposal below. Thanks. This 
proposal was mailed to all ANSI/ISO C Standard members, about 10 days 
ago.

Please respond via private mail.

Rex Jaeschke

                 Numerical C Extensions Group Formation

Introduction
============

As some of you know, for some time I have had an interest in
standardizing extensions outside of X3J11.  Thus far, my role has
been to convene an extensions meeting one evening during each X3J11
meeting week.  And while each extensions meeting was well attended,
only the two or three regular presenters really participated.

In September, we at X3J11 decided we had done the best job we could
and voted to forward the standard to X3 for final approval.  And
although that has not yet happened, all indications are that it will
without further committee deliberation.  As a result, the X3J11
meetings will be held less regularly and for shorter periods.  That
coupled with the fact that many (most?) of the regular X3J11
attendees have little or no interest in the numerical marketplace at
this time, makes X3J11 an inappropriate forum for efforts to
standardize extensions, at least in the numerical direction.

Certainly, any effort to standardize extensions must be done with
X3J11's stated goal and future directions in mind.  One of the
principle reasons complex and the like are not in the first version
of the standard is the lack of prior art and in some cases, the lack
of consistent prior art.  Only once an extensions group can form
consensus within their own ranks can they reasonably expect a formal
standards body to consider adopting their extensions.

The First Step
==============

As a result of my involvement in X3J11, my writing and teaching
interests, and of my starting The Journal of C Language Translation,
I have formed an extensions group.  The name of that group is ``The
Numerical C Extensions Group'' (NCEG) and its broad purpose will be
to standardize extensions to the preprocessor, language and/or
library as appropriate to sell to and/or satisfy the increasing
interest in C being shown by the numerical community.

Who am I to start such a group?

  -- What I lack in implementation details I make up for in
enthusiasm.  Besides, there are plenty of competent people out there
who can provide the technical details.

  -- I have no commercial interest in the outcome of such extensions and
can therefore, provide some unbiased leadership.

  -- If others are really interested in making it work I have the time
and resources to commit.

  -- I offer the services of The Journal for ongoing publicity of
the groups' decisions and activities.  At the very least, Tom MacDonald of
Cray Research (and The Journal's Numerical Editor) will provide
regular coverage.

  -- If I don't start something will you? (I don't mind sharing the
``glory'' and the work.)

Getting Together
================

We are already at the point where more than a few companies are
interested in the idea of NCEG.  However, unless something formal
happens soon their interest will wane and they will ``do their own
thing'' anyway, or at best, sound off a few ideas with others via
e-mail.

Cray Research has agreed to host an inaugural NCEG meeting at their
Mendota Heights facility in suburban Minneapolis, Minnesota on May
10--11.  That gives you time enough to decide on your level of
participation, if any.  The meeting needs to take place before the
summer break when many of you may be vacationing, plus one or more of
the participating vendors may well be shipping product containing
numerical extensions by the end of the year.  The longer we leave it
to get started the harder the task will be.

Inaugural Meeting Format
========================

I propose a 1 1/2 day format for the following reasons:

  -- It will take quite some time to address administrative issues before
even looking at technical solutions.

  -- Staying overnight gives attendees a chance to get together over
dinner and discuss ideas.  I find that sleeping on decisions made the
previous day can often result in changes and improvements.

  -- Finishing by lunch the second day gives everyone time to catch a
flight out that afternoon.

A reasonable format would be to break the day into four formal
periods, two each in the morning and afternoon.  Have a two hour
lunch to get informal discussions going and to have people meet each
other.

Wed:    9:00  --  10:30   session 1	
       10:45  --  12:15   session 2	
       12:15  --   2:15     LUNCH	
        2:15  --   3:45   session 3	
        4:00  --   5:30   session 4	
                        			
Thu:    9:00  --  10:30   session 1	
       10:45  --  12:15   session 2	

Meeting Agenda
==============

It is clear to me that the thing we don't want to do immediately on
the first day, is to start producing technical specifications.  In
fact, if all we achieve in both days is a consensus of what the
issues really are, and in which corners each company stands, we will
have been wildly successful.

I believe a reasonable plan of attack is to:

  -- Identify any existing prior hardware and software art.

  -- Identify existing and pending formal and de facto standards and
establish a liaison with them.  (X/OPEN, OSF, POSIX, X3J11, GKS, and ISO
immediately come to mind.  Maybe even Fortran 8X.)

  -- Identify and prioritize the technical issues into the following
categories:

      :-- Must have now or as soon as possible.

      :-- Can live without for the time being but eventually need/would like.

      :-- Wishful thinking; ``Gee, wouldn't that be nice stuff''.

  -- Recognize, accept and rationally deal with the problems created when
competing vendors and conflicting commercial interests arise.

  -- Identify, as soon as possible, those areas that such a group cannot,
or chooses not to, standardize.

Meeting Rules
=============

Although I was not involved with X3J11 at the very beginning, I have
attended all but about seven meetings.  (X3J11 votes by majority
rules.) I have also attended three ISO C meetings where voting is by
consensus.  As a result, I propose that we remain as informal as
possible.  In particular, given the specific nature of the task, the
small number of participants and the potential commercial conflicting
interests, I propose working by consensus rather than simple or two
thirds majority vote.  It makes no sense for the group as a whole, to
have one or two vendors be quite opposed to some idea and go do it
their own way anyhow.  If such situations cannot be resolved fairly
quickly, those issues may have to go into the ``unspecified'' or
``implementation-defined'' bin.

Unless someone else wants to arm wrestle me for the role of
convener/chair I am happy to serve in that capacity.  Apart from that
we would need a secretary--perhaps a different person each meeting
so the workload can be spread around.

Beyond the First Meeting
========================

I would expect that by the end of the first meeting we will have
identified most of the ``Must have now or soon'' goals and that we
will each have volunteered to be the focal point for, or to actively
participate in, one or more interest groups.

We will also have exchanged e-mail and postal addresses and phone
numbers so that the ``real'' work can get under way.

It would probably be useful to identify a date and host for the
following meeting.  Of course, meeting frequency can be determined as
necessary and probably no more than two or three times per year. 
Once we get organized it would be desirable to schedule them along
with X3J11 meetings.

Also, we would need a volunteer to do a mailing of minutes, etc., to
all companies we have ``registered'' as intending to participate. 
Meeting attendance must not be necessary for NCEG participation and
so there needs to be a way for proposals, etc., to be circulated in
paper form.

Committee Status
================

As stated earlier, initially NCEG would have no official status. 
However, it is expected that most, if not all, member companies would
also be X3J11 members.  If a useful numeric extensions package can be
agreed upon, it certainly should be submitted to X3J11 and POSIX for
their consideration, however.

Regarding the adoption by a formal standards group--it is quite
possible that even if we don't violate X3J11, they may not adopt any
or all of our proposals simply because the general membership won't
want to be forced to implement things their customer base don't need. 
The only way this might work is if future versions of the standard
are defined as ``Base plus optional packages'' as other language
standards are.

While we certainly don't want to go against established practice, I
see the main role of NCEG as defining a de facto standard.  If we all
agree on the details, our efforts must be successful, by definition. 
Then, if we have done our homework thoroughly, we'll also have the
official (or, perhaps, unofficial) backing of one or more standards
groups.

What Can You Do?
================

  -- Let Tom MacDonald or I know as soon as you can if you are interested
in NCEG.  This is for your benefit as much as ours so we won't come
chasing after you.  If less than 8--10 companies commit to attending the
first meeting THAT MEETING WILL LIKELY NOT BE HELD.

  -- Give me constructive feedback on this whole proposal, even if you
don't intend to participate in the group now or at all.

  -- If you want to participate, identify the people in your organization
who will likely attend and/or provide input.  Even if you cannot attend
the meeting, make your submissions anyway so that I can make sure they get
a hearing.

  -- Identify your company's numerical needs and categorize them into the
three groups named earlier.  Make sure you have a good idea about which
things you are prepared to ``go to the wall on'' and which you are not. 
(Nothing useful will likely result without compromise.)

  -- Offer to become the focal point for a particular topic.  (I'm sure
Tom MacDonald would LOVE to handle complex since that's his top
priority.)

  -- Tell anyone who might be remotely interested in what I am proposing.

Technical Issues
================

I have identified the following possible issues.  (I'm sure there are
many more.) They are in no particular order.

  -- complex

  -- IEEE issues including infinity and not-a-number handling

  -- float.h

  -- need for something like {__NCE__} predefined conformance macro

  -- validation suite

  -- matherr and errno

  -- vector/parallel processing (including array syntax)

  -- aliasing

  -- variably dimensioned arrays

  -- Fortran interface

  -- issues with existing math library

  -- numeric applications libraries

What Happens Next?
==================

I announced the group's existence in the free sample issue of The
Journal which was mailed in Mid-March.  (About 1500 copies were
distributed world-wide.)

We'll schedule the meeting and if your level of commitment is
reasonable, we'll hold it; if it is not, we'll cancel it.  And
depending on our understanding of the problem we'll either reschedule
it or drop the whole idea.

If you want to discuss this proposal or related issues, contact Tom
MacDonald or myself as follows:

Rex Jaeschke, The Journal of C Language Translation, 1810 Michael
Faraday Drive, Suite 101, Reston, VA 22090, (703) 860-0091,
uunet!aussie!jct.

Tom MacDonald, Cray Research, Inc., 1345 Northland Drive, Mendota
Heights, MN 55120, (612) 681-5818, [email-masked], uunet!cray!hall!tam.

Hotel and Meeting Details
=========================

The meeting will be held at Cray's facility located at:

Cray Research
1345 Northland Drive
Mendota Heights, MN 55120

If you wish to provide handouts of technical submissions, etc.,
please bring 30--40 copies since on-site duplication facilities will
be limited.  (At the time of writing, the number of people who have
indicated their interest in attending is at least 15--20.)

Accommodation is available within walking distance at:

Mariott Courtyard
1352 Northland Drive
Mendota Heights, MN 55120
(800) 321-2211
(612) 452-2000

Their standard room rate is $62 per night.  You may get a corporate
rate if you ask.  A block of rooms has NOT been reserved; each of you
must take care of your own reservations.

The hotel has an indoor pool, whirlpool and small exercise room, and
a reasonable restaurant.  Airport limo service is available on demand
from 6:30 AM till 11PM, free of charge.  (The hotel is only 10--15
minutes from the airport.)

If you rent a car at the airport, take 494E to the Pilot Knob exit. 
You can see the hotel from the freeway and you make your way to the
local service road to get to it.

Mendota Heights is about 15 minutes from downtown St.  Paul and 25
minutes from downtown Minneapolis.

Please advise either Tom or I if you plan to attend the meeting so we
can arrange for an appropriate size room and refreshments.

Rex

Rex Jaeschke     | C Users Journal     |  Journal of C Language Translation
(703) 860-0091   | DEC PROFESSIONAL    |1810 Michael Faraday Drive, Suite 101
uunet!aussie!rex | Programmers Journal |     Reston, Virginia 22090, USA

------------------------------

From: Victor Eijkhout <[email-masked]>
Date: Fri, 07 Apr 89 18:30:24 MET
Subject: Mini-Conference on Preconditioned Conjugate Gradient Methods

           MINI CONFERENCE ON PRECONDITIONED
               CONJUGATE GRADIENT METHODS

To celebrate the 13th, the 17th, 31st, and 37th birthdays
of the Preconditioned Conjugate Gradient Method a
miniconference (workshop) will be held at the University of
Nijmegen, the Netherlands, on June 19-21, 1989.

The preconditioned conjugate gradient method has undergone
rapid developments and found wider applications in recent
years. The method has been generalized to nonsymmetric and
indefinite problems, preconditioning methods of optimal
order of computational complexity have been found, new
areas of applications (such as for spectral methods) have
been seen, and the method has been quite successfully
adapted to parallel and vector computers.

The aim of the conference is to report on these and similar
topics and to offer the possibility of discussing the
topics in the presence of many specialists.

The conference will have a number of invited talks, as well
as contributed talks. The deadline for submitting abstracts
(one to two pages) for contributed talks is May 10, 1989.
Notification of acceptance will be given by June 1, 1989.

Each participant to the conference should make his own
hotel reservation. A list of convenient hotels is included
in the information leaflet.

Please indicate your interest in attending or contributing
a paper as soon as possible. The conference fee is f150,
which includes refreshments at coffeebreaks, and conference
proceedings. (The present exchange rate is US$1=f2.13.)

For the organizing committee,
Owe Axelsson.

Organizing committee: O.Axelsson, B.Layton, L.Kolotilina,
V.Eijkhout, J.Maubach, B.Polman.
Honorary member: David M. Young.

                REQUEST FOR INFORMATION

Yes, I am interested in attending the miniconference on
PCG methods. Send me more information.

I do/don't plan to submit an abstract for a contributed
talk.

Name:
Adress:
email:

send to: V. Eijkhout
         [email-masked]

or:      V. Eijkhout
         Faculty of Mathematics and Computer Science
         University of Nijmegen
         Toernooiveld 5,
         NL  6525 ED Nijmegen
         the Netherlands

------------------------------

From: Martin Knapp-Cordes <[email-masked]>
Date: Fri, 7 Apr 89 18:28:32 CDT
Subject: Wanted: Scientific Images and Image Sequences

	Wanted: Scientific Images and Image Sequences

The National Center for Supercomputing Applications and Apple Computer, Inc.
are making preparations to cut a compact disk to be distributed at AUC in
July and at ACM SIGGRAPH '89.  The Apple Science '89 CD will contain the
NCSA Scientific Software Suite for the Macintosh (NCSA Image, NCSA DataScope,
NCSA PalEdit, NCSA Layout).  In addition to these programs, we will include
approximately 300MB of images and animation sequences from researchers
around the world. All images used will be fully credited.

NCSA is seeking examples of images that you have used in your research.

FIRST PRIORITY WILL BE GIVEN TO IMAGES GENERATED FROM SCIENCE AND ENGINEERING
CALCULATIONS AND THE DISPLAY OF SCIENTIFIC DATA. 

Here are the details.

1. TYPE - Raster images and/or numerical data to produce raster images ONLY.

2. BITS OF COLOR/GRAYSCALE - HIGHEST PRIORITY TO 8 BIT. SOME 24 BIT IMAGES
ARE TO BE PUT ON THE CD. However, the NCSA tools cannot deal with 24 bit
images currently. If your 24 bit images can stand it convert them to 8 bit
before submitting. That will increase your chances of getting on the CD.

3. DEADLINE - First priority will be given to those that arrive by April 21
at NCSA. Our absolute production deadline is around May 15.

4. CATEGORIES - you may submit in any or all categories. Please submit only
what you think are your best. Don't send us volumes, because our review
process can't handle it and they may be ignored.

	4.1	single	- standalone image of unusal value.
	4.2	group - sets of images that may be related but not intended
		to be animated.
	4.3	animation - sets of images which are intended to be
		played in sequence for example by NCSA Image.

5. CREDIT - For EACH example in EACH category you submit please include a textfile with the following information. BE AS CONCISE AS POSSIBLE!
 
	Title: (Give some name or title for the image(s) - SHORT!)
	Description: (Describe the science and the content of the image(s).
		   Please include the size and the # bits of color or
		   grayscale.)
	Generation: (Software/hardware used to generate and/or display
		   the image)
	Author(s):(name and address. E-Mail and Telephone numbers are
		   optional)
	Reference(s): (optional list of references)

6. Format - We prefer to deal in one of five formats

	1. raw raster - (8 bit) (bytes in row order, left to right,
			top to bottom). NO HEADERS OR TRAILERS!
			(24 bit) (RGB format) (red bytes in row order, left
			to right, top to bottom, followed by Green, and
			then Blue) NO HEADERS OR TRAILERS!
	2. raw palette - (8 bit) (RGB format - 256 bytes of red, followed
			by Green, and Blue) NO HEADERS OR TRAILERS!
	3. Sun raw raster - Sun users will know about these. 8 or 24 bit.
	4. NCSA HDF - NCSA Hierarchical Data Format - Familiar to some
			NCSA users. People using the current version of
			NCSA Image or NCSA DataScope will know about these.
	5. ASCII data - if numerical data sets for example to use with
			NCSA DataScope supply the data as follows:
			(2-D data sets ONLY!)

	nrows ncols
	max_value min_value
	row1 row2 . . .
	col1 col2 . . .
	data1 data2 . . .
	. . .

		Note:
			1. Only the order is important. Otherwise free
			   format. Arbitrary white space and newlines
			   can separate each floating point number or
			   integer.
			2. Max and min define the range of number values
			   in the range of interest.
			3. row and column values define the values of the
			   two independent variables.
			4. the data or dependent variable is ordered in
			   row order, left to right, top to bottom. 

6. How to send - Use one of the following means.

	1. Mail MAC disk(s)
	2. Mail a UNIX tar formatted 1/4" cartridge or 1/2" real tape (large
	   files or animations)

 	3. ONLY AS A LAST RESORT SEND SMALL FILES (<=.25 MB)
	   VIA E-MAIL. THEY MUST BE in binhex/SuffIt format!

	TO:
		Susan Goode - Science '89 CD Project
		NCSA - Software Development Group
		269 Computing Applications Building
		605 East Springfield Avenue
		Champaign, Illinois  61820

		 [email-masked]

We believe that it is the intent of Apple Computer, Inc. to make available to each successful contributor a free copy of the Apple Science 89' CD.

Best Regards
Martin Knapp-Cordes	[email-masked]	(217) 244-0704

------------------------------

From: Ian Cavers <[email-masked]>
Date: 6 Apr 89 21:01:52 GMT
Subject: Extended Precision Inner Products on MC168881

 Hi.  We want to accumulate inner products in extended precision
on a Sun 3/50 (SunOS 3.2 or 4.0) with a MC68881 coprocessor.  In other words we 
want to take the inner product of two floating point vectors without 
rounding the product of each pair of elements to double precision before adding
it to the sum.  Once the sum of the products has been accumulated in extended
precision it will be rounded to double precision.  I believe that the only
way to ensure such inner products are actually executed entirely in extended
precision is to use assembler language to control the MC68881. (The Sun Fortran 
compiler only supports single and double precision, not extended precision.)

  If anyone can help me with this problem I would appreciate it.  I would like
to avoid the effort of writing an inner product routine in assembler myself 
if I can.

Thanks in advance for any help.

   Ian Cavers   (email: [email-masked])
   UBC Department of Computer Science, Vancouver, B.C., Canada

------------------------------

End of NA Digest
**************************
-------