I did what I mentioned earlier and replaced the repeated division in FS. by repeated multiplication and one division. I didn't benchmark it rigorously, but it seems to be nearly as fast as the method where we multiply by 1/10, but it doesn't have the accuracy problems. For example:
The new method: > _pi _1e3 f* fs. 3.1415925E3 ok > _pi _1e3 f/ fs. 3.1415923E-3 ok The multiply by 1/10 method: > _pi _1e3 f* fs. 3.1415915E3 ok > _pi _1e3 f/ fs. 3.1415923E-3 ok So the new method restricts the error to the least significant digit printed, where as the multiply by 1/10 method does not. Unless this turns out to be much slower than I expect, I'll run with this new method until f/ can be improved. Any objections if I make the floating point code version 4.1 dependent so that I can use 2>R, 2R> and 2LITERAL? -Leon >Saturday 04 September 2010 >From: "pito" <p...@volna.cz> >Subject: Re: [Amforth-devel] printing floats > Yes, 0.1 is $3dcccccc = 0.09999999403953552 > from that the result will be 3.14158984478e+/-15 (shall be > 3.1415926535e+/-15). > Our result is 3.1415851, or 3.1415874 - so quite precise. However, I > would simply recommend to print with 4 decimal places only. For > atmega users -3.1415E-27 might be ok, I guess. And nobody will be > nervous (:-)). Q: can we set the number of decimal places to be > print somehow? Pito ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Amforth-devel mailing list Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
