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.
Oh to have a peek! > I later converted the whole thing to Delphi, allowing up to 315,643 > digit precision, which you can find on my web site. Converting the > Pascal to C wouldn't be a huge task, and I might just do that anyway. I saw your Ecalc. It looks great! Im rather disappointed that it doesnt handle googolplexes, but then, one cant have everything I suppose ;) During development of my high precision (80 bit) fp package, the idea was to implement an RPN calculator Thing (I wasnt aware of Things at the time (86/87) but it was to have been implemented as a general system resource) based on the HP41 programmable calculator/computer. All calculations internal to the package would use it directly, and it was to be accessable from Basic (and any other language, including assembler). Of course the dream was ultimately to resurect and enhance my much beloved HP41CX, ie to have a simple programmable interface that would manipulate the stack and the rest of the calculator environment natively, but Ive had to shift all that on to my retirement todo list. (Mind you, dont expect any gamma function or FFT multiplication, as I dont even know what they are ;) > The reason I mention it is that it gets to be very inefficient doing > every operation as a separate *BASIC call - the call overhead itself > will be as great as the computation time (for precisions less that about > 256 bit, IIRC). > > Certainly it's a bad idea to convert to/from decimal! That typically > takes longer than the calculation itself. Agreed. That is why it is more sensible to store the numbers in strings in their internal format. Since C handles types differently to S*Basic, I thought it a good idea to hitch the type to the number format, thus saving time on validation, etc, and to allow a more S*Basic-like feel to coercion within the package. Per
