----- Original Message ----- From: "Marcel Kilgus" <[EMAIL PROTECTED]> To: "ql-users" <[EMAIL PROTECTED]> Sent: mardi 3 juin 2003 21:52 Subject: Re: [ql-users] is minus one = -1?
> > P Witte wrote: > > In internal format, Exponent . Mantissa: > > > -1 = $800 . $C0000000 > > -1 + 0 = $801 . $80000000 > > > which can be a flaming nuisance! > > You got the mantissas and exponents mixed up, $800 $80000000 is "-1" > and $801 $C0000000 is "-1" but not your two. As Robert wrote this is a > question of normalisation, however, QDOS FP values don't have the > implied "1." he mentions (this is for example found in the IEEE > standard, except the 80bit one which is a bit special in this > respect). As far as I know normalisation is not required for QDOS FP > values. > > In case somebody is wondering how this can be, QDOS FP values work > like this: A FP value consists of an exponent (e.g. $800) and a > mantissa (e.g. $80000000). The exponent has an offset of $800, i.e. in > the example $800-$800 = 0. The highest mantissa bit represents "-1", > the bits following represent 0.5, 0.25, 0.125 etc. always the halve of > the preceding bit. The bits are added up. The generic formula is > 2^exponent * mantissa. > > Therefore $800 $80000000 equals > 2^0 * -1 = 1 * -1 = -1 > Whereas $801 $C0000000 equals > 2^1 * (-1 + 0.5) = 2 * (-0.5) = -1 > > They are both different representations of the same value. One could > construct even more of those, e.g. $802 $E0000000 is -1, too! > > This is one reason why I always warn people to be careful with FP > values. In University one gets taught to NEVER EVER try to compare two > FP values using the "equals" operator but to always use an "epsilon > environment", which means to subtract the values from one another and > check that the result is "almost 0" > Example: Epsilon = 0.000000001 > IF (a - b) < Epsilon THEN PRINT "They are equal". > > In SuperBasic I believe this technique is already implied when using > the "=" operator. But you cannot just compare the bytes of the two > values (e.g. in assembler) because of the different representations a > value can have (there's some rounding going on almost every time one > uses FP). > > > Is this a bug? > > Point of view, I'd say no. The original SMSQ/E routines give the same > result for both -1 and -1+0, it's the PC FPU (or the IEEE->QDOS > translation) that gives something different on QPC. I could probably > do some normalisation, which could solve your problem in THIS case, > but other than that... > > Marcel > I hardly dare to disagree with Marcel but I would describe it as a bug. It would not be a bug on any other system because as Marce rightly says "In University one gets taught to NEVER EVER try to compare two FP values using the "equals" operator" so you could not rely on the result. In SMSQ, you should be able to rely on the result. SMSQ digital string to FP value conversion is supposed to be exact in that all decimal values that can be represented exactly in binary floating point (e.g. 9999.625) are represented exactly in floating point and that operations (add, subtract, multiply, divide and, within certain limits rasing to a power) that can yield exact results will yield exact results (e.g. 9/6 is exact but 9/5 is not exact). For this reason you should be able to rely on 1+2+3+4+5 being exactly equal to 15 (in SMSQ) whether you do the operation in integer or floating point. In this case, the values are exact, it is just that they are not represented exactly the same. The problem being that for all integral n, 2^n and -(2^n) have different exponents when normalised. I thought that all negation operations in SMSQ checked for this - is it a general problem or is just certain implementations of SMSQ? Tony Tebby
