Marcel Kilgus wrote:
TonyTebby wrote:
I hardly dare to disagree with Marcel but I would describe it as a bug.
Oh well, if you wouldn't dare, who would? ;-)
I'd dare...
It's a bug.
Although I would guess that no "official" documentation might state categorically that numbers are supposed to be normalised, it has to be done.
It's not just relevant to "comparison for exact equality". If un-normalised values are allowed to creep into calculations, accuracy is lost. (E.g. an addition operation first looks only at exponents in order to determine how far a value has to be shifted before a straight addition is performed. If a value is not normalised, it may be completely disregarded when it should contribute to the result.)
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?
I suppose it's QPC only as QPC exchanges all the original FP calls with a few "QDOS to IEEE, compute using FPU, IEEE to QDOS" routines (which doesn't really take more time than, say, about 5 emulated average instructions...). The problem seems to lie in the back conversion to QDOS format and only affects negative numbers. I think I have fixed it, but then I have some headache at the moment and FP arithmetics is no fun even when fit and sober.
To clarify why IEEE and QDOS formats differ:
1) IEEE uses a "concealed leading one bit" and has an explicit, separate sign bit.
2) QDOS uses a standard signed value. It has no form of negative zero and, other than zero (and denormal values... see below), insists that the two most significant bits differ.
Negation of an IEEE value merely inverts the sign bit. IEEE in fact has negative zeroes, which it is quite careful about!
Negation of a QDOS value always has to check for the (irritating) case of negating $8000000.
BTW, I've read that Quanta published some IEEE<->QDOS FP conversion routines in the past (might have been quite some time ago). Does anybody remember this and can scan me a copy?
I don't think you need worry too much. I suspect that the routine you use to convert to IEEE always ends up by normalising (in IEEE terms) the value pushed onto the FP stack. My comments about lack of accuracy won't apply. The problem is probably in the conversion back to QL format. For all the "usual" values, it is indeed only negative powers of two that cause the problem. However, if you are implementing denormal values (as Minerva does) you have to be a bit picky. Them aside, a correctly normalised, non-zero mantissa will always set the V flag when shifted left one bit (or added to itself).
Denormal values:
Both IEEE and Minerva (and I think that means SMS as well, as I believe TT used my code) use the concept of denormal values. They are there to improve accuracy when "tiny" values crop up in calculations.
The idea behind them is that there should not be a sudden accuracy cutoff in the representation.
IEEE (IIRC) uses the one below its normal maximum negative exponent to flag up that the exponent is *really* only maximum negative, but that the mantissa now has an explicit leading one bit.
Minerva (due to the differing approach) just lets values with its maximum negative exponent (zero, as represented) have leading bits which don't differ. Note that this means that, Minerva's zero value (exponent *and* mantissa all zero) is just another denormal value.
I think prior QL ROMs were a bit cavalier in this area.
Depending on your luck, invalidly represented values *might* not cause problems on Minerva, but I wouldn't bet on it. E.g. a zero mantissa value with a larger non-zero exponent value creeping into "1.0 + 0.0" might well cause a result of zero. It decides that because the exponent of the zero is so large, the value "1.0" would need to be downshifted so far that it will not contribute to the result, so it just returns the (still naffly represented) zero.
Testing:
I thought I'd mention - when I was developing the Minerva arithmetic routines, I actually tested them against IEEE calculations (and my extended precision calculator). I ran thousands of comparisons where I generated nasty patterns of bits for mantissas (etc), including all the exact powers of two and ones that differed from them by least significant bits and so on. It took quite a while before I convinced myself that my arithmetic was "perfect" (i.e. barring cases where results could not be represented, the IEEE result matched the Minerva result bit for bit, even on non-exact divisions and square roots!).
--
Lau
http://www.bergbland.info
Get a domain from http://oneandone.co.uk/xml/init?k_id=5165217 and I'll get the commission!
