Обсуждение: simple division

I have asked this question before and apologize for not remembering it.  How do you do simple division in postgres and get 10/4 with decimals?

 

This involves cast and numeric in odd ways that are not well explained in the documentation. For instance, you’d expect an example in the Mathematical Functions. But there isn’t.

 

The documentation of string functions is exemplary. The documentation of mathematical less so. Remember that it may be used by folks like me whose math is shaky. The MySQL documentation is better on this simple operation.

I may be misunderstanding the question but:

select cast(x/y as numeric(10,4));

JD

 

 

-----

Martin Mueller
Professor emeritus of English and Classics

Northwestern University

 

 

-- 
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development. 
Advocate: @amplifypostgres || Learn: https://postgresconf.org
*****     Unless otherwise stated, opinions are my own.   *****

Martin Mueller schrieb am 04.12.2018 um 21:29:
> I have asked this question before and apologize for not remembering
> it.  How do you do simple division in postgres and get 10/4 with
> decimals?

In the expression 10/4 both numbers are integers.
And an integer divsion does not yield decimals (that's the same as in every strongly typed programming language).

I am not entirely sure what the SQL standard says about such an expression, but e.g. SQL Server, SQLite, Firebird and
DB2behave the same as Postgres.
 
That is they apply integer division if all values are integers, and decimal division if at least one value is a
decimal.

To get a division of decimals you need to specify at least one value as a decimal,

e.g. "select 10.0/4" or "select 10/4.0" whatever you prefer.

On Tue, Dec 4, 2018 at 1:29 PM Martin Mueller
<martinmueller@northwestern.edu> wrote:
> I have asked this question before and apologize for not remembering it.  How do you do simple division in postgres
andget 10/4 with decimals? 
> This involves cast and numeric in odd ways that are not well explained in the documentation. For instance, you’d
expectan example in the Mathematical Functions. But there isn’t. 

select 10/4, 10.0/4, 10/4.0, 10.0/4.0;

The first one returns 2, the rest of them 2.5 - from which one can
infer that if both inputs are integer (type) the output is integer
(type) - if at least one input is non-integer (type) the output will
be as well.

If you want to cast...select 10/(4::numeric)...

David J.

On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake <jd@commandprompt.com> wrote:
> I may be misunderstanding the question but:
Indeed...
> select cast(x/y as numeric(10,4));

Your answer is 2.0 instead of the correct 2.5 - you need to cast
before the division, not after.

David J.

I didn't formulate my question properly, because the query went like
 "select alldefects /wordcount" 
where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to
work.
 

The Postgres notation of this simple procedure is very unintuitive. I haven't been able to remember several times, and
mostpeople think of me as a person with a reasonably good memory. There is no obvious place in the documentation to
lookthis up.
 


On 12/4/18, 2:45 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:

    On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake <jd@commandprompt.com> wrote:
    > I may be misunderstanding the question but:
    Indeed...
    > select cast(x/y as numeric(10,4));
    
    Your answer is 2.0 instead of the correct 2.5 - you need to cast
    before the division, not after.
    
    David J.
    

On Tue, Dec 4, 2018 at 1:57 PM Martin Mueller
<martinmueller@northwestern.edu> wrote:
>
> I didn't formulate my question properly, because the query went like
>  "select alldefects /wordcount"
> where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to
work.

IDK...the first thing that came to mind was to just stick it at the
end of the expression:

select x/y::numeric from (values (10,4)) vals (x,y)

And it worked...

If you want to propose a concrete documentation patch more power to
you but this doesn't come up enough to think that what we have is
materially deficient.  I'm sorry you are having trouble with it but
the lists do provide quick and customized answers for situations like
this.

David J.

Use CAST() instead of ::.

SELECT CAST(alldefects AS NUMEREIC(10,4))/wordcount;

On 12/04/2018 02:57 PM, Martin Mueller wrote:
> I didn't formulate my question properly, because the query went like
>   "select alldefects /wordcount"
> where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to
work.
>
> The Postgres notation of this simple procedure is very unintuitive. I haven't been able to remember several times,
andmost people think of me as a person with a reasonably good memory. There is no obvious place in the documentation to
lookthis up.
 
>
>
> On 12/4/18, 2:45 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:
>
>      On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake <jd@commandprompt.com> wrote:
>      > I may be misunderstanding the question but:
>      Indeed...
>      > select cast(x/y as numeric(10,4));
>      
>      Your answer is 2.0 instead of the correct 2.5 - you need to cast
>      before the division, not after.
>      
>      David J.
>      
>

-- 
Angular momentum makes the world go 'round.

Am 04.12.18 21:57 schrieb(en) Martin Mueller:
> I didn't formulate my question properly, because the query went like
>  "select alldefects /wordcount"
> where alldefects and wordcount are integers.

test=# create table xxx(alldefects bigint, wordcount bigint);
CREATE TABLE
test=# insert into xxx values (4, 10);
INSERT 0 1
test=# insert into xxx values (3, 17);
INSERT 0 1
test=# select alldefects::real / wordcount::real from xxx;
  ?column?
----------
       0.4
  0.176471
(2 rows)

Hth,
Albrecht.

It worked, and I must have done something wrong. I'm probably not the only person who would find something like the
followinghelpful:
 


division (integer division truncates the result)    10/3    3
division (with decimal results)    10/3::numeric    3.3333
division (rounded)    round(10/3::numeric, 2)    3.33

From an end user's the question "how do I divide two integers and limit the number of decimals" is surely a common one.
And if you look it up somewhere, division is probably the search word.  Now you could argue that the user should
alreadyknow about formatting and rounding.  But some don't.
 

If you wanted to look up a rare wordform in a famous early 20th century dictionary of Old English, you had to know the
rootform of the word. If you already knew the root form, there is a good chance that you didn't need to look it up in
thefirst place. If you didn't know the root form, the dictionary was no use. 
 

In this, single stop shopping for the three most common problems of simple division makes life easier for users.







On 12/4/18, 3:06 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:

    On Tue, Dec 4, 2018 at 1:57 PM Martin Mueller
    <martinmueller@northwestern.edu> wrote:
    >
    > I didn't formulate my question properly, because the query went like
    >  "select alldefects /wordcount"
    > where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed
towork.
 
    
    IDK...the first thing that came to mind was to just stick it at the
    end of the expression:
    
    select x/y::numeric from (values (10,4)) vals (x,y)
    
    And it worked...
    
    If you want to propose a concrete documentation patch more power to
    you but this doesn't come up enough to think that what we have is
    materially deficient.  I'm sorry you are having trouble with it but
    the lists do provide quick and customized answers for situations like
    this.
    
    David J.
    

Martin Mueller schrieb am 04.12.2018 um 21:57:
> I didn't formulate my question properly, because the query went like
>   "select alldefects /wordcount"
> where alldefects and wordcount are integers.   
> But none of the different ways of putting the double colon seemed to
> work.
One way is to make one of the integers a decimal by multiplying with 1.0

    select alldefects * 1.0 / wordcount

> The Postgres notation of this simple procedure is very unintuitive. I
> haven't been able to remember several times, and most people think of
> me as a person with a reasonably good memory.

Postgres supports the SQL standard's CAST operator:

    select cast(alldefects as decimal) / wordcount

The "Postgres way" would be:

    select alldefects::decimal / wordcount

> There is no obvious place in the documentation to look this up.

This is covered in the chapter "Type Casts"

https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-TYPE-CASTS

On 12/4/18 2:36 PM, Martin Mueller wrote:
> It worked, and I must have done something wrong. I'm probably not the only person who would find something like the
followinghelpful:
 
>
>
> division (integer division truncates the result)    10/3    3

The math types might take offense here, with the use of "truncates".  
Integer division really ask how many times can one subtract the 
numerator from the denominator without going negative (or how many times 
does the numerator "go into" the denominator).

It may seem a nuisance, but int division is a useful construct and must 
be supported (and be the default). (If you have 10 people to transport 
in cars which hold four (all can drive) 10/4 = 3 ;) )

On 05/12/2018 10:51, Rob Sargent wrote:
>
> On 12/4/18 2:36 PM, Martin Mueller wrote:
>> It worked, and I must have done something wrong. I'm probably not the 
>> only person who would find something like the following helpful:
>>
>>
>> division (integer division truncates the result)    10/3    3
>
> The math types might take offense here, with the use of "truncates".  
> Integer division really ask how many times can one subtract the 
> numerator from the denominator without going negative (or how many 
> times does the numerator "go into" the denominator).
>
> It may seem a nuisance, but int division is a useful construct and 
> must be supported (and be the default). (If you have 10 people to 
> transport in cars which hold four (all can drive) 10/4 = 3 ;) )
>
>
>
>
Hmm...

10 / 4 = 2

> On Dec 4, 2018, at 9:33 PM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>
>> On 05/12/2018 10:51, Rob Sargent wrote:
>>
>>> On 12/4/18 2:36 PM, Martin Mueller wrote:
>>> It worked, and I must have done something wrong. I'm probably not the only person who would find something like the
followinghelpful: 
>>>
>>>
>>> division (integer division truncates the result)    10/3    3
>>
>> The math types might take offense here, with the use of "truncates".  Integer division really ask how many times can
onesubtract the numerator from the denominator without going negative (or how many times does the numerator "go into"
thedenominator). 
>>
>> It may seem a nuisance, but int division is a useful construct and must be supported (and be the default). (If you
have10 people to transport in cars which hold four (all can drive) 10/4 = 3 ;) ) 
>>
>>
>>
>>
> Hmm...
>
> 10 / 4 = 2
>
And two are left stranded!
 The point is that integer math has its place. You cant have 2.5 cars. So 10/4 in this context is 3.
More correctly the calculation is
10/4 + 10%4>0 ? 1 :0 = 3

(Maybe psql does have % so mod(10,4))

On 05/12/2018 20:07, Rob Sargent wrote:
>
>> On Dec 4, 2018, at 9:33 PM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>>
>>> On 05/12/2018 10:51, Rob Sargent wrote:
>>>
>>>> On 12/4/18 2:36 PM, Martin Mueller wrote:
>>>> It worked, and I must have done something wrong. I'm probably not the only person who would find something like
thefollowing helpful:
 
>>>>
>>>>
>>>> division (integer division truncates the result)    10/3    3
>>> The math types might take offense here, with the use of "truncates".  Integer division really ask how many times
canone subtract the numerator from the denominator without going negative (or how many times does the numerator "go
into"the denominator).
 
>>>
>>> It may seem a nuisance, but int division is a useful construct and must be supported (and be the default). (If you
have10 people to transport in cars which hold four (all can drive) 10/4 = 3 ;) )
 
>>>
>>>
>>>
>>>
>> Hmm...
>>
>> 10 / 4 = 2
>>
> And two are left stranded!
>   The point is that integer math has its place. You cant have 2.5 cars. So 10/4 in this context is 3.
> More correctly the calculation is
> 10/4 + 10%4>0 ? 1 :0 = 3
>
> (Maybe psql does have % so mod(10,4))
>
>
SELECT ceil(10/4.0);

Is what you want for that example.

On Wed, 5 Dec 2018 at 09:13, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
> SELECT ceil(10/4.0);
>
> Is what you want for that example.

Except that implies that "number of people who can fit in a car" is a
real number, not a whole.

IMO it's fundamentally broken that SQL doesn't cast the result of a
divide into a numeric value - the potential for unexpected errors
creeping into calculations is huge; however that's the standard and
no-one's going to change it now.

Having said that it's worth noting that those in the Other Place think
that it's broken enough to go against the standard (they have a DIV b
for integer divide and a/b for float).

Geoff

On 06/12/2018 00:05, Geoff Winkless wrote:
> On Wed, 5 Dec 2018 at 09:13, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>> SELECT ceil(10/4.0);
>>
>> Is what you want for that example.
> Except that implies that "number of people who can fit in a car" is a
> real number, not a whole.
>
> IMO it's fundamentally broken that SQL doesn't cast the result of a
> divide into a numeric value - the potential for unexpected errors
> creeping into calculations is huge; however that's the standard and
> no-one's going to change it now.
>
> Having said that it's worth noting that those in the Other Place think
> that it's broken enough to go against the standard (they have a DIV b
> for integer divide and a/b for float).
>
> Geoff
>
If you divide one integer by another, then it is logical to get an 
integer as as the answer.

On Wed, 5 Dec 2018 at 12:45, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
> If you divide one integer by another, then it is logical to get an
> integer as as the answer.

Hmm. It might fit with what a computer scientist might expect (or
rather, not be surprised about), but I don't think you can say that
it's "logical".

Where's the logical progression in step 3 here:

1 You asked the computer a question

2 The values you passed to it don't have decimal points

...

4 Ergo, you wanted an answer that was incorrect.

Geoff

On 12/5/18 4:45 AM, Gavin Flower wrote:
> On 06/12/2018 00:05, Geoff Winkless wrote:
>> On Wed, 5 Dec 2018 at 09:13, Gavin Flower 
>> <GavinFlower@archidevsys.co.nz> wrote:
>>> SELECT ceil(10/4.0);

>> Geoff
>>
> If you divide one integer by another, then it is logical to get an 
> integer as as the answer.

Hmm, grab any of my calculators and divide 10/4 and get 2.5. Seems not 
everybody agrees with that logic:)


-- 
Adrian Klaver
adrian.klaver@aklaver.com

Geoff Winkless <pgsqladmin@geoff.dj> writes:
> IMO it's fundamentally broken that SQL doesn't cast the result of a
> divide into a numeric value - the potential for unexpected errors
> creeping into calculations is huge; however that's the standard and
> no-one's going to change it now.
> Having said that it's worth noting that those in the Other Place think
> that it's broken enough to go against the standard (they have a DIV b
> for integer divide and a/b for float).

Well, this isn't really blame-able on the SQL standard; it's a
Postgres-ism.  What the spec says (in SQL99, 6.26 <numeric value
expression>) is

         1) If the declared type of both operands of a dyadic arithmetic
            operator is exact numeric, then the declared type of the
            result is exact numeric, with precision and scale determined
            as follows:

            a) Let S1 and S2 be the scale of the first and second operands
              respectively.

            b) The precision of the result of addition and subtraction is
              implementation-defined, and the scale is the maximum of S1
              and S2.

            c) The precision of the result of multiplication is
              implementation-defined, and the scale is S1 + S2.

            d) The precision and scale of the result of division is
              implementation-defined.

         2) If the declared type of either operand of a dyadic arithmetic
            operator is approximate numeric, then the declared type of the
            result is approximate numeric. The precision of the result is
            implementation-defined.

Postgres' integer types map onto the standard as exact numerics with
scale 0.  (The precision aspect is a bit squishy, since their maximum
values aren't powers of 10, but let's disregard that.)  Postgres'
integer division operator meets the spec with the stipulation that
the "implementation-defined" scale of the result is 0.  Other SQL
implementations can and do define that differently --- if they even
have an "integer" data type, which some do not.

Anyway, the bottom line here is that we're balancing surprise factor
for novices against twenty-plus years of backwards compatibility,
and the latter is going to win.

            regards, tom lane

I take the point that two decades of backward compatibility should and will win. That said,  it's an easy enough thing
toright the balance for novices and put in a really obvious place in the documentation what you should do if you want
todivide two integers and get the results with the number of decimals of your choice. I made one suggestion how this
couldbe done. A better way might be a short paragraph like
 

A note on division:  if you divide two constants or variables defined as integers, the default will be an integer. If
youwant the result with decimals, add "::numeric".  If you want to limit the decimals, use the round() function:
 
    Select 10/3:        3
    Select 10/3::numeric    3.33333
    Round(select 10/3::numeric, 3)        3.333
For more detail see the sections on ...





`
On 12/5/18, 9:23 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

    Geoff Winkless <pgsqladmin@geoff.dj> writes:
    > IMO it's fundamentally broken that SQL doesn't cast the result of a
    > divide into a numeric value - the potential for unexpected errors
    > creeping into calculations is huge; however that's the standard and
    > no-one's going to change it now.
    > Having said that it's worth noting that those in the Other Place think
    > that it's broken enough to go against the standard (they have a DIV b
    > for integer divide and a/b for float).
    
    Well, this isn't really blame-able on the SQL standard; it's a
    Postgres-ism.  What the spec says (in SQL99, 6.26 <numeric value
    expression>) is
    
             1) If the declared type of both operands of a dyadic arithmetic
                operator is exact numeric, then the declared type of the
                result is exact numeric, with precision and scale determined
                as follows:
    
                a) Let S1 and S2 be the scale of the first and second operands
                  respectively.
    
                b) The precision of the result of addition and subtraction is
                  implementation-defined, and the scale is the maximum of S1
                  and S2.
    
                c) The precision of the result of multiplication is
                  implementation-defined, and the scale is S1 + S2.
    
                d) The precision and scale of the result of division is
                  implementation-defined.
    
             2) If the declared type of either operand of a dyadic arithmetic
                operator is approximate numeric, then the declared type of the
                result is approximate numeric. The precision of the result is
                implementation-defined.
    
    Postgres' integer types map onto the standard as exact numerics with
    scale 0.  (The precision aspect is a bit squishy, since their maximum
    values aren't powers of 10, but let's disregard that.)  Postgres'
    integer division operator meets the spec with the stipulation that
    the "implementation-defined" scale of the result is 0.  Other SQL
    implementations can and do define that differently --- if they even
    have an "integer" data type, which some do not.
    
    Anyway, the bottom line here is that we're balancing surprise factor
    for novices against twenty-plus years of backwards compatibility,
    and the latter is going to win.
    
                regards, tom lane
    
    

On 06/12/2018 02:32, Adrian Klaver wrote:
> On 12/5/18 4:45 AM, Gavin Flower wrote:
>> On 06/12/2018 00:05, Geoff Winkless wrote:
>>> On Wed, 5 Dec 2018 at 09:13, Gavin Flower 
>>> <GavinFlower@archidevsys.co.nz> wrote:
>>>> SELECT ceil(10/4.0);
>
>>> Geoff
>>>
>> If you divide one integer by another, then it is logical to get an 
>> integer as as the answer.
>
> Hmm, grab any of my calculators and divide 10/4 and get 2.5. Seems not 
> everybody agrees with that logic:)
>
>
Calculators normally work in floating point (in fact, as far as I am 
aware, they never work in integer mode by default) , unless you are 
either doing symbolic maths or numbers that are integer based like 
hexadecimal.

So your example does not contrdict what I said.

On 2018-Dec-06, Gavin Flower wrote:

> Calculators normally work in floating point (in fact, as far as I am aware,
> they never work in integer mode by default),

The reason they don't work in "integer mode" is because it doesn't make
sense.

We only have this thing called "integer division" because it's a cheap
thing to implement in terms of machine instructions.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services