# Why doesn't Mathematica pack Boolean arrays?

I've been wondering about this for a while now, so I'm going to ask. This is a question about the design of Mathematica, which perhaps cannot be directly answered by anyone but the designers, however similar queries have been fruitful in the past.

Simply: why aren't arrays of True and False values packed? Compile handles True | False so it seems Mathematica has some understanding of optimizing for this type, yet:

boolean = DeveloperToPackedArray @ RandomChoice[{True, False}, 1*^6];

DeveloperPackedArrayQ @ boolean


False

This is rather frustrating because packing would be particularly effective on binary data:

bigint = FromDigits[Boole@boolean, 2];

ByteCount[boolean]

ByteCount[bigint]


8000032

125040

Yes, one can sometimes fall back to this storage format and use Bit* operations, but that is inconvenient and it doesn't always help; data must be converted for functions that expect True or False and the opportunity for internal optimizations may be lost.

Is there some reason I fail to comprehend that makes implementing packing of Boolean arrays a bad idea?

-
I thought that packing optimized speed and not memory. Packing boolean arrays would reduce memory consumption but would probably increase access time. –  Sjoerd C. de Vries Aug 24 '12 at 21:54
@SjoerdC.deVries Packing hugely optimizes memory as well. Whenever it can be used, it wins both performance - wise and memory - wise, there is no tradeoff. –  Leonid Shifrin Aug 24 '12 at 22:04

As I suggested in my answer to a related packed-array question, the main problem is IMO not in the data structure (packed array) per se, but in all the functions which must work with this data structure together and in concert, to make it really well-integrated into the language. Notice that there isn't a separate boolean atomic type in Mathematica, True and False are just special symbols. I suspect that one would need to introduce an atomic Boolean head, and perform a re-design and enhancements to a whole lot of core functions, to make boolean packed arrays really work.
Besides being a fundamental design choice (change of an existing design), this is a lot of work and a lot of places where bugs may be introduced. This has to be weighted against the benefits of having separate boolean type. While I can see some such benefits, I don't think the outweigh the associated difficulties, some of which I just listed. Anyone who needs efficient boolean arrays can use integer arrays of 0-s and
1-s consistently in their functions. My two cents, as usual.