RE: [Axiom-developer] Left shifts of negative numbers

[Page, Bill]

Dylan,

[ Some of your emails arrive as text file attachments to
otherwise empty emails (such as this one) and other times
as ordinary email? Are you sending an unusual format to
the axioim mailing list? (e.g. HTML or "rich text" format). ]

I agree with your analysis. Note that a similar but
different defintion of shift is given in si.spad.pamphlet
(SingleInteger)

  shift(x,n) == QSLEFTSHIFT(x,n)$Lisp

In Axiom both

  -> )lisp (ASH -7 -1)

and

  -> )lisp (QSLEFTSHIFT -7 -1)

return -4. Oddly, I could not find any definition for
QSLEFTSHIFT. ASH is an "arithmetic" shift. I looked for
a Lisp function for "logical" shift (as found in some
machine architectures) but did not find any. In Axiom
I can write

  -> ASH(-7,-1)$Lisp

but

  -> QSLEFTSHIFT(-7,-1)$Lisp

says: "QSLEFTSHIFT is not a lisp function ..." ???

Maybe some of the Lisp programmers here can give us a
clue as to why?

Failing finding a native Lisp function that does the
job, how about defining it as

  shift(x,y) == integer(ASH(x-1,y)$Lisp)+1

Regards,
Bill Page.


> From: address@hidden
> [mailto:address@hidden
> Sent: Tuesday, October 14, 2003 5:41 PM
> To: address@hidden
> Subject: [Axiom-developer] Left shifts of negative numbers
 
> I have investigated Bug #4733 (rounding of negative numbers).
> The problem is unexpected behaviour of 'shift' with negative
> arguments: 'shift(-7,-1)' is -4, while the code in the
> 'truncate' function in float.spad.pamphlet clearly expects the
> answer to be -3 in this case. The definition of what 'shift'
> should do in IntegerNumberSystem is ambiguous about what should
> happen with negative arguments, but in integer.spad.pamphlet
> 'shift' is actually implemented with a call to the lisp function
> 'ash'; according to the standard I found on the web (see

http://www.lispworks.com/reference/HyperSpec/Body/f_ash.htm#ash

> ), 'ash' should have the opposite behaviour: '(ash -7 -1)'
> should be -4 (as GCL implements).
>
> Presumably the correct fix involves changing 'shift' so that
> it rounds towards 0 when both arguments are negative (and
> documenting how it actually behaves), rather than changing
> the code in float.spad to deal with the current behaviour?
> What will other axiom code expect?  Most of the instances in
> the algebra tree seem to apply 'shift' only when the first
> argument is positive.
>
> Peace,
>       Dylan