Re: Bit ops on boolean arrays?

["David J. Slate" <dslate@...>]

I agree with Steve D. that modifying Lua internals would not be
justified in this case unless there were sufficient demand, which is
quite unlikely (I don't really have use for this feature myself). It
was more a thought that if one is going to do bit ops, my suggestion
is cleaner than bit32. I've always thought that bit ops on integers
are really a low-level implementation of what should be higher-level
concepts, such as the set operations I mentioned. Note that the Pascal
language (not that I would recommend that to anyone!) had a setof type
constructor, which was one of the language's more interesting
features, together with a set of operations that went with it.

Yes, I can imagine the "blood spilled" over the bit ops decision. A
feeling of unease about this feature is partly what inspired my post,
as well as being reminded of my past chess programming days, when I
had to resort to evil tricks to persuade ancient Control Data and Cray
Fortran compilers to perform bit-wise operations on phoney floating
point numbers in order to implement efficient bit boards.

Eduardo Ochs's idea about using strings to represent arbitrary bit
sequences (and hence boolean arrays) sounds quite plausible, and
better than having to invent another "userdata".

Speaking of "blood spilled", I'm reminded of what mayhem must have
gone on at "Python Central" during the debate over the "future
division" transition, which changed the semantics of the "/" operator
not to truncate the result of dividing two integers to an integer,
thus producing a major incompatibility with past versions.  When I
first discovered Lua a few years ago, the first thing I looked at was
what the rules were for basic arithmetic, and was quite gratified to
find that integers were just a subset of double-precision floating
point numbers.


On Thu, 30 Dec 2010 20:09:49 +0200 steve donovan <steve.j.donovan@gmail.com> wrote:

> On Thu, Dec 30, 2010 at 7:50 PM, David J. Slate <dslate@speakeasy.net> wrote:
> > The problem with my idea is not that it clutters up the language, but
> > that it requires another internal representation of a certain kind of
> > array, and it may simply not be worth the effort to write the code to
> > deal with this representation.
> 
> It's not generally a good idea to modify the internals of Lua to
> account for a another special case. Because _everybody_ has a special
> case that would just be so cool to have in the language. Standard bit
> operations were enough of a nag point that the decision was made to
> implement them, and even then blood was spilled in the process.
> 
> Why can't it be a library?  It would be just as efficient.
> 
> steve d.


On Thu, 30 Dec 2010 16:25:35 -0200 Eduardo Ochs <eduardoochs@gmail.com> wrote:

> What about implementing in C the functions:
> 
>   bitarray_and
>   bitarray_or
>   bitarray_xor
>   bitarray_not
> 
> that operate on strings? A string with length 20 would then stand for
> an array of 160 bits...
> 
> > The use of efficient bit ops to perform high-level operations on
> > bool arrays would happen behind the scenes, invisible to the user.
> 
> The low-level way to create a bitarray "object" from a string with
> length 20 would be this:
> 
>   bo = {str20}
>   setmetatable(bo, bitarray_metatable)
> 
> That would give you _exactly the right kind_ of invisibility to the
> user (trust me).
> 
>   Cheers,
>     Eduardo Ochs
>     eduardoochs@gmail.com
>     http://angg.twu.net/