On Tue, 19 Jun 2001, you wrote:
> Thank's a lot for your work. I think it would be a good idea to store the
> result somewhere for all the community. Because I still think this behavior
> is not obvious and can generate unexpected results and frustrations.
>
> Claude
I couldn't resist a contribution on this thread:
1) FOR/NEXT
If you want a predictable number of steps, you should always do integer
FOR/NEXT loops (or at least use integral strart/step/end values). You
can always then use a scaled value of the index to do what you want
inside the loop.
Now for the more curious bit. I'm not sure if SMS still adheres to this
(in fact, I'm pretty sure it doesn't, 'cos SMS tries to be
"efficient"). On all QDOS versions, Minerva included, what FOR/NEXT
does is this:
Each time through the loop, the FOR variable value has the STEP value
added. This is subtracted from the TO value. If this result
is "small", the EXACT value from TO is stored at the FOR
variable and the loop continues. If the result has gone past the TO
value, in the direction of the STEP, the loop exits (without
actually changing the FOR variable's value). Otherwise the loop
continues with the FOR varible updated by STEP.
The "small" in the above was done very pedanticly pre-Minnie, bu Minnie
just looks for exponents differing by 13. That means it checks for
about STEP/8192, but a factor of two either way of that really.
Now, the above is all pretty clever, and copes VERY well with people
who like doing "FOR J = 0 TO 10 STEP 0.001". What happens in this
example is that the value in J drifts progressively off the intended
value, as 0.001 will not be exactly represented as floating point. The
inaccuracy is multiplied by 10000 by the time it gets to the
intended penultimate value of 9.999 (it can be expected to be out
by 10000 times 2 to the -32, i.e less than one part in a million).
However, firstly the QL loop will do exactly 10001 steps and secondly,
the final value will be precisely 10 (not a smidgeon less )(or more!).
Now, the down side of the clever stuff (which has only just occurred to
me!):
"FOR j = 0 TO 999999 STEP 500000" will do J=0,500000,999999 which you
might not expect!
So much for all that stuff.
Except... I have this vague memory that TT was going to make FOR loops
hold onto the initially supplied values, evaluate how many steps they
looked as if they needed to do, then do exactly that many, scaling the
variable to neat values along the way. Maybe he didn't.
2) INT and Rounding
A kettle of fish.
For serious PURE mathematical reasons, INT should always give the
integral value which is strictly less than the supplied value.
However, when genuinely off into the floating point world, which is
very symmetrical about zero, the "round toward zero" rule is much
preferred.
Where I could, in Minerva, I also respected the IEEE "halves round to
the nearest even value" rule. This rule has two benefits (and one
disadvantage!). Firstly, it tends to make computational inaccuracies
even themselves out better. Secondly, it tends to leave at least one
less non-zero bit in the result, which means its going to fit into 32
bits (or whatever) more often. (The disadvantage is that an extreme
value will round to overflow rather than squeeze down to all ones... so
no big deal).
P.S. A curious trick that I introduced in Minerva.
When a pre-Minerva program was typed in, what you typed as a numeric
value was tokenised and stored. What was listed went through the normal
PRINT routine. Fine, if you stored the program and reloaded it. It was
thereafter totally consistent. However, say you typed in
"0.3333333333333". When you did that, the tokenised value was accurate
to the precision you typed. However, the PRINT value would only show
nine digits. When THAT was stored and reloaded, the tokenised value
wasn't exactly the same!
I.e. "I typed this in and it worked. Why doesn't it work now I've
reloaded the program?"
Minerva actually does a "doulble-take" before tokenising. It stores
only exactly what it will list, save and restore.
P.P.S. I guess it's really time I tried to sort out uploading the Minnie
sources?
--
Laurence Reeves
