> 1. it seems the fs. routine presition itself is 7 digits which is > good > 2. it seems the f/ most notably with larger operands (eg. +/- 1e15) > introduces errors so the result's precision drops to 6 digits or > less
Yes, the number of decimal points it prints should be related to the size of the number -- I just trusted an algorithm in the paper I linked to handle it correctly. 24 bit significands can hold about as much as 7 decimal digits, so that's about the most you should see. > 3. what is interesting the fs. conversion took seconds (atmega > @25MHz)e.g.: This is partially a mistake on my part -- there are a number of things like "10 s>f" in the code which I should really replace with "[ 10 s>f swap ] literal literal", or something like that so that they don't have to be calculated repeatedly at run time. I meant to do it before release but forgot -- I'll do it today. Even with that change, it still may be slow. -Leon ------------------------------------------------------------------------------ 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
