On 03/11/2010 12:00, David Parks wrote:
> I ran into a problem with decimal formats. Example:
>
> $math.roundTo(10, 0.158343834599)
> Actual Result : 0.15834383478471944
> Expected result : 0.1583438346
>
>
According to its souce code, the roundTo method is, for the time being,
limited to 9 digits.
> Aside from roundTo(...) producing incorrect numbers of decimal places (when
> 10 or more is entered as param #1) the rounding is blatantly incorrect (I
> expect this is due to Decimal rounding error).
>
> I wanted to fix this by writing my own methods to use BigDecimal, but here I
> ran into a problem. When I implemented:
>
> public Number myRoundTo(int decimalPlaces, String num){
> BigDecimal bg = new BigDecimal(num);
> return bg.setScale(decimalPlaces, RoundingMode.HALF_UP);
> }
>
> A call to $mymath.myRoundTo(2, 1.234) is never called. This is because 1.234
> is converted to a Decimal and velocity finds no method with a signature of a
> (Integer, Decimal) (I can accept an Object, but then I still get a Decimal
> which will produce rounding error as documented in BigDecimal javadocs). My
> concerns are:
>
> 1) Why can't velocity convert a number parameter to a String or BigDecimal
> format if the method signature calls for that. This should not be complex
> using reflection. If someone will even point me to the right spot in the
> code I might be able to post a quick patch for it.
>
We are already using reflection to automatize several conversions  but
conversions between numbers and strings are not always done magically.
As you found out, quoting numbers is an easy way to convert them into
strings.
> 2) roundTo(...) should be fixed to avoid Decimal use, this unfortunately
> seems to depend on #1. In fact Decimals should be avoided altogether for
> view related cases, the performance gain over BigDecimal just isn't going to
> be notable in this context.
>
We can't make asumptions on the type of encountered numbers  neither
can we impose one subclass of Number or the other.
What we need to is to use BigDecimals when necessary and to fix the
MathTool to reach a consistent behaviour with BigDecimals.
> 3) Why convert a number  like the 2nd param in: $math.roundTo(3, 1.234) 
> to a Decimal rather than a BigDecimal? Seems more logical to convert it to
> BigDecimal then pass it to the method as a Number.
>
>
I'm not convinced that we should use BigDecimals when unnecessary  what
would we gain?
> For now my solution is the inelegant:
>
> #mymath.myRoundTo(2, "1.234")
>
>
>
$math.roundTo(2, 1.234) produces 1.23 as expected.
Claude

To unsubscribe, email: userunsubscribe@velocity.apache.org
For additional commands, email: userhelp@velocity.apache.org
