On May 20, 2006, at 1:09 PM, Mark Wieder wrote:
Note: this is BZ #2419, which for some reason Tuviah closed as
NOT_A_BUG in January 2004, so unless Jacque reopens it it's unlikely
that it will be fixed.
What would you recommend as the new behavior for Revolution trunc()?
I'm assuming you want trunc() of a positive number with a fractional
part almost one to round up. Since that is the situation here.
How close should it be?
Here is one approach that makes it consistent with Revolution fuzzy
equality:
on mouseUp
put 10.27 into tNumber
put the trunc of tNumber into tInteger
put tNumber - tInteger into tDecimal
put 100 * tDecimal into tNewDecimal
put trunc(tNewDecimal) && markTrunc(tNewDecimal)
end mouseUp
function markTrunc y
put trunc(y) into c
if c+1=y then -- floating point fuzzy equals
return y
else
return c
end if
end markTrunc(y)
Maybe, you can suggest that as a feature enhancement.
(An alternative would be to add a tiny epsilon to the number and then
truncate.)
Though, the real problem is the binary point in the representation of
the result of arithmetic, some folks might prefer this to doing
anything that might slow down arithmetic. For me, I lean toward
going toward a decimal point in Revolution arithmetic.
Dar Scott
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
