On Tuesday, March 11, 2003, at 08:51 AM, Peter Romianowski wrote:
I don't think FP would break existing templates if implemented with
Unfortunately it does. #set ($foo = 5 / 2) will result in $foo being 2.5 instead of 2.
As I pointed out before, it need not be. The only contentious point remaining is the "confusing" syntactic difference between an integer (without a decimal separator) and a real (with an obligatory decimal separator); beyond that, automatic widening/coercion is transparent and well understood.
One possible compromise would be explicit coercion, possibly via a tool. For instance,
#set ($foo = 5 / 2)
would set $foo to 2 as before, but
#set ($foo = $types.asDouble(5) / 2)
(or any variation thereof) would set $foo to 2.5.
Another possibility to consider would be to have one unified syntax for numeric constants (with or without decimal separator), but two sets of operators, � la Caml: + - * / for integer operations; +. -. *. /. for real operations. I'm just mentioning so as to bring it up for consideration, not that I'm advocating it.
care (although I don't see myself the necessity for them); but I just *cringe* at the idea of balooning the numeric types to BigInteger/BigDecimal's. It's just megaton-scale overkill.
As said some times now: The final version will *of course* not use BigInteger / BigDecimal for every operation. That'd be total overkill! I just implemented the *first* version this way, because it was quick to do and would deliver the most precise results. These results can be achived with some if-Statements too and that will be done for a final version (of course, again). My focus has been on correctness rather than speed for the first version.
All right, I stand corrected.
I'd say that any application sensitive enough to overflow to care should implement careful (pardon the redundancy) business logic outside
That's for sure! But I really don't see why something like displaying
a progress bar ("10.23 % finished") would require any business logic.
Other things like displaying a total price should go into the business
logic or controller, since there might be rounding issues. For my everyday
use I find enough cases where I simply need numbers or the possibilities
to compare floats.
These are really two separate issues. "10.23 %" is a formatted representation of a number (which might be more accurately written as 0.102299995). On the other hand, comparison of floats and such I think would be desirable. In general, independently of input (#set) and output (dereferencing), the operators should transparently understand all native types as they might be the results of a method invocation.
I know that "anecdote" is not the singular of "data", but in my experience we never had a problem with this, although we're using Velocity to enter to and display information from a rich database-based application.
BTW, most people forget that with full number support
you get short, byte and long-support too. I cannot count the number of
workarounds I had to implement because my business logic must use longs :)
As I said above, this seems desirable to me independently of the I/O issue.
the template. Otherwise, every Velocity user would pay a heavy tax on the marginal gain of people that should know better than implement BigInteger factorials in Velocity.
As said above: *Of course* no released version will rely on BigDecimal / BigInteger. The overhead to the current (1.3.1rc2) implementation (if you like to stick to Integer) is one if-Statement, like:
if (left instanceof Integer && right instanceof Integer)
And I don't think that there are applications that make you notice the difference (in terms of speed).
I don't mind the overhead of having the built-in numeric types handled in a dynamic, scientific-calculator-like way (where a number is a number even if the representation changes). If implemented well, that could be very flexible and intuitive.
I'd like to point out that it's more usual to widen before operating instead of dispatching on the type, thus:
Number widen(Number n) {
if (n instanceof Long || n instanceof Double)
return n;
else if (n instanceof Byte || n instanceof Short || n instanceof Integer)
return new Long(n.longValue());
else if (n instanceof Float)
return new Double(n.doubleValue());
else
throw new IllegalArgumentException("widen");
}
Number add(Number l, Number r) {
l = widen(l);
r = widen(r);
Number res;
if (l instanceof Long && r instanceof Long)
res = new Long(l.longValue() + r.longValue());
else
res = new Double(l.doubleValue() + r.doubleValue());
return res;
}This implements my suggestion that 5/2 == 2 but 5.0/2.0 == 2.5; if not, widen everything to double and eliminate the first branch of the conditional in add().
If the Velocity compiler can do some kind of static analysis on the expression tree, then a number of widening operations can be optimized out.
If I'm allowed to vote, I'd
-1
on the numeric proposal as it is now.
With the things I said now, what would be your vote? +0? Yours and mine vote wouldn't count, but I'd like to know.
+0 on the basis of perceived (by me) necessity; +1 on the basis of orthogonality. I'm very mixed on this because, on one hand I think elegance overrides usefulness, but on the other I'd err on the cautious side on this issue. I'd rather cast a +0.5 (no pun intended) and break a tie.
Would separating the numerics proposal in two, i.e. enriching the numeric tower vis-�-vis the unified, consistent handling of numeric results make it more acceptable to the community?
Mat�as.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
