Maxima interface to Lisp bit-functions



Am 18 Mar 2008 um 8:02 hat Robert Dodier geschrieben:

> On 3/17/08, van Nek <van.nek at arcor.de> wrote:
> 
> >  lsh(int, count): left shift
> >  lsh(int):  count=1 by default
> >  rsh(int, count): right shift
> >  rsh(int):  count=1 by default
> 
> (1) I recommend omitting the count=1 default. Not enough to gain
> by writing lsh(x) instead of lsh(x, 1).

My intention was to make short code possible. If we add bit_ or bitwise_ in front, the two 
more characters ,1 don't matter. OK by me.


> (2) OK by me to have rsh simplify to lsh or vice versa,
> although I don't have strong feelings about it.

Stavros convinced me yesterday to skip rsh. (Mathematica offers both.)


> >  logbitp(index, integer):  tests, if bit with weight 2^index is
> 1
> >
> >  logand(int1, int2, ... ):       bitwise and
> >  logxor(int1, int2, ... ):       bitwise xor
> >  logior(int1, int2, ... ):       bitwise ior
> >  logeqv(int1, int2, ... ):       bitwise equivalence
> >
> >  lognot(int):  bitwise not
> 
> (3) I recommend separating the specific function name from the
> prefix, and changing the prefix since "log" suggests logarithm.
> Instead: bitwise_bitp, bitwise_and, bitwise_xor, etc.

When I started I had nothing in mind but the original Lisp functions for integers. In didn't 
thought of simplification rules. Now it turns into something different. So why not find better 
names then. I would prefer the short prefix bit_.


> (4) Probably lsh and rsh should be bitwise_lsh and bitwise_rsh
> for consistency with the names of the other bit operations.
> (5) Also I recommend "or" instead of "ior". I don't think the
> extra "i" helps any. Other programming languages don't have it.
> (6) The and, or, xor, and eqv functions should be declared
> commutative --- Maxima knows a little bit about such functions,
> and any extensions to the treatment of commutative functions
> would help these functions too.

What do you recommend? Should these functions have operator properties like floor etc.? 

> (7) Is the eqv function really needed? isn't eqv(x, y) iff is(x = y)
> ??

I am not shure about this point. I listed it for completition. 
(Mathematica doesn't have this function.)
 
> >  integer_length(int):  length of the bit representation
> 
> (8) This name seems problematic. How about something narrower
> such as integer_log2 or floor_log2 ?
> (9) Also I wouldn't try to define this for negative integers --
> seems
> too ambiguous. Let the user write floor_log2(abs(n)) to make it
> clear.

This is what I found in the doc of Mathematica:

BitLength[n]
gives the number of binary bits necessary to represent the integer n

    * For positive n, BitLength[n] is effectively an efficient version of Floor[Log[2, n]]+1. 

    * For negative n it is equivalent to BitLength[BitNot[n]]. 

E.g. bit_length(-8) is bit_length(7), so bit_length(abs(n)) wouldn't make anything clear to me.

But I also see problems here. There will be an inconsistancy with the ibase : obase : 2 
notation. -8 decimal should be viewed as 000 binary (omitting the trailing 1s). This is what 
fits to bit_length(-8) = 3. But you can't read 000 back to -8.


> >  All function behave as follows:
> >
> >  if all args are integers => evaluation
> >  if at least one arg is a string, a Maxima list or constant but
> not an integer => merror
> >  all other cases => unevaluated expression
> 
> (7) This is OK by me. Extending these functions to rational
> non-integers or whatever is OK too, but that is something
> we can add later if we want.
> 
> Thanks for bringing this to our attention, Volker. I think at this
> point
> the important thing is to spell out the list of functions and
> their
> properties. I'm pretty sure it will be straightforward to write
> the
> simplification functions or whatever once we have a specification.

I have in mind to realize some simplifications. E.g. for bit_and:

bit_and() => -1
bit_and(x) => x
bit_and(x,x,y) => bit_and(x,y)

bit_and(x,-x-1,y) => 0 

bit_and(0,x) => 0
bit_and(-1,x) => bit_and(x)

bit_and(5,6,x) => bit_and(4,x)

But I do not plan to do this before the first of april.

Volker



> 
> best
> 
> Robert Dodier
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima