result types of bool matrix operations

[JeffBezanson]

Gunnar's issues 5 and 6:

5. Complex booleans seem somewhat brittle.

julia> true * true
true

julia> true * complex(true)
true + falseim

julia> complex(true) * complex(true)
1 + 0im

6. Boolean matrix arithmetic is unpredictable.

julia> [true,true]' == [true true]
true

julia> [true,true]' * [true,true]
1-element Int64 Array:
 2

julia> [true true] * [true,true]
1-element Bool Array:
 true

julia> ([true,true] .== true)' * [true,true]
1-element BitArray:
 true

We have true+true === 2 but true*true === true. Maybe it's best just to give an Int for all bool arithmetic.

Then there is a further problem, that functions like dot and matrix * use the input type to determine the output type, but for Bool this is wrong. One thing that works is

resulttype(T::Type) = typeof(zero(T)*zero(T)+zero(T))

to be pedantic.

[stevengj]

Regarding arithmetic, I can see three options.

1. All arithmetic operations (except bitwise operations) promote Bool to Int, (i.e. true*true == 1).
2. Arithmetic operations on Boolean values are defined by interpreting the value as an integer modulo 2 (i.e. true + true == false etc.).
3. The C-ish style in which we to do the arithmetic as Int but convert the result back to Bool (via != 0), i.e. true+true=true, true*true=true etcetera.

[StefanKarpinski]

I think that the following makes the most sense to me:

1. Arithmetic operations on Bools promote to Ints: true+true => 2, false+false=>0 etc.
2. Bitwise operations on Bools produce bools: true & true => true.

Currently, arrays of bools are the only ones for which vectorized arrays don't preserve the size and type of their operands, which is a bit inconsistent, but probably much more useful than the alternative of doing Int arithmetic and then casting back to Bool – if you want that, you can always express it more clearly using bitwise operators.

Side issue: can we replace im = ImaginaryUnit() with the complex(false,true)? That would be a nice way to simplify the complex hierarchy now that Complex is memory-compatible with C99 complex numbers.

[JeffBezanson]

Agree on the arithmetic, since it's what we do for all other integer types.

It'd be nice to get rid of ImaginaryUnit, but it does have useful special behavior:

julia> Inf*im
complex(0.0,Inf)

julia> Inf*complex(false,true)
NaN + Inf*im

I don't yet see a way around this.

[StefanKarpinski]

One option would be to introduce pure imaginary numbers, Imaginary{T<:Real} and then let im = imaginary(true) which would be an element of Imaginary{Bool}. That could sanely have the Inf*im => complex(0.0,Inf) behavior and would be more generally useful for allowing the compact representation of purely imaginary values and array.

[StefanKarpinski]

Of course, that proposal doesn't actually simplify the type hierarchy, but it does generalize it to be more useful.

[GunnarFarneback]

Amusingly my suggestion to have false * x = zero(typeof(x)) and true * x = x is a perfect fit with the desire to have Inf * complex(false, true) = complex(0.0, Inf).

[JeffBezanson]

I did notice that, and it does make me stop and think. But my current impression is that it's mostly a coincidence.

[StefanKarpinski]

Thanks, Jeff. I think the right approach for supporting things like matmul in GF(2) is to make a new type whose addition and multiplication are appropriate to that field.