velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <revu...@wanadoo.es>
Subject Re: comparing monetary value
Date Wed, 16 Oct 2002 20:41:45 GMT
On Wednesday 16 October 2002 03:04 pm, Anders Lindback wrote:
> Daniel Dekany skrev:
> > Wednesday, October 16, 2002, 9:44:17 AM, Martin Jacobson wrote:
> > > STham@thoughtworks.COM wrote:
> > >>    I believed at the moment, all numbers are treated as Integer.
> > >> Anyone came across this problem of manipulating with money value
> > >> before?
> > >>
> > >> Example :
> > >>
> > >>   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.
> > >
> > > This thread, for all the heat it is generating, surely revolves around
> > > the separation between business logic, and presentation. If you think
> > > that a rigorous separation is a Good Thing, then there seems, on the
> > > present evidence, to be no requirement for Velocity to handle any
> > > numerical values other than integers. If, on the other hand, you want
> > > to be able to manipulate, eg, monetary values in the template, then
> > > 'vanilla' Velocity won't work for you.
> >
> > I guess we have already seen that sometimes you need decimal values in
> > representation tasks (money...). The list-readers who don't want
> > decimals also admit this when they show workarounds like valueInCents.
> > Why is it better to force designers (and programmers) to play with
> > $valueInCents+tools, than simply providing decimal support? Why is it
> > less error prone and nicer to complicate things with those multiplied
> > values (force designers to always keep in mind, that what is 10.25 in
> > real-world, is 1025 here...), than simply use decimals? Does it make
> > sense?
>
> It makes perfectly sense since computors are digital and are very poor
> to represent floating point numbers. Fractions are a pain in the ass
> - one of the reasons for BigDecimal is too remedy that problem.
>
> Many number that you think would be easy to represent in a computer
> are not easy to represent given todays FPU.  This is especially true
> when you start talking about respresenting money with floats.

Well, what you're saying is an argument against using the standard floating 
point numbers (float/double in java) to represent decimal numbers in business 
apps. However, a template engine can implement decimal numbers point however 
it chooses -- using java.math.BigDecimal or even a custom class, if 
necessary. 

Your argument seems to be that, since a given implementation (float/double) is 
problematic, then it is logical that the problem should not be addressed at 
all (!) 

>
> For example you can get a situation where 2 + 2 != 4 when using
> with floating point numbers. (2+2 may becomes 3.9999999999999 instead. )

Well, there are people claiming it's not necessary, precisely because it is so 
"trivial" to write a tool that handles this. Well, if indeed it is tricky to 
implement deal with the rounding and localized display issues correctly, is 
that not a strong argument for addressing the issue in the template engine's 
core? Then you avoid the situation where countless people trip over the same 
tricky issues implementing the "trivial tool" in question. The problem gets 
solved once and for all in a standard way.

Regards,

Jonathan Revusky
--
FreeMarker-Velocity comparison doc
http://freemarker.sourceforge.net/fmVsVel.html
Velocity->FreeMarker template conversion utility
http://freemarker.sourceforge.net/usCavalry.html


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message