On Sun, 17 Dec 2006 16:39:56 -0000, Wolfgang Lenerz <[EMAIL PROTECTED]> wrote:
> On 16 Dec 2006 at 10:56, Marcel Kilgus wrote: > >> Wolfgang Lenerz wrote: >> >> On an ordinary QL I can type >> >> >> >> f%=-32768/1 >> >> >> >> and find that f% now contains -32768. >> >> >> > Well that must be a nice bug. >> > >> > unless I'm mistaken, 32768/1 = 32768 >> > >> > and 32768 just doesn't fit in an integer. >> > Err, what? > 32768/1 = -32768 ???? > How can that be? > I still think that there is no problem, integers go from -32768 to > 32767, NOT > to 32768. OK the contradiction in your email aside Wolfgang, integers go from -32768 to 32768. The original statement that causes the error is f%=-32768/1 which should result in f% containing -32768. I wonder if the error is caused because SMSQ/e (unlike Minerva and QDOS) sees this as an integer calculation. It therefore tries to do 32768 / 1 and then negate it. As an integer, as soon as it tries to put 32768 onto the stack it fails as this is not a valid signed integer. As Laurence points out, Minerva and QDOS convert fetch the numbers as floating point, do the calculations in floating point and then convert the result to integer. I am not sure how SMSQ/e does this, but if it fetches the numbers as integers, it will fail if it tries to fetch 32768 (although not -32768). So if we can step through how SMSQ/e calculates this statement (f%=-32768/1), perhaps we can see the cause of the error. -- Rich Mellor RWAP Services URL:http://www.rwapsoftware.co.uk URL:http://www.rwapservices.co.uk _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
