Rich Mellor wrote: > 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. > > Nope. Wolfgang was correct, in that 16-bit integers go from -32768 to 32767. > 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. Nope. Minerva tokenises "-32768" as integer, fetches it as integer, and ditto for the "1". It then sees that the operator is a "/", which obliges it to convert both value to floating point. > 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. > >
-- L _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
