> I think that possibly adding 64bit Integers broke a few things in
> the math routines (maybe it never worked correctly -- not a lot of
> applications do a lot of math on the SQL side) so it needs some
> checking, personally I think when dealing with numbers, if there is
> a float or double anywhere it gets cast to double, and dealt with
> that way. If there is no float or double, it gets cast to INT64
> and you do a modulus, if the result is 0 do the math in INT64 cast
> the result into the same as the longest input value, or the
> shortest value that will contain the result, whichever is longer.
>
> If the modulus result is not 0, cast everything to doubles do the
> math as doubles and if the result contains a decimal point leave it
> as a double, otherwise cast it into the same as the longest input
> value, or the shortest value that will contain the result,
> whichever is longer.

Why don't we keep usual type conversion you have in Java (and I
suspect in C/C++ too) - line is processed from left to right taking
parenthesis into account and we automatically cast operands of an
operator to the more precise type?

(3/10) * 3.3333333 = 0 // already present
3/10 * 3.333333 = 0 // already present
3.333333 * (3/10) = 0 // already present
3.333333 * 3 / 10 = 9.99999 // already present

Also we can simplify developer's work by introducing simplified
casting (like (int)3.0 or (double)3 ).

Best regards,
Roman Rokytskyy