The majority of my users write scripts to implement custom mathematical functionality. It is very common for my users to write expressions with integer literals and assume the math will be floating-point. For example

double f(double x)

{

return x**(2/3) + x**2 + 1;

}

instead of

double f(double x)

{

return x**(2.0/3.0) + x**2 + 1;

}

Most don’t have any idea what integer division is. Those with any programming background tend to have experience with Visual Basic or Matlab, both of which always use floating-point division. I find myself correcting this common mistake frequently, and I only expect it to get worse as my user base grows.

I hesitate to ask, because it would be a departure from C++ behavior, but could AngelScript adopt an Engine Behavior option that would treat the / and /= operators as floating-point division? We could introduce \ and \= operators to perform integer division (like Visual Basic and Python 3). I suppose even with the engine option disabled the \ and \= operators could still be of some use.

a \ b; // int(a) / int(b)

Let me know what you think, and let me know if you have any alternative suggestions. This is a very common mistake that my users make, so I need to do something about it. Of course, if you agree to the Engine Behavior option, I would provide the implementation.

Thank you for your consideration,

Jason

Just a quick thought, but you could, instead of using the atomic POD types, use a set of boxing types like Java does. You would end up with a bunch of classes (Integer, Double, Float, ...) and overload their arithmetic operators.

I know modifications like this might be a big thing for ongoing projects, but I think it might be a - more or less - elegant approach to deal with your problem.

I thought about that, but my biggest problem comes from my users' use of literals.

I think the use of an engine property to treat the result of / and /= as float/double would be acceptable, as long as the impact in the code is relatively isolated (which ought to be possible).

I don't see the need for an additional operator to force integer division in this case, as the user can explicitly convert the result to integer with int(expr) if desired. Explicit conversions would be more readable than have a backslash or double-slash as integer division in my opinion.

I agree that explicit conversions would be more readable than a backslash. The only issue with int(expr) would be that not all large, 64-bit numbers convert to doubles without loss, so the result of a floating-point division followed by truncation would not necessarily be the same as integer division. I'm not too concerned about that though, because I can always create some sort of "idivide" function in my application.

It turned out to be a very small compiler modification. As far as I can tell, this is complete.

Thanks. I'll review and incorporate the patch as soon as possible.

I've added the patch in revision 2003.

Regards,

Andreas