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).
(2) OK by me to have rsh simplify to lsh or vice versa,
although I don't have strong feelings about it.
> 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.
(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.
(7) Is the eqv function really needed? isn't eqv(x, y) iff is(x = y) ??
> 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.
> 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.
best
Robert Dodier