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
