Lau writes
> > By way of a complete diversion, I did produce a *very* high precision > package for the QL. All in assembler, very optimised, and/but requiring > the precision (in multiples of 16 bit) to be stated in advance (anything > from 64 bit up to a ludicrous number of digits). Not IEEE, but close, > and easily converted. It took the form of a library that operated on a > stack (very similarly to the QL's FP stack and its operations) and a > front end to that. > Great, but I think the problem started with the representation of programmed constants in SBASIC which in QDOS SuperBASIC and SMSQ SBASIC are "rationalised" to a limited accuracy when the program is saved (not quite as clever as Minerva here) . If extended precision arithmetic is used, it will be necessary to intoduce a new data type and implement this through all of the parser, compiler, interpreter, arithmetic routines, conversions and token->text routines. Any offers? > Certainly it's a bad idea to convert to/from decimal! That typically > takes longer than the calculation itself. Yes!!! > Doing the whole thing in decimal strings is not such a bad idea. If > anyone is familiar with the "bc" calculator (Linux/*nix), that does it > that way, and I used some of its ideas for my calculator. There's > already a QL package (via DP) that does this (quickly enough for > moderate precision data). > How about it ? Tony Tebby
