This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> 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