Re: Hidden integers...

["Ben Cooley" <benc@...>]

> 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.

Sounds like you were running up against the same sort of issues we were.
It's a pain to have to use epsilon values to fix float/int conversions all
the time, and try to find out where and why 8.99999999982 didn't convert
correctly to integer 9 in your code.

> > 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.

If you do, tolua will not work.  We've tried it.   Not that we use a lot of
real time floating point in our project, but if you're only using 'float' in
a game, double is a bit of overkill.  It's possible implementing hidden
'double' with the Value union for some projects might be better than
converting everything to 'double'.

> > 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.

Theres a small error that crops up and gets worse in floating point when
doing multiplys and divides.  It gets larger as you do more of them.   You
can use an epsilon value to check to see if a floating point value falls
within a given range of an integer value and round it, but it adds a hidden
inaccuracy in the floating point system if everything is floats.

> > 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.

Perhaps.  Of course our projects would largely end up being integer only, so
we wouldn't care.

> 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?).

To ensure that hidden integers don't break code written for floats, you have
to convert to a float if there could be an overflow.   The imult() function
would simply do an integer multiply.

The idiv() function is just sytactic consistency for the rest of the integer
routines.

> 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.

Yeah.. could be a problem.  I dunno.. I'd have to check how the VM works and
see what it would mean.

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

Thanks.