Robert Kern <[EMAIL PROTECTED]> writes:
> Alexander Schmolck wrote:
>> Robert Kern <[EMAIL PROTECTED]> writes:
>>
>>> If possible, I would prefer a way to pass a value to use and raise the
>>> error if
>>> no such value is passed rather than hardcode an identity value for min()
>>> and max().
>>
>> What's wrong with inf? I'm not sure integer reductions should have
>> max/min-ints as identity values (because this could lead to nasty bugs when
>> implicit dtype promotions are involved), but I can't see any problems
>> resulting from +/-inf.
>
> 0 and 1 exist in both integer and floating point versions. +/-inf don't. A
> hardcoded identity value should be consistent across all uses, not changing
> depending on the type .
I don't see why the integer case can't just throw an error, because I don't
see how this could cause much trouble. OTOH I have no difficulty thinking of
current 'special' integer-behavior that I find quite problematic, e.g.
seterr('ignore'); divide(1,0) == 0 # no error, no warning[1]
> (and we shouldn't use +/-inf for integer arrays, either)
Agreed.
> There are also times when I have constraints on the domain of the inputs. For
> example, I might be dealing with arrays that should only have positive
> numbers.
> If I call max() on the arrays, I might want the result for the empty one to be
> 0, not -inf.
I don't find this argument convincing -- add.reduce won't care that your
numbers are all positive and add.multiply won't care if they're all negative.
> Besides, being able to specify what value to use to start the reduction is a
> generally useful feature regardless.
Yes, I agree that this it should be possible to pass a seed value, but that is
to my mind largely an orthogonal issue.
Whilst we're discussing reduction wish-lists, I think it would also be useful
to have a flag to specify that a reduction should be rank-preserving (i.e. use
unit dimensions over the reduced axis) because that works synergisticly
together with broadcasting (e.g.
X - mean(X, axis=n, samerank=1)
).
> There have been several times in the past week, even, when I wished we had
> that capability.
'as
Footnotes:
[1] Maybe the result of overhomogenizing? IMO the logic that applies to
floating point numerics just doesn't apply to integer numerics -- dividing
by a number you know to be exactly 0 is always an error, period.
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
