... templates.¹

Although it is often not thought of as polymorphism, template polymorphism is in many respects more flexible than inheritance polymorphism, one merely requires that an interface have certain features. The disadvantages are code bloat and some loss of semantics enforcement.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... meaningful²

Every package is happy to interoperate with packages which adopt its conventions.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... all³

Or almost all; there are bound to be some things which reside in flat text files, e.g., CLI initialization files

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... addressed.⁴

It would be ideal if the GNU C++ compiler, g++, was sufficiently reliable. Unfortunately that is not yet the case.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... interferometer⁵

More precisely, an earth rotation aperture synthesis array.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... normally⁶

However, one can imagine that for, say, geodesy, the values in a telescope component that describe the displacement of a telescope from a normative position might be the desired result.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... MeasurementSets.⁷

While such concatenations will be physical in the first instance, a Table class which presents a single table interface to multiple underlying tables will be available at some point.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... simulated.⁸

Or partially simulated; a pure east-west array might have a zero column of W's which are returned from a (trivial) virtual column.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... spectra.⁹

It seems likely that these classes will at least have a common base class, and possibly that VisSet will be derived from SpectrumSet.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... process.¹⁰

Incidentally, earlier versions of this scheme had calibration being applied in the data view ( e.g., VisSet). I believe that the requirement that we allow for partially calibrated data requires that calibration results in a MeasurementSet, not a VisSet. In other words, we need to produce calibration chains of indeterminate length -- f (g(h(...(data)))) -- if we want to be able to change and replace functions in the calibration chain, it is required that the domain and range of those functions be the same, i.e., the MeasurementSet.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... clarification.¹¹

However this is not a large point; we merely have to decide what values we want the TelescopeModel to have and export them -- normally it would fill its internal tables from the MeasurementSet.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... row¹²

For these purposes, all indirect arrays and tables are identical; think of them as pointers. This rule ensures that all rows have the same size.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... row.¹³

Actually the dimensionality may be fixed in the table description if desired.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... added.¹⁴

A description can also be incompletely specified, for example:

• A column named ``Data'' containing complex arrays must exist;
• A column named ``Data'' containing 1-D complex arrays must exist;
• A column named ``Data'' containing 1-D complex arrays of length 512 must exist.

In practice, the second (or possibly first) alternative would be likely be the right level of detail. One wouldn't want to forbid the number of channels of the detector from changing, on the other hand the user of the table shouldn't have to engage in a lot of run-time detection of the table structure.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... table.¹⁵

Presently iterator tables are actually implemented with reference tables.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... disk¹⁶

In principle storage managers could be written for tape drives or other devices.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... Karma¹⁷

Karma is a programmers toolkit for scientific computing with communications support, event management, data structure manipulation, graphics display and user interface support. Information on Karma may be found at http://www.atnf.csiro.au/karma. Karma was developed by R. Gooch.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... requirements.¹⁸

For example, it is expensive to change a value in the middle of a Miriad-like dataset, however it is quite cheap to extend it. On the other hand, a Karma data set cannot be extended at all once it is created (short of a copy).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... it¹⁹

Actually element iterators like these are of wider utility than for only traversing lattice regions; they are of wide utility for containers in general. In C++, the best example of this is the ``Standard Template Library'' (STL) which is being adopted by the ISO/ANSI C++ standardization committee. The AIPS++ element iterators should be STL compatible to enable their use with third party libraries and functions.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... mask.²⁰

Actually, the mask is an implementation detail. The same result could be had by storing a list of valid (or invalid) positions. However, the use of a mask results in a more predictable cost. Our implementation of a MaskedLattice contains two lattices: one for the data and the other for the mask.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... indexing.²¹

In C++, we should probably also make a distinction between arithmetic arrays and general arrays. We might also want array classes that, for example, wrap around Karma library arrays.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... rule²²

First formulated by Mark Calabretta.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... languages²³

APL, IDL, Mathematica, Fortran 90, S+ etc.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... data.²⁴

Actually, it is possible to get reasonable performance without tiling if you assume that you can hold an entire XZ slice of the cube (in this example) in memory at once.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... process²⁵

Almost certainly a thin layer on top of a WWW browser like Mosaic.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... hub.²⁶

Perhaps ``sender blocks until reception would be a better policy?''

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... values²⁷

Writing the values contained in an object out in some way that its values can be reconstituted into a similar object. This is essentially ``copy'' semantics: some object is overwritten with values that came out of some previous object. (AipsIO behaves like this.) persist >> object is a reasonable way to think of this.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... objects²⁸

A PARTICULAR object whose lifetime can exceed that of the process in which it was created. persist >> object is a bad way to think of this, you are not changing some (possibly empty) existing object, you are ``activating'' an already existing object.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... data²⁹

If the class is designed properly.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... whole-array³⁰

Glish originally only had 1-D arrays; it has recently been augmented to handle multidimensional arrays by Darrell Schiebel of the NRAO AIPS++ group.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... distribution.³¹

Available via anonymous ftp from ee.lbl.gov in the glish subdirectory. The principal author of Glish is Vern Paxson ( vern@ee.lbl.gov).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... editing³²

Also recently added by the AIPS++ group.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.