David N. Williams wrote: > > Bernd Paysan wrote: > > On Saturday 25 January 2003 14:54, Anton Ertl wrote: > > > >>>There's a reason to prefer the first version. Sometimes you > >>>want an accurate decimal representation of a radix 2, 64-bit > >>>floating point number considered as exact. > >> > >> [...] > > > > Generally, you should not considder FP numbers as exact representation, but as > > interval of value+-eps/2. Therefore I think it's ok for ecvt() to stop when > > there's only one FP representation for this number, i.e. conversion is clear > > in both ways. ... > If I understand correctly, r2p1 is supposed to be exact to > machine precision, i.e., the truncation of the double (or quad) > precision representation. The algorithm is then careful about > the order of adding pieces, so it gets better accuracy. > > Then you have the problem, how to get r2p1 and t2p1 into the > machine in Forth.
For that you do not need exact output at all (after all, your problem is input). What you need is a >FLOAT that produces the float closest to the decimal number you have given. You can then pass it any of the decimal numbers that are less than eps/2 away from the desired value. Having the exact decimal value corresponding to the FP value desired is not necessary. If you have such a >FLOAT, it would be nice to have a REPRESENT (and F. etc.) that (with enough PRECISION) always produces a decimal number within eps/2 of the FP number given, such that you can convert an FP number to decimal and back without changing it. Producing the exact decimal value corresponding to the FP value is not necessary here, either. There are algorithms for doing these things. However, currently Gforth uses the system functions strtod() (for >FLOAT) and ecvt() (for REPRESENT), and so its >FLOAT and REPRESENT are only as good as the system's, and Gforth does not guarantee any of the nice properties discussed above. > I've done this two ways. The first was to compute in hex with > Mathematica, and construct the raw representations by hand. Somehow constructing the binary representation without using >FLOAT is probably a good way, at least for Gforth (there are of course those hypothetical non-IEEE DP FP versions of Gforth, but I don't know any). > It > was then very comforting to be able to print out the decimal > representations to around 40 digits with F., add them up, and > see that I got 1+sqrt(2) to nearly 34 significant digits, twice > the machine precision. Ok, now I see the application. But that's very specialised. > I believe a better way to do the insertion is with a variant of > >FLOAT that reads C99 mixed hex/radix 2 FP strings. I've > written most of one of those, too, for IEEE 32-bit and 64-bit > numbers. Another way is to use D>F to convert the mantissa, then use f2* or f2/ repeatedly for the exponent. - anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
