>>As far as working with heterogeneous data-types is concerned, we're
>>working on a prototype C++ implementation that will support polymorphic
>>arithmetic (using a technique call "double polymorphism").
>
>I convert from any type to type double using my procedure 'from_nc_type' & do
>reverse using 'to_nc_type'. These are in nc.h, which together with other source
>code mentioned below, is accessible by anonymous ftp to atmos.dar.csiro.au
>followed by "cd netcdf/hld"
Good solution -- given a particular set of criteria. I'm not sure I'd
want to implement a 3-D convolution operator this way -- but for small
datasets, at least, it has much to recommend it.
>- ncgen - extended to allow insertion & modification of existing file
>- ncdump - extended to allow specification of variables, etc
>- ncrename - much as proposed
>- ncdelete - delete attributes (& variables if possible)
>- nccopy - copy data from one file:variable to another
Both ncdelete(1) and nccopy(1) can be implemented in terms of
ncextract(1), which is about to be released.
>In my previous posting I proposed a syntax for specifying an 'array' defined
>by netcdf filename, variable name & a vector of subscripts for each dimension.
>I want to argue that given such a flexible way of specifying source &
>destination, only a small number (such as the 5 or 7 above) would be needed.
>For example, one copy utility (say nccopy) would do the essence of the tasks
>of the eleven proposed programs ncextr, nccut, ncthin, ncappend, nccat,
>ncmerge, ncpaste, ncjoin, ncorder, ncunpack, ncpack
This is nice and elegant solution. Unfortunately, it has the drawback
of requiring that a layer be created which is capable of interpreting
such netCDF specifications in the manner you suggest. This would mean
that no netCDF operators could be released until the interpreter was
fully completed (or as near enough as makes no difference). This is in
contrast to the current proposal of implementing stand-alone netCDF
programs and releasing them as they are completed.
Personally, I'd be more than happy to work on such a netCDF
specification interpreter (I've thought about one for some time). I
think it makes sense, especially as the first step towards a potential
`netCDF data-server' and as an interface for converting between how
data exists in a netCDF object and what an individual program wants to
see. I think, however, that it will take some hewing and crying from
the netCDF user-community to convince the powers that be that they
should set these wheels in motion. Note that the preceding is just my
opinion and not necessarily the UPC's (which I don't think has an
opinion on this).
>I do not claim to fully understand the current proposals or that my proposals
>have been fully thought through. I just want to stimulate some lateral
>thinking before things are set in concrete.
For what it's worth, you have my support (to stimulate at the very least ;-).
--Steve
