[Numpy-discussion] ufunc oddities

Charles R Harris charlesr.harris@gmail....
Sat May 24 22:02:59 CDT 2008

On Sat, May 24, 2008 at 8:59 PM, Robert Kern <robert.kern@gmail.com> wrote:

> On Sat, May 24, 2008 at 9:45 PM, Charles R Harris
> <charlesr.harris@gmail.com> wrote:
> >> I'm not sure why you're showing me numpy C code. I am talking about
> >> the Python bools True and False.
> >
> > Because I'm talking about ufuncs. The original question was about ufuncs
> > and, since array booleans are not treated as numbers for ordinary
> > arithmetic, the question was when *do* we treat them as numbers. I'm a
> > bugger for consistency and booleans aren't consistent.
> And I brought up the Python bools because there is a relationship that
> numpy has with the rest of Python's types that we need to keep in
> mind.
> I think it boils down to this: when we have places where bools are
> operated with bools and expect to output bools, we can decide what the
> rules are. For the arithmetic operations +-*, there are reasonable
> Boolean logic interpretations that we can apply.
> When upcasting is requested, either implicitly or explicitly, they
> turn into 1s and 0s. All of the behaviors you think are inconsistent
> just arise from the consistent application of that simple rule. Since
> it *is* sometimes useful to treat booleans as numerical 1s and 0s, I
> think it would be a mistake to prevent it. Sure, it doesn't really
> make sense to do sin(True), but if you want to preserve the useful
> behaviors, you will just end up with a big list of special cases and
> make behavior difficult to reason about.

So what about the rule that the array type takes precedence over the scalar
type? That is broken for booleans.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080524/7b1d25dc/attachment.html 

More information about the Numpy-discussion mailing list