From tody Wed Apr 20 18:50:45 1983
Date: 20 Apr 1983 18:50-MST
To: vesa
Subject: ii comments
Cc: tody

I read through "tnotes1", and felt that enough information was conveyed
to explain how the asi___ routines work, and how to use them.  It is
good documentation for the package, though some sections are probably
to technical for the general user, and should probably be moved to an
appendix in the final documentation.

I only have one minor suggestion, and that is that there seems little
reason to abbreviate NEAR, REFL, and PROJ, since only three characters
are saved in each case, and the other parameter names are all spelled out.

I also looked at the code for ASIFIT.  I noticed that the recursion
relations for the cubic spline are coded inline.  I suspect that this
is actually LESS efficient than using a separate procedure, due to
the complex coeff offset expressions appearing in the inner loops
(unless the Fortran compiler does a very good job of optimizing loops).

By using a separate procedure, for example, the statement

	coeff[COFF+i] = coeff[off2+i] * (coeff[COFF+i] - coeff[COFF+i-1])

can be converted to something like

	bcoeff[i] = acoeff[i] * (bcoeff[i] - bcoeff[i-1])

where in the main routine, there is a procedure call something like the
following:

	call fit_bspline3 (coeff[COFF], coeff[off2], ...)

In other words, the routines that actually do the work do not need to
know that everything is saved in a single coeff array.  This simplifies
the code, as well as making it run faster on some machines.  The technique
has an additional advantage: by isolating the compute bound code into
a separate (small) procedure, it becomes easy to hand optimize that procedure
in assembler, should we wish to do so.

From tody Wed Apr 20 19:48:51 1983
Date: 20 Apr 1983 19:48-MST
To: vesa
Subject: first benchmarks
Cc: tody

I ran some preliminary benchmarks on the asi code, assuming no bad pixels.
The benchmark routine is in math/interp.  Results:

512 by 512 image interpolation, no bad pixels, using ASIEVA:

	nearest		47 (cpu seconds)
	linear		22
	poly3		50
	poly5		89
	spline3		94

This is quite encouraging.  I expect that these timings can be decreased by
a factor of from 3 to 5, given a good Fortran compiler (the current UNIX
compiler is very poor), and possibly hand optimising critical sections of
the code in assembler.

The nearest neighbor timings don't make any sense (that should be the
fastest interpolant).  Are you using sqrt, or something like that?
The spline timings are worse than I expected, compared to poly3.  May
be due to complex offset expressions, which F77 does not optimize.

From tody Fri Feb 18 14:10:36 1983
To: vesa
Subject: x code
Cc: tody


We want to make IRAF source code as readable as possible, therefore there
is a (currently unofficial) standard for ".x" code.  Your code is pretty
close to the standard, but here are some things to consider:

    (1)	It is preferable to enclose large blocks of documentation in
	.help .. .endhelp sections, rather than making each line a comment.
	This has two advantages: (1) it is awkward to edit text set off with
	a # on each line, and (2) the help utilities can only extract
	source code documentation which is set in help blocks.  It is not
	necessary to use text formatter commands in help blocks, i.e.,
	you can simply type it in as it will appear on the terminal.

	In the same vein, it is better to put the discussion of the input
	and output parameters in the help text, rather than in the
	declarations section of the procedure.  Placing each input and
	output parameter on a single line, followed at the right by a short
	comment, gets the job done without cluttering up the declarations
	section.  More extensive comments should be placed in the help text.


    (2)	It is mostly up to the programmer to decide where to put whitespace
	to make the structure of a program clearest.  Whitespace should
	be inserted in a statement to make the important logical components
	of the statement stand out.

	In particular, there should be a space after every keyword, before
	the left parenthesis.  If the statement is compound, the left brace
	should be set off from the right paren by a space.  In short
	expressions, operators should be set off by whitespace.

	Adding whitespace between a function name and the left paren is
	optional, as is whitespace between the elements of an argument list
	(after commas).

	Blank lines should be used to set off sections of code, just as
	blank lines are used to separate paragraphs of text.

	It is possible to overcomment code, making it hard to read.  If
	more than a third of the lines in a procedure are comments, the
	code is probably overcommented.  Place detailed discussion of the
	algorithm in the help text.


    (3)	Indenting structures by full tab stops is acceptable, but 4 space
	indents are preferred (the code rapidly runs off the right side of
	the screen if full tab indents are used, encouraging use of too
	short identifiers and omission of whitespace).  The autoindent
	feature of VI makes this easy (in .login file: 'set ai sw=4').


    (4)	The standard form of the if .. else construct is
	
		if (expr) {
		    stmt
		} else {
		    stmt

	or (if "stmt" is several lines, and whitespace is desired)
		
		if (expr) {
		    stmt

		} else {
		    stmt
		
	rather than

		if (expr) {
		    stmt
		}
		else {
		    stmt

From tody Fri Feb 18 15:21:33 1983
Date: 18 Feb 1983 15:21-MST
To: vesa
Subject: spec changes
Cc: tody


Now that Garth, Harvey, Steve and others have had a chance to comment on the
specs for the interpolator routines, it is time to make the final revisions
to the specifications.  Often ones perspective on a problem changes when one
actually begins coding, and even the most carefully prepared specifications
need to be changed.  Please feel free to suggest further changes.


Modifications

    (1) Everyone wanted the interpolators to be able to generate estimated
	values to replace indefinites (as an option).

    (2)	Steve wanted sinc function interpolation added to the set of 
	interpolators.  I would also like to try this for undersampled
	CCD data.  A fairly high "order" (basis function size) seems
	justified for this interpolant.

    (3)	A surface integration routine is desired (MSIGRL).


SET Routines

    I think we should generalize the form of the "set" routines to permit
options such as (1), and others we may wish to add in the future (such
as telling the interpolator not to check for indefinites in the data).

Set routines are also used in the FIO, IMIO, VSIO, and GIO packages in
the program interface.  For example, in FIO, the number of buffers for a
file could be set by a call of the form

	call fset (fd, NBUFFERS, 2)

The form of a set call is therefore

	call ___set (object, parameter, value)

i.e.,

	call asiset (coeff, II_INTERPOLANT, II_DIVDIF3)
	call asiset (coeff, II_TYBNDRY, II_NEAREST)
	call asiset (coeff, II_REPLACE_INDEFS, YES)

Note that the prefix "II_" must be added to all Image Interpolation
defined parameters and parameter values.  This is unattractive, but necessary
to avoid redefinitions of identifiers in other packages, such as IMIO (IMIO
has the same boundary extension options as II).


Surface Integration

    I suggest the following calling sequence for the surface integration
routine:

	integral = msigrl (x, y, npts, coeff)

where the surface to be integrated is defined by the closed curve {x[i],y[i]},
where 1 <= i <= npts, defined by the caller.