QGIS » QGIS Application

If both numbers in division are integers, then integer division is used. If any of those numbers is a floating point number (e.g. 2.0/4 or 2/4.0) then real division is used. The same semantics is can be found in PostgreSQL and Sqlite3 (and in python2.x)

For the record, mysql (and Python3.x) always use real division.

Do you think it should stay like that?
Things like this should at least be made really obvious to the user...

I am fine with the current behavior.
What do you suggest to make it more obvious to the user?

Say the help for this (not currently implemented in Nathan's expression builder) is "a/b : a divided by b", change it to this:

"a/b : a divided by b.
If both numbers are integers, integer division is used, e.g. 1/2=0, but 1/2.0=0.5"

And because people might not look at the help for an operator as simple as /, also create a section in the user manual which lists issues like this where the expression parser behaves differently from what people would expect (unless they have used some other particular software). Even this probably isn't enough.

I don't have QGIS here to test, but I'm wondering:
- what happens if you divide two fields with precision 0 by each other? Do you need to do field_1*1.0/field_2 if you don't want integer division?
- if the precision of a field is greater than 0, but the field value is a round number, does the expression parser treat it as a real number or an integer?
- what is the point in integer division? Is it a lot faster? Wouldn't it be a lot more user friendly to always do real division, and if someone wants to round the answer then they can build that into the expression?

Alister Hood wrote:

I don't have QGIS here to test, but I'm wondering:
- what happens if you divide two fields with precision 0 by each other? Do you need to do field_1*1.0/field_2 if you don't want integer division?

Yes, you do.

- if the precision of a field is greater than 0, but the field value is a round number, does the expression parser treat it as a real number or an integer?

As a real number, thankfully.

If I do this the results are shown with many decimal places, regardless of the precision of the output field!^:
$x

^ However, when the layer is saved the results are rounded to the correct precision. N.B. this is the same as #3606

Except it isn't rounded to the correct precision when saved if it is a memory layer.

Alister Hood wrote:

I don't have QGIS here to test, but I'm wondering:
- what happens if you divide two fields with precision 0 by each other? Do you need to do field_1*1.0/field_2 if you don't want integer division?

Or use type conversions: toreal(field_1)/field_2

- if the precision of a field is greater than 0, but the field value is a round number, does the expression parser treat it as a real number or an integer?

Yes. Look into vector layer properties dialog to find out about types of each field.

- what is the point in integer division? Is it a lot faster? Wouldn't it be a lot more user friendly to always do real division, and if someone wants to round the answer then they can build that into the expression?

Nothing related to performance. The point is to have a choice - someone wants real division, someone wants integer division.

Hello, my first QGIS post. May I add my thoughts? I was confused by this situation as well. Spent several hours trying to debug it until I came across this report.

I created a real field with precision = 2. Using the field calculator, I populated this new field by dividing two integer fields (e.g. integer_a / integer_b). I expected real numbers, but the result was either a zero or 1. I assumed that the zero/1 result was a bug/error because the output field was formatted as real.

It sure seems to me that if the output field type is real, then real division ought to be used regardless of the input type. If a user creates a real field, they're expecting "real" results. The integer_a * 1.0 / integer_b * 1.0 workaround is cumbersome and unintuitive.

Thanks!

Nothing related to performance. The point is to have a choice - someone wants real division, someone wants integer division.

I really think that the vast majority if users do expect to have always the real division.

And I just checked also other gis sw, and the real division is always used.

my suggestion would be to change the behavior instead of documenting it, is cumbersome for any common user.