[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ncvarget and array reordering

> Organization: NCAR/SCD
> Keywords: 199406162101.AA20031

Hi Ethan,

>       I was wondering if anyone ever tried passing negative edge lengths
> to the ncvargetg function. First off, I know this doesn't work because I
> get an "invalid edge length" error. But, I can't find where in the 2.3
> documentation this constraint is stated. You'd think the function
> interface would tell you by using the "const unsigned long" type
> declaration in the function prototype rather than "const long".

I couldn't find this constraint in the documentation either.  Evidently we
either need to specify that edge lengths must be nonnegative in the
documentation, or add the code to support negative edge lengths.  

When the netCDF interface was defined, I was against using the unsigned
qualifier for integer types just to indicate that non-negative values were
required, because I'd been told that using "unsigned" could cause serious
performance degradations on some platforms that don't support unsigned
operations in hardware.  Today I would probably use a typedef for "unsigned
long", but that would be a change to the interface and it's much too late
for such a change now.

> The whole idea here is, if negative edge lengths were allowed, then user
> defined reorderings of data during reads and writes would be possible.
> Saving both programing time and CPU time.
> 
> Does anybody know why NetCDF doesn't let you set negative edge lengths?
> It sure does seem like it would be a pain to have to read in an entire
> block and figure out how to reorder it when it could have been done
> relatively easily when reading the data in the first place, not to mention
> the extra CPU time.
> 
> Does anybody even care about this kind of functionality? It would seem
> like the people who wanted strides and index maps would possibly benefit
> from this functionality as well.
> 
> Is this some kind of XDR constraint that creeps up to the user interface
> level?

I'll put this on our list of things to look at before the next release.
However there are some problems I can already anticipate in permitting
negative edge lengths.  Much netCDF code that is out there already uses the
product of the elements of the count array to determine how much memory to
allocate for the result of a read, and allowing negative edge lengths means
all that code would have to be changed to instead use the absolute value of
that product.

Also, the MATLAB netCDF interface has adopted the convention that using "-1"
for an edge length means it defaults to the actual edge length.  Permitting
negative edge lengths would clash with this convention and an unknown amount
of existing MATLAB code.

Finally, if negative edge lengths are permitted for the generalized
hyperslab interfaces, it seems to me that they should be permitted for the
old hyperslab interfaces as well.  With our library code already optimized
for reading forwards in a netCDF file by exploiting read-ahead semantics, I
know that the code changes to support what would amount to reading values
backwards from the order they appear in the file would be extensive.  What
you are asking for is similar to asking for an extension to the stdio
library to interpret negative sizes as meaning to supply the values in
reverse order.  I know of no stdio implementation that allows this.

--
Russ Rew                                                   UCAR Unidata Program
address@hidden                                             P.O. Box 3000
http://www.unidata.ucar.edu/                             Boulder, CO 80307-3000