Re: simple division
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: simple division
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 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.
Re: simple division
I take the point that two decades of backward compatibility should and will win. That said, it's an easy enough thing to right the balance for novices and put in a really obvious place in the documentation what you should do if you want to divide two integers and get the results with the number of decimals of your choice. I made one suggestion how this could be 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 you want the result with decimals, add "::numeric". If you want to limit the decimals, use the round() function: Select 10/3:3 Select 10/3::numeric3.3 Round(select 10/3::numeric, 3) 3.333 For more detail see the sections on ... ` On 12/5/18, 9:23 AM, "Tom Lane" wrote: Geoff Winkless 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 ) 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
Re: simple division
Geoff Winkless 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 ) 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
Re: simple division
On Wed, Dec 5, 2018 at 7:55 AM Geoff Winkless wrote: > 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. > Well put. However the nature of the question you asked does not necessarily allow for a correct finite answer. If I ask for 10/3, for instance, or 1/0. To play devil's advocate, then: you should have known that some of the answers would need to be truncated. This just truncates a little more aggressively. ;-) -- Ray Brinzer
Re: simple division
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 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.kla...@aklaver.com
Re: simple division
On Wed, 5 Dec 2018 at 12:45, Gavin Flower 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
Re: simple division
On 06/12/2018 00:05, Geoff Winkless wrote: On Wed, 5 Dec 2018 at 09:13, Gavin Flower 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.
Re: simple division
On Wed, 5 Dec 2018 at 09:13, Gavin Flower 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
Re: simple division
On 05/12/2018 20:07, Rob Sargent wrote: On Dec 4, 2018, at 9:33 PM, Gavin Flower 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 following helpful: division (integer division truncates the result)10/33 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 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.
Re: simple division
> On Dec 4, 2018, at 9:33 PM, Gavin Flower > 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 following helpful: >>> >>> >>> division (integer division truncates the result)10/33 >> >> 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 > 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))
Re: simple division
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
Re: simple division
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/33 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 ;) )
Re: simple division
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
Re: simple division
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/33 division (with decimal results) 10/3::numeric 3. 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 already know 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 root form 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 the first 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" wrote: On Tue, Dec 4, 2018 at 1: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. 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.
Re: simple division
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. pgpZHLz289mhC.pgp Description: PGP signature
Re: simple division
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, and most people think of me as a person with a reasonably good memory. There is no obvious place in the documentation to look this up. On 12/4/18, 2:45 PM, "David G. Johnston" wrote: On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake 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.
Re: simple division
On Tue, Dec 4, 2018 at 1: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. 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.
Re: simple division
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 most people think of me as a person with a reasonably good memory. There is no obvious place in the documentation to look this up. On 12/4/18, 2:45 PM, "David G. Johnston" wrote: On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake 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.
Re: simple division
On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake 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.
Re: simple division
On Tue, Dec 4, 2018 at 1:29 PM Martin Mueller wrote: > 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. 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.
Re: simple division
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 DB2 behave 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.
RE: simple division
From: Martin Mueller Sent: Tuesday, December 4, 2018 3:30 PM To: pgsql-general Subject: 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. - Martin Mueller Professor emeritus of English and Classics Northwestern University There is nothing odd about: select (12345678.1234/32.5678)::numeric(10,4); Regards, Igor Neyman
Re: simple division
On 12/4/18 12:29 PM, Martin Mueller wrote: 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. *
