Chris Stasny wrote:
> 
> But there will always be issues of how to handle inexact
> approximations of decimals when dealing with a crowd that has used
> high precision BCD numbers for years.
> 

For me the INT issue has little to do with the precision of BCD vs. SANE (or
other internal representations).  When I use INT, it's usually to answer
questions like, "How many boxes of width x! can I fit on a line of width y! ?"
 The "traditional" answer is: INT(y!/x!).  This formula would *occasionally*
yield the wrong answer (using BCD *or* SANE) if y! is very close to a multiple
of x!; but I can predict that and deal with it.  On the other hand, the
formula is utterly useless if INT sometimes rounds up and other times rounds
down (it then gives the wrong answer roughly *half* of the time).  I do not
think it's a "better" implementation for INT to round rather than to truncate;
sometimes we do want to round, but often (much more often, in my case), we
really, really do need to truncate, and rounding simply gives the wrong answer.

I can still salvage my "boxes" program by using FIX(y!/x!); but in the
interest of compatibility with other languages (including FBII), I'd rather
have seen INT do what it used to do, and maybe a new ROUND function to do the
fast rounding thing.

- Rick