Konrad Hinsen writes:
"Perry Greenfield" <perry@stsci.edu> writes:
Questions:
1) given 2, is there still a desire for .reduce() to return rank-0 arrays (if not, we have .areduce() which is intented to return arrays always).
2) whichever is the "returns arrays always" reduce method, should the endpoint be rank-0 arrays or rank-1 len-1 arrays?
I don't really see an application where a reduction operation yielding rank-1 or higher arrays would be useful. It would be a special case, not useful for generic programming. So my answer to 2) is rank-0.
What I am wondering is what behavior suits "generic" programming more. Eric Jones and Paul Dubois have given examples where having to deal with entities that may be scalars or arrays is a pain. But, having said that, the behavior that Eric wanted was not consistent with what many thought rank-0 arrays should have (i.e., len(rank-0)=1, rank-0[0] = value). The proposal to generate rank-1 len-1 arrays was made since len() of these arrays is = 1, and indexing with [0] does work. So for the kinds of examples he gave, rank-1 len-1 arrays appear to allow for more generic code. But I'm not trying to speak for everyone; that's why I'm asking for opinions. Do you have examples where you find rank-0 arrays make for more generic code in your cases when len() and indexing on these does not have the behavior Eric wanted? May I see a couple?
As for 1), if indexing doesn't return rank-0 arrays, then standard reduction shouldn't either. We would then have a system in which rank-0 arrays are "expert only" stuff, most users would never see them, and they could safely be ignored in tutorials.
That's my inclination, but I think that the question of whether there should be some reduce mechanism that returns arrays always is still a valid one. I can see that there are good uses for that (or at least a function to cast a scalar to a rank-1 len-1 array if it isn't already an array, like what array() does except that it now generates rank-0 arrays). Perry