velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: comparing monetary value
Date Tue, 15 Oct 2002 16:21:15 GMT
On Tuesday 15 October 2002 05:09 pm, Bill Kaufman wrote:
> > STham@thoughtworks.COM wrote:
> > >  Give a certain amount has to be less than a given value.
> > >
> > >   if ($someMoneyValue < 0.01) ???
> > >
> > >How do people normally handle money in velocity?? Thanks.
> >
> > Apparently, they put some kind of custom "tool" in the context. This
> > strikes me as quite undesirable really, though it is a necessary
> > workaround due to VTL's lack of support for decimal numbers.
> There's another solution I haven't noticed mentioned: Don't use
> floating-point numbers.

Bill, you seem to be saying that the solution to Velocity's lack of floating 
point numbers is not to use floating point numbers.

Well... hmm.... I suppose that's true as far as that goes, in a kind of 
self-evident sort of way, though... :-)

> Instead, calculate everything as integers of the smallest unit (e.g.,
> cents, or tenths of cents).  Not only does this work better in Velocity,
> it's also exact and avoids round-off errors.

This is quite a valid point. Floating point arithmetic can produce some very 
weird rounding glitches when used in business apps. 

In FreeMarker, we use java.math.BigDecimal by default, which actually, in a 
sense, does what you're proposing. A BigDecimal is like an integer of 
unlimited size with a decimal scale. This is the default. In the very latest 
FreeMarker version, we have an alternative "arithmetic engine" which can be 
configured, which uses java.lang.Double and this might well be preferred for 
science/engineering sorts of applications. BigDecimal is clearly better for 
business apps, and we have that as a default, because we think that's where 
the greater part of our user base is.

> Of course, this does have the problem that you'd have to somehow specify
> the units for every currency you support (e.g., 100ths or 1000ths for US$,
> versus 1s for lira),...

Yeah, well, this is the thing. There are different number and currency display 
conventions in different locales. Just for starters, the decimal separator in 
some locales is a period (full stop) and in others is the comma. It strikes 
me as much better if your display tool just transparently deals with these 

Sure, each project can create a custom tool on an as-needed basis, but doesn't 
this imply a constant reinvention of the wheel? It seems to me that a 
view-oriented tool should deal with these things in the core and in a 
standard way.

Jonathan Revusky
FreeMarker-Velocity comparison doc
Velocity->FreeMarker template conversion utility

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message