On 31 May 2002 at 12:56, rrokytskyy wrote:

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

I think the whole problem has been exposed as operator error, so we should just
leave things as they are. However I think it would help if the standard test suite,
had some math tests added to it, because it appears that there may be some math
related issues. I don't think we need simplified casting, unless the SQL standard
allows for it. Paul Schmidt, President
Tricat Technologies
paul@...
www.tricattechnologies.com