Re: Hidden integers...

[Reuben Thomas <rrt@...>]

> 1. As a scripting language, lua must interface with C code which is
> largely integer based, and contains numerous instances of bit flagged
> variables, shifting, and integer arithmatic.  Representing these values, and
> performing these operations in lua presently is either poorly handled or not
> possible.

Indeed. My bitlib offers bitwise operations, and on a typical system will
offer 56-bit integers (i.e. the size of the mantissa of the floating point
type). In practice, this means that with a little care it's possible to
treat numbers as 32-bit integers. But there are bound to be some gotchas. I
did however manage to write an assembler for a VM which had to manipulate
32-bit words and bytes quite successfully.

> 2. Representation of floating point values as doubles is required because
> lua does not support true integers.  In game applications where floats are
> the primary floating point value used, constant conversion of floats to
> doubles and floats to integers take place.

Although you can always make Lua use float instead of double for its number
type.

> 3. Certain operations which return imprecise results in floating point
> (division, multiplication, etc.) are better handled using integer
> armetic.

Although unless you need more than 32-bit integers, the floating point
result will be accurate.

> 4. In many cases, integer arithmetic in the VM is faster than floating
> point arithmetic.

Although the overhead of interpretation tends to obscure this (except on
processors such as the ARM that don't have hardware FP), and the extra
overheads of implicit conversion might make it worse.

> 5. Integer supported added in the way proposed would not break existing
> programs (except those which may depend on all numeric variables returning
> the string "number" for the function type()).

Sounds good.

> Integer constants would be represented in lua as integers and not floating
> point values.  Assignment of an integer value to a variable would result in
> an integer variable.

> i = imult(a,b)
>
> Would return the integer result of multiplying integer values a,b and
> would not convert to a number on overflow.  If a and b were not integers,
> they would be converted to integers.

I'm not quite clear what this is for (as opposed to just i = tointeger(a) *
tointeger(b)). Similarly idiv (presumably the mod function would be extended
to give an integer result for integer inputs?).

The thing I worry about is performance loss owing to lots of extra checks
being made (is the number an integer or a float?). But perhaps this isn't a
problem, since all the operators can also have tag methods, so there's
already a check being made as to whether the operands are numbers, tables,
or userdata.

I am very much in favour of adding integer operations to Lua if possible,
and this sounds like a plausible scheme.

-- 
http://sc3d.org/rrt/ | Caution Children At Play Drive Slowly