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

Re: ncvarget and array reordering (fwd)

>From: address@hidden (Ethan Alpert)
>Organization: NCAR/SCD
>Keywords: 199406281640.AA10426 ncvarget

Ethan,

>I posted this to netgroup and didn't get any response.
>
>Do you all at unidata have any comments?

Our reigning expert on things like this, Russ Rew, is out of the office
until July 5.  I am forwarding this note to him so he can respond when
he gets back.

>-ethan
>
>> 
>> 
>> 
>> Hello,
>> 
>>      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 documenta
> tion
>> this constraint is stated. You'd think the function interface would tell you
>> by using the "const unsigned long" type declaration in the function prototyp
> e 
>> rather than "const long".
>>  
>> The whole idea here is, if negative edge lengths were allowed, then user
>> defined reorderings of data durring 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 relative
> ly
>> 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 thi
> s
>> functionality as well.
>> 
>> Is this some kind of XDR constraint that creeps up to the user interface lev
> el?
>> 
>> Thanks in advance for any info,
>> 
>> -ethan
>> 
>> ----------------------------------------------------------------------------
> ----
>> 
>> Example in case my description of the problem isn't good enough:
>> 
>> For example consider the following 3x3x3 array and indices: 
>> 
>> A start array of { 0, 0, 0 } and a count of { 2, 2, 2 } produces:
>> 
>> (0,0,0) 1
>> (0,0,1) 2
>> (0,0,2) 3
>> (0,1,0) 4
>> (0,1,1) 5
>> (0,1,2) 6
>> (0,2,0) 7
>> (0,2,1) 8
>> (0,2,2) 9
>> (1,0,0) 10
>> (1,0,1) 11
>> (1,0,2) 12
>> (1,1,0) 13
>> (1,1,1) 14
>> (1,1,2) 15
>> (1,2,0) 16
>> (1,2,1) 17
>> (1,2,2) 18
>> (2,0,0) 19
>> (2,0,1) 20
>> (2,0,2) 21
>> (2,1,0) 22
>> (2,1,1) 23
>> (2,1,2) 24
>> (2,2,0) 25
>> (2,2,1) 26
>> (2,2,2) 27
>> 
>> 
>> Note how the negative edge length affects the layout of the values in contig
> uous
>> memory:
>> 
>> A start array of { 0, 0, 2 } and a count of { 2, 2, -2 } would produce:
>> 
>> (0,0,0) 3
>> (0,0,1) 2
>> (0,0,2) 1
>> (0,1,0) 6
>> (0,1,1) 5
>> (0,1,2) 4
>> (0,2,0) 9
>> (0,2,1) 8
>> (0,2,2) 7
>> (1,0,0) 12
>> (1,0,1) 11
>> (1,0,2) 10
>> (1,1,0) 15
>> (1,1,1) 14
>> (1,1,2) 13
>> (1,2,0) 18
>> (1,2,1) 17
>> (1,2,2) 16
>> (2,0,0) 21
>> (2,0,1) 20
>> (2,0,2) 19
>> (2,1,0) 24
>> (2,1,1) 23
>> (2,1,2) 22
>> (2,2,0) 27
>> (2,2,1) 26
>> (2,2,2) 25
>> 
>> 
>> A start array of { 2, 2, 2 } and a count of { -2, -2, -2 } would produce:
>> 
>> (0,0,0) 27
>> (0,0,1) 26
>> (0,0,2) 25
>> (0,1,0) 24
>> (0,1,1) 23
>> (0,1,2) 22
>> (0,2,0) 21
>> (0,2,1) 20
>> (0,2,2) 19
>> (1,0,0) 18
>> (1,0,1) 17
>> (1,0,2) 16
>> (1,1,0) 15
>> (1,1,1) 14
>> (1,1,2) 13
>> (1,2,0) 12
>> (1,2,1) 11
>> (1,2,2) 10
>> (2,0,0) 9
>> (2,0,1) 8
>> (2,0,2) 7
>> (2,1,0) 6
>> (2,1,1) 5
>> (2,1,2) 4
>> (2,2,0) 3
>> (2,2,1) 2
>> (2,2,2) 1
>> 
>> 
>> 
>> 
>> 
>> 
>
>

Tom Yoksas