Re: Integer division

[Jay Carlson <nop@...>]

On Nov 20, 2012, at 3:49 PM, Roberto Ierusalimschy wrote:

>> I worry that integer multiplication might slow down some of my code,
>> and there'd be a risk of unexpected precision overflows.
> 
> As integer will be a "visible" subtype, you can choose not to use
> it. If you feed floating-point numbers to your computations, Lua will
> perform them using floating-point arithmetic, just like today. The
> main difference is that you have to think about how you want to handle
> overflows.

Is it a goal to have this invariant?

  For all numbers n1, n2:
  For all non-debug Lua expressions L:
      [[ function f(x,y) return L end ]] 
  There do not exist integers i1==n1, i2==n2 such f(i1,i2)~=f(n1,n2)?

That is, do expressions mean the same thing regardless of the subtype of their numeric values?

If this is true, it really is my decision how to handle overflow; I can tell what behavior is by local inspection.

If this is not true, I only decide how to handle overflow if I have written the whole program. Libraries and other people's code may return integers where I expect general numbers, or place them into tables etc etc, leading to fascinating bugs and/or attacks.

I think this is a stronger property than "no type contagion". By "contagion", I mean automatic promotion from ints to floats. Under a "no type contagion" rule you can still have polymorphic arithmetic operators but add(n,m) requires subype(n)==subtype(m). This makes you explicitly coerce arguments if you want the unusual behavior. In the invariant above I can set i1,i2 to MAXINT, n1,n2 to tofloat(MAXINT), and L to "(x+y) // 2" and get different results. The place this comes up is when I call f(a[1], a[2])--values supplied by some library not under my control.

As I've implied, one way out of this is to ditch polymorphism of numeric ops. If you want maxint overflow and integer coercion, use "n1 +! n2": this has consistent behavior regardless of the types of its arguments.

Jay