On Mon, Mar 17, 2008 at 3:20 PM, van Nek <van.nek at arcor.de> wrote:
> Am 17 Mar 2008 um 13:55 hat Stavros Macrakis geschrieben:
> > I would recommend that you choose either lsh or rsh as fundamental,
> > and simplify the other one to it, e.g. rsh(x,2) == lsh(x,-2).
>
> Stavros, my intention is the here, to make clear the shift direction just by the functions
> name. The original Lisp function ash (artihmetric shift) doesn't do so. But you are right,
> lsh(x,-1) is understandable as a shift to the right.
The name ash in Lisp is a historical remnant. lsh with a negative
shift treated the integer as a fixed-size word and shifted in zeroes
from the left; while ash shifted in ones from the left for negative
numbers. With arbitrary-sized integers, the distinction is
meaningless. Having one function rather than two is always better.
Consider the identity lsh(x,1)-rsh(x,-1)=0. If rsh simplifies to lsh,
this is handled trivially by the unmodified + simplifier. If not,
there needs to be a special case in the + simplifier or a special
simplification function.
> integer_length(-1) returns 0, because for negative integers it returns the position of the
> leftmost zero (the leftmost 1 in case of positive ints).
> So integer_length(-2^100) returns 100.
So integer_length(-n-1) = integer_length(n) for n>=0? And integer_length(0)=0?
> > > if at least one arg is a string, a Maxima list or constant but not an integer => merror
> > Why not extend to non-integers? logior(1/2,1/3) => 5/6;
> It was not my intention to handle these numbers. I just looked into the Mathematica doc and
> they also only care about integers.
> Stavros, do you see an interesting application of such to rationals extended bitwise
> operations ?
No applications in mind, it just seems like a natural extension, so
why give an error? Why not just leave unsimplified until someone
comes along and programs this case? Certainly some cases are easy:
logop(m/2^i,n/2^i) == logop(m,n)/2^i and preserve all the useful
identities. If you don't allow this, then simplifying logand(x,x) is
only correct if x is an integer.
> > There are many other useful simplifications,
> Right, these are useful simplifications. Can you give me any hint, how to manage them.
Take a look at, say, simpmin to see how to write simplifying routines.
-s