I think I agree with Rick on this: > I don't agree that there should be a distinction between behaviors > based on how the digits value has been set. The 3.2.0 code did not > make such a distinction, raising an error in both situations.
Hence, if the doc makes no distinction and the 3.2 code makes no distinction, but the 4.x code does make a distinction, then the correct action is to change the 4.x code back to the 3.2 behaviour? This does seem to be the best thing mathematically, too. If the user asks for 20 digits but only gets 16, then the result could be off by 10,000 ulps, which is 'shocking' :-). Some algorithms would never converge with that kind of error. (And, of course, if later the underlying software started using a more precise library based on quad BFP (binary128) or decimal128 then suddenly results could start to be very different. Incidentally, there is now a decimal function library available open source, I think (from Intel). Pretty sure that would provide decimal128, which would permit up to 34 digits precision (I haven't looked at it). Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
