Floating Point Numbers

[Mr_Navigator]

Has anyone in the past written any code that allows displaying in SuperBASIC very large floating point numbers such as 20456.2342456633 for example?

I dont believe there is anything in SuperBASIC that does it as an operator, nor displays it with appended identifier.

Maybe an existing extension?

[dilwyn]

Has anyone in the past written any code that allows displaying in SuperBASIC very large floating point numbers such as 20456.2342456633 for example?

I dont believe there is anything in SuperBASIC that does it as an operator, nor displays it with appended identifier.

Maybe an existing extension?

There was a Maths package by Helumt Aigner but not if it can do what you want - have a look at http://www.dilwyn.me.uk/tk/index.html.
Also, have a look in Quanta Library - disk MA01 - at CalQLator which claims to do up to 120 decimal places. Author was E G Whitbread in 1985. I think program is in SuperBASIC so you might be able to look at the code to see if it does what you want.
I seem to remember a QL program to calculate PI to some alarming number of decimal places such as 1900, but can't remember where I saw it - I just did a quick search on my website and Quanta library but can't seem to find it. Possibly, it might have been in Phil Jordan and Steve Johnson's PD libraries (disk 17 perhaps?)
There's also George Gwilt's FPU routines, but I don't know if those do anything approaching what you want.
And I think there was some extended precision math routines of sorts in C68, but you'd need to ask Dave Walker on that. I think there was a related package called Cephes Mathematical Functions Library which did extended precision functions (hundreds of bits).
Laurence Reeves (he of Minerva fame) also did a maths toolkit of some sort, again, can't remember where I've seen it.
Hope something ticks the right box for you
Dilwyn

[polka]

Floating point in Qdos is to my opinion a very "dark" issue :

QL floating point arithmetic uses 6bytes numbers with 2bytes for exponent and 4bytes for mantissa.
This is the rule when you write programs with SuperBasic, and also for instance when you use the "floating point extensions" of ComputerOne FORTH or DigitalPrecision SuperFORTH (which I never do).

But the math packages usually going with the C (or other...) development systems normally use IEEE floating point format :
4bytes FP with 8bits exponent and 24bits mantissa, giving 7.22 decimal digits resolution
8bytes FP with 11bits exponent and 53bits mantissa, giving 15.95 decimal digits resolution
16bytes FP with 15bits exponent and 113bits mantissa, giving 34.02 decimal digits resolution

So my question is :

does (to your knowledge) Lattice C and/or C68 math package use the IEEE FP format or the QL format ?

and if (as I believe, but I am not sure) they use the IEEE FP format, what with calls to Qdos routines (for instance for graphics) with FP arguments ?

As I never did this kind of programming, I don't know, but I am wondering...

Bye, Paul

[tofro]

Well, displaying a large number of decimal places is definitely one thing. But definitely not of much use if you can't calculate with appropriate precision.
QL SuperBASIC is worth for about 8 to 9 valid decimal places. It will only display 8 of them.
On a native QL, that's about the best you can get with the limited range provided by the 6 byte floats implemented in the native floating point engine, without reverting to e.g. fixed point arithmetics.
C68 uses 32 or 64-bit floating point which should give you enough elbow room to cope with nearly all requirements regarding range and precision. C68 also handles the translation between IEEE doubles and QDOS FP format when callng graphics routines (which are the most important ones in QDOS where floats are involved)
On a Q40(?), Q60 or a QXL (if you happen to have one of the rare ones with a "real" 68040) with appropriate processor, you could use the integrated floating point hardware with up to 64(80) bit precision. George Gwilt has built support for that into QDOS and SMSQ (The FP registers need to be saved between task switches, which is not normally done in QDOS)

If you're prepared to trade speed for precision, you could implement your own fix-point arithmetic package in e.g. assembler - There's a number of (not necessarily QL-related) articles about that on the internet. (for example here: http://stuff.mit.edu/afs/athena/contrib/bignum/)

[Mr_Navigator]

Thanks for the responses, what I am trying to do is display seconds to 3 decimal places from the DATE function in a timed loop. I can calculate using the DATE function to more or less 'second' accurarcy, but as of yet haven't been able to figure how to display it with decimal places.

I want to do some thing like:

32.123
32.347
32.592
32.728

etc.

I can get the seconds to display, and I know I wont capture all micoseconds, the QL is not fast enough, however I cannot display anything like this format, it will only revert to standard (to the power of) format. unless I am missing something really obvious.

[polka]

C68 also handles the translation between IEEE doubles and QDOS FP format when callng graphics routines (which are the most important ones in QDOS where floats are involved)

Thank's, this is really the answer to THE question I was wondering about. An alternative could have been that the math library (maybe it's the case with other C compilers : Lattice ?) had actually entry points to the floating point engine of Qdos, and did all computations with the ROMed routines and this special 6bytes format.

About the other issue : displaying QL clock readings with ms accuracy... Are you sure that the clock actually has such time resolution ? I did not try it with SuperBasic, but the Forth "date" functions deliver a long (32bits) integer thus a resolution of 1 second.

Bye Paul

[Mr_Navigator]

About the other issue : displaying QL clock readings with ms accuracy... Are you sure that the clock actually has such time resolution ? I did not try it with SuperBasic, but the Forth "date" functions deliver a long (32bits) integer thus a resolution of 1 second.

Good point, and no I dont know, you are probably correct about the DATE function being 32 bits long

I may be getting confused with what I used to be able to do in Microsoft QuickBASIC (many years ago) which had a timer function called TIMER which I am sure gave the floating point value of the number of seconds past midnight (accurate to 1/100th of a second, 86400 being the maximum. All programs written in Microsoft QuickBASIC that used the RND function, would then tend to set the random seed at the beginning of the program with RANDOMISE TIMER.

I wonder if it is possible to extract this type of information from the QLs registers?

[RWAP]

No - the standard QL is not equipped with a battery backed clock

There is a DIY Toolkit TIMER routine written by Simon Goodwin which uses high precision timers - but this is only accurate to 1 frame (1/50th of a second on the UK QLs, or 1/60th on other QLs)

[polka]

Let's be simple : why does it have to be counting milliseconds ? any short time intervals will do !

So suppose that when powering up your QL you start a very tiny job written in assembler that just increments continually a 16bit or 32bit counter as fast as it can (only a couple of machine codes, I guess) and not bothering about overflow (with 16bit, passing 65535 it will go back to O,1,2,...).

Now YOUR job, needing a seed, could at any arbitrary time read this value (just read the current value, not touching it).

I wrote this in FORTH (a lot slower than assembler for such a task) :

: .TIME 0 BEGIN 1+ ?TERMINAL UNTIL . ;

and it loops about 800 times a second on my Qemulator (at original QL speed - I dare not imagine how fast it would run at full speed) until I stop it hitting any key, then displaying the last value.

Bye, Paul

[tofro]

Hi,
if it's only for the sake of seeding RND, why don't you just do a
10 RANDOMISE(DATE)
This shold give you a new seed every second - Which I think should be good enough for just about anything random. And it will give you a unique seed until the year 2029
Apologize for this (very) simple solution

And, BTW:
10 RANDOMIZE
(without arguments)
Will use an (internal) random seed (probably something based on time in milliseconds). So all this fiddling around in date and time is most probably not needed at all.
Apologize for this (even simpler) solution

Cheers,
Tobias