Re: [Numpy-discussion] .max() and zero length arrays
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. 'as ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] .max() and zero length arrays
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 (and we shouldn't use +/-inf for integer arrays, either). 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. Besides, being able to specify what value to use to start the reduction is a generally useful feature regardless. There have been several times in the past week, even, when I wished we had that capability. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] .max() and zero length arrays
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
Re: [Numpy-discussion] .max() and zero length arrays
Alexander Schmolck wrote:
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.
The floating point case should also throw an error if the integer case does.
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.
Correct, they won't. It also doesn't matter that they won't. It does for min()
and max(), though.
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.
It is a largely orthogonal issue; however, it also happens to solve the issue at
hand without introducing other weirdness.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth.
-- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
