floating point

[Will Glass-Husain <wg...@forio.com>]

Hi,

I've been playing with the floating point number patch recently.

There were several versions floating around the email list in early summer.
It took me a few hours to integrate them into my personal build based on CVS
Head.  Consequently, I took the liberty of packaging the changes together in
a more organized set of patch files and sticking them on Bugzilla.

Second, Peter Romianowski wrote an email a few weeks ago noting that the one
area left for this patch involves conversion of numerical arguments for
method calls.  I wrote some test code, and I think this problem is largely
solved by default, at least in the version I'm working with.

Peter said:

> The biggest one [issue to solve] is how do we invoke methods that have
numbers
> (int or floating point) as arguments.

I wrote a junit test to check this (TestNumberMethodCalls.java, included in
the patch).  I was pretty happy with the behavior.  Peter's example works (I
believe) in a reasonable manner.

> ctx.put ("lv", new Long(3));
> ctx.put ("iv", new Integer(3));
> #set ($value = $lv+$iv)
> $ref.foo($value)

As the returned value is small (6), this will apply to one of the following
methods (first one found).

public String foo(byte val)
public String foo(short val)
public String foo(int val)
public String foo(float val)
public String foo(double val)

For larger values (e.g. a value larger than a short), it will start at the
appropriate method (e.g. int) and search upwards from there.  If the number
is bigger than a long, it will look for a parameter with BigInteger.  (or
BigDecimal for floating points).

This behavior is caused by two factors.  First, the current number patch
does the following

(1) Values returned by math operations get casted to the smallest possible
type (byte/short/int/long/BigInteger or float/double/BigDecimal)
(2) Literals get casted to the smallest possible of common numerical types
(int/long/BigInteger or double/BigDecimal)

Second, the introspector automagically takes primitive values (or primitive
wrappers) and casts them to the most appropriate method (e.g. a byte value
can apply to an int or Integer parameter).  Details are in
o.a.v.util.introspection.MethodMap.

I believe this behavior is easy to understand, and follows "common sense"
principles.  From the template designer's perspective, they can stick in any
number into a method call and it will just work.  (this is important).  From
the programmer's perspective, they can provide an int or double method (or a
long, BigInteger or BigDecimal if the value is expected to be large) and it
will almost always work.

If we change the casting behavior (I think this was discussed this summer,
although I can't remember why), the method calls may require additional
effort to do appropriate conversion.  For this reason, I'm thinking we
should stick with the behavior as is in this patch.

One issue not resolved: TemplateNumber.  The patch allows users to put an
arbitrary object in the context that implements TemplateNumber, allowing
that number to be used in math and comparison operations.  Currently a
TemplateNumber cannot be used in a method call.  I've spent several hours
working my way through the Introspection code, it looks like simple changes
to MethodMap (to find the correct method) and UberspectImpl.VelMethodImpl
(to adapt parameter values) would make this work.  But before I changed this
code, I thought I'd stop and ask for comments.

Best, WILL


_______________________________________
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org