# Get rows product (multiplication)

If you need this type of calculations often, I suggest you store the signs and the logarithms in separate columns.

The signs can be stored as `1`

(for positives), `-1`

(for negatives) and `0`

(for zero.)

The logarithm can be assigned for zero as `0`

(or any other value) but it should not be used in calculations.

Then the calculation would be:

`SELECT CASE WHEN EXISTS (SELECT 1 FROM test WHERE <condition> AND datasign = 0) THEN 0 ELSE (SELECT 1-2*(SUM(datasign=-1)%2) FROM test WHERE <condition>) END AS resultsign, CASE WHEN EXISTS (SELECT 1 FROM test WHERE <condition> AND datasign = 0) THEN -1 -- undefined log for result 0 ELSE (SELECT SUM(datalog) FROM test WHERE <condition> AND datasign <> 0) END AS resultlog ;`

This way, you have no overflow problems. You can check the `resultlog`

if it exceeds some limits or just try to calculate `resultdata = resultsign * EXP(resultlog)`

and see if an error is thrown.

This question is a remarkable one in the sea of low quality ones. Thank you, even reading it was a pleasure.

**Precision**

The `exp(log(a)+log(b))`

idea is a good one in itself. However, after reading **"What Every Computer Scientist Should Know About Floating-Point Arithmetic"**, make sure you use ** DECIMAL or NUMERIC** data types to be sure you are using Precision Math, or else your values will be surprisingly inaccurate. For a couple of million rows, errors can add up very quickly!

`DECIMAL`

(as per the MySQL doc) has a maximum of 65 digits precision, while for example 64bit IEEE754 floating point values have only up to 16 digits (log10(2^52) = 15.65) precision!**Overflow**

As per the relevant part of the MySQL doc:

Integeroverflow results in silent wraparound.DECIMALoverflow results in a truncated result and a warning.Floating-pointoverflow produces a NULL result. Overflow for some operations can result in +INF, -INF, or NaN.

So you can detect floating point overflow if it would ever happen.

Sadly, if a series of operations would result in a correct value, fitting into the data type used, but at least one subresult in the process of calculations would not, then you won't get the correct value at the end.

**Performance**

Premature optimization is the root of all evil. Try it, and if it is slow, take the appropriate actions. Doing this might not be lightning quick, but still might be quicker than getting all the results, and doing it on the application server. Only measurements can decide which gets to be quicker...