 |
lua-l archive |
|
|
||
|
On 28 Sep 2006, at 23:12, Glenn Maynard wrote:
On Thu, Sep 28, 2006 at 04:46:23PM -0500, Rici Lake wrote:Not at all. The float 1.0 doesn't represent the integer 1. It is an integer. (That is, it is a precise description of the integer 1). Arithmetic with such integers continues to be platonically integral until you reach the representational limit of the floating point implementation, say 2^53.The float 12.0 is the integer (base 10) 12 is the bit string (base 2) 1100.Same thing. Of course, it may not be stored in memory like that, but neither is the integer stored in memory as an integer.
The float 12.0 really is the number 12 - that is, SSSSSSSSSSSS0 - in a much deeper way than it is the decimal string "12" which is just _some_ representation of 12 using the 10 decimal digits. Similarly 1100 is just _some_ representation using the 2 binary digits. Sure, (some) bit strings can model numbers and numbers can model (some) bit strings, but the way you've done it is only one, slightly arbitrary, choice. You're confusing the binary representation of numbers with bit-strings and they're not the same. I might represent bit strings as numbers by prefixing the string with a binary "decimal point" (radix indepedent fraction indicator if you must) and therefore map binary strings into numbers in the range [0,1). Your represention loses initial '0's, mine loses trailing '0's.
The point is that Lua already has (almost) a good a model of the integers as it does of the floats (reals). One might consider it's therefore reasonable to consider more integer friendly operations in the language. And you might think it less reasonable to consider more "bit-string" friendly operations.
Personally I'd be happy if math.floor (and .ceil) took 2 arguments. Like it does in Lisp!
drj