P.S. Why not just ignore Slice and use Slab you ask? One reason is: 2D operations on a 3D volume. For example, Reduce won't let you reduce in some dimensions but not others (e.g. X&Y, but not Z). Slice(all)->Reduce->Stack does the job efficiently, except that origin and deltas are corrupted by Slice. And you can't use Slab instead in this pipeline as Stack insists on increasing the dimensionality.
Hmm, I thought Reduce did vector (dimensional) reduction if you fed it a vector, but made a multigrid of scalar (same in all dimensions) reductions if you fed it a list.
I know I haven't used Slice for ages in preference to using Slab; including making a Slab of 0 thickness when I wanted a "slice" but still retaining the original dimensionality. Losing the dimension was usually more bother than it was worth.
Also, I expect you are aware that there is no definite connection between dimension 0 and dimension X and so on in DX-speak. Dimension 0 is the slowest changing, but if you've transposed, that dimension might not plot along the X-axis.
I have pondered your questions and don't have an answer re the Slice "bug". It could be a bug or it could be the best possible solution when the deltas are presented, like yours, in the "wrong" order. In effect, it seems to me you are transposing X and Y and DX is getting confused while untangling them. The bug may be simply that the routine looks in the wrong place for the "0" origin and count after determining that the "1" dimension must be "X" due to the delta being non-zero in the first component and 0 in the second (though why that should matter is not clear). Your proposed solution may be better, but I think it should become Slice2 module until we've tested it on a number of different cases that are less "degenerate" (:-) (no personal aspersions intended of course).
With any luck the person who wrote Slice will pipe up...? Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED]
