Tony Firshman wrote:
On Mon, 10 Mar 2003 at 17:44:27, Claude Mourier 00 wrote: (ref: <[EMAIL PROTECTED]>)
De : Tony Firshman [mailto:[EMAIL PROTECTED] Envoye : lundi 10 mars 2003 17:32 A : [EMAIL PROTECTED] Objet : Re: [ql-users] Sbasic and numbers
On Mon, 10 Mar 2003 at 15:45:29, Claude Mourier 00 wrote: (ref: <[EMAIL PROTECTED]>)
Marcel gives already the right (and only ?) answer : always use integer representation for number then convert them with IDEC$/FDEC$. Sad method as this slow down a lot the process.
This is no good for QDOS - it does not use integers. It 'says' it does, but works with FP internally. ie it converts integers to FP, works with that and then converts back - ie integer arithmetic will be slow and unreliable.
Minerva was the first to introduce 'real' integers, followed by SMSQ.
?
I never notice a problem as far as there is no more than 9 digits envolved
... except it's slow
Exactly - and it is not actually using integers at all. It is converting into floating point internally.
Integers are really not used by QDOS - in calculations certainly.
Lau ought to chip in here with the definitive statement.
Goad me into speaking, huh?
QDOS (non-Minnie) does work with integers. It's just not very clever on tokenising them.
Minerva goes to some pains to ensure that whatever comes in as a program gets tokenised, then listed, in a form that will re-tokenised exactly the same. This is deep stuff. What JS would do would be to tokenise a value using all the digits supplied. It the program was then listed (SAVE'd), the value would be truncated to nine digits. On re-LOADing that, the actual value stored in the program could differ from that that the original LOAD (or whatever) had had stored for the tokenised value. Minnie reads the text vale, converts it to FP, reconverts that to text, then back to FP. Is this making any sense to anyone out there? (I liked how I managed to grammatically correctly get both a "that that" and a "had had" into one sentence!)
The choice of exactly how an FP value is displayed is a compromise. As pointed out, it sounds like a good idea to PRINT 0.011 as such. However, take note of PRINTing 0.0110000001, where, if we stuck to a maximum of 9 digits, we'd be rounding it off to 0.011, when we can stick to the digit requirement with 1.10000001E-2 (though I'll admit that it this case it still takes more characters to display).
As a side issue, people often bemoan the lack of long integer support. In the interest of saving space, Minnie implemented short integer tokenisation. I considered doing long integers, but came to the conclusion that it was pointless (is that a pun?).
Firstly, tokenising long integers would take up precisely the same amount of space as floating point.
Secondly, the code to handle long integers would be immensely expensive: they would need coercing routines plus all their arithmetic.
Thirdly, their arithmetic would be scarcely any faster than FP (on Minnie)... and may even be slower in a lot of cases! (FP calcs detect when they are only dealing with up to 16 bit values, and cut out expensive multiply/divide steps - they're even cleverer should a value be a power of two).
Fourthly, ALL calculations made in FP with values that happen to be 32 bit (signed) integer values will give the identical results that would have come from doing the calculation in long integer format. (Excepting non-exact divisions, of course).
As a final digression, I've always bemoaned the fact that floating point is only allowed a twelve bit exponent. It could have gone for 15 bits, which would have reduced the overall code and increased the speed!
There you go.
--
Lau
http://www.bergbland.info
Get a domain from http://oneandone.co.uk/xml/init?k_id=5165217 and I'll get the commission!
