DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43940>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43940 Summary: Faster method for double formatting Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: general AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] We format a lot of double values to strings for PDF and PostScript output. We currently use DecimalFormat in a problematic way (DecimalFormat is not thread-safe). It also doesn't quite cover the requirements I have for the method in that particular context. Furthermore, this has shown as a minor hotspot in profiling sessions. The task is to write an implementation of the following method: static void formatDouble(double value, int decimals, int precision, StringBuffer target) value: the double value decimals: the number of decimal places behind the decimal point precision: the maximum precision for small values. If the value is between -1 and +1, the precision needs to be increased up to the number of decimal places indicated by this parameter. This is used in contexts where transformation matrices scale the content and a higher precision might be required. target: the formatted characters are appended to the given StringBuffer. A StringBuffer is chosen for efficiency so the number of String concatenations can be reduced if possible. A wrapper method returning a String is easily written around this method. The goal of this method is to have a compact representation of a double value while adressing accuracy requirements in the usage context. the decimal point is . (".", PERIOD) (this is not dependent on the user's locale) A few examples (consider decimals being 4 and precision being 8): 0.0 should be rendered as "0" 0.1 should be rendered as "0.1" 1234.1 should be rendered as "1234.1" 1234.1234567 should be rendered as "1234.1235" (note the trailing 5! Rounding!) 1234.00001 should be rendered as "1234" 0.00001 should be rendered as "0.00001" (here you see the effect of the "precision" parameter. 0.00000001 should be rendered as "0.00000001". 0.000000001 should be rendered as "0". Acceptance criteria: - The method has to prove to be faster than new DecimalFormat("0.######", new DecimalFormatSymbols(Locale.US)).format(value) on Sun Java 1.4, 1.5 an 6.0. - The method must be thread-safe. - The method must have a javadoc comment. - It must be accompanied by a JUnit TestCase testing all aspects of the method. - It should not depend on any additional library not already in the dependency list of Apache XML Graphics Commons (its destination in the end). Any volunteers? The prize: eternal glory and a big "thank you" from me! ;-) Otherwise, this is just a reminder for myself. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
