Sounds like +/b should not be much of a problem. What about the other primitives? It seems that the primary consideration is that the speed can not be much, if any, slower than byte booleans to be practical.
Self-Classify (=) - A shoe in. Conversion from bit to other numeric types - Probably about the same speed as now. Creating booleans from comparisons - The packing might require additional code, but should be about the same speed as now. How could this relate to Copy? (see next) Copy (#) - Probably about the same speed as now; however, it is used a lot so it can't be slower. Append (,) - A bit slower for small arrays but should be considerably faster for large arrays. Grades and sorts (/:) (\:) - Monadic may be difficult as the indices have to be built. Dyadic? Prefix and Infix (\) - Not pretty. +\/b would probably have to be converted to numeric first. Any others? On Tue, Sep 7, 2010 at 1:47 AM, Robert P. Rumble <[email protected]>wrote: > At 08:29 PM 9/6/2010, you wrote: > >Bytes are directly addressable in the most popular CPUs; > >bits are not. > > > >However, with an additional 20 years of C programming under > >my belt, I am now confident enough to tackle bit booleans, > >if I should become interested enough. Bit booleans offer > >lots of room for lots of juicy tricky clever code. For example, > >how do you compute +/b where b is a bit-boolean vector? > > This may have already been done for you in hardware. > > See opcode called popcount or popcnt, aka "the NSA instruction" for > x86 architectures. > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
