MySQL SELECT Precision of calculation (digits after decimal point)How MySQL does the math calculation of floating point addition?Limiting floats to two decimal pointsMySQL - UPDATE query based on SELECT QueryMySQL can't handle large values even with DECIMALDOUBLE vs DECIMAL in MySQLhandling decimal precision in Mysql or PHPmysql decimal and tinyint multiplication precisionFloating point precision for currency: using “round” function in MySQL query vs PHP vs JavascriptPrecision of reciprocal in floating point arithmeticsDecimal Precision when transferring Data between SQL Server and MySQLWhat MySQL “DECIMAL” precision and scale is required to store a C# decimal value?
As easy as Three, Two, One... How fast can you go from Five to Four?
Placement of positioning lights on A320 winglets
Why are ambiguous grammars bad?
How do I type a hyphen in iOS 12?
That's not my X, its Y is too Z
How to represent jealousy in a cute way?
Can I use 220 V outlets on a 15 ampere breaker and wire it up as 110 V?
What class is best to play when a level behind the rest of the party?
What did the 8086 (and 8088) do upon encountering an illegal instruction?
Lowest Magnitude Eigenvalues of Large Sparse Matrices
Why vspace-lineskip removes space after tikz picture although it stands before the picture?
Should I be able to use the Gloom Stalker ranger's Dread Ambusher class feature when attacking before initiative has been rolled to add a d8 damage?
Oil draining out shortly after turbo hose detached/broke
How many sets of dice do I need for D&D?
A life of PhD: is it feasible?
Realistic, logical way for men with medieval-era weaponry to compete with much larger and physically stronger foes
How does AFV select the winning videos?
What plausible reason could I give for my FTL drive only working in space
Is all-caps blackletter no longer taboo?
How to Handle Many Times Series Simultaneously?
If absolute velocity does not exist, how can we say a rocket accelerates in empty space?
Why do (or did, until very recently) aircraft transponders wait to be interrogated before broadcasting beacon signals?
Labels still showing when no Label Features turned on in ArcMap?
Professor Roman loves to teach unorthodox Chemistry
MySQL SELECT Precision of calculation (digits after decimal point)
How MySQL does the math calculation of floating point addition?Limiting floats to two decimal pointsMySQL - UPDATE query based on SELECT QueryMySQL can't handle large values even with DECIMALDOUBLE vs DECIMAL in MySQLhandling decimal precision in Mysql or PHPmysql decimal and tinyint multiplication precisionFloating point precision for currency: using “round” function in MySQL query vs PHP vs JavascriptPrecision of reciprocal in floating point arithmeticsDecimal Precision when transferring Data between SQL Server and MySQLWhat MySQL “DECIMAL” precision and scale is required to store a C# decimal value?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I'm trying to achieve the same amount of precision (number of digits after decimal point) for results coming from a SELECT that does some equations.
- Is there any difference in terms of performance, good practice of use in case of achieving wanted precision between CAST() or ROUND() besides rounding by the last one? Is there any better alternative?
For the sake of simplicity values in all examples below are hardcoded, they may or may not come from table's columns
I'm using MySQL 8.
If you run example E1
:
-- E1
SELECT (41/99);
-- 0.4141
you'll get 4 digits after decimal point.
Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:
-- E2
SELECT ROUND((41/99), 20);
-- 0.41414141400000000000-- or
SELECT CAST((41/99) AS DECIMAL(21,20));
-- 0.41414141400000000000How to get more decimal points precision from
E2
in case data used for calculation is int?
If you supply data with decimal point you get much higher precision:
-- E3
SELECT ROUND((41.0/99.0), 20);
-- 0.41414141414141414100
SELECT CAST((41.0/99.0) AS DECIMAL(21,20));
-- 0.41414141414141414100
It is important to me to avoid floating point datatypes due to their approximation of decimals. If the data be coming from table column the column will be decimal datatype. But data for calculations may be also hardcoded.
mysql select precision decimal-point
|
show 5 more comments
I'm trying to achieve the same amount of precision (number of digits after decimal point) for results coming from a SELECT that does some equations.
- Is there any difference in terms of performance, good practice of use in case of achieving wanted precision between CAST() or ROUND() besides rounding by the last one? Is there any better alternative?
For the sake of simplicity values in all examples below are hardcoded, they may or may not come from table's columns
I'm using MySQL 8.
If you run example E1
:
-- E1
SELECT (41/99);
-- 0.4141
you'll get 4 digits after decimal point.
Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:
-- E2
SELECT ROUND((41/99), 20);
-- 0.41414141400000000000-- or
SELECT CAST((41/99) AS DECIMAL(21,20));
-- 0.41414141400000000000How to get more decimal points precision from
E2
in case data used for calculation is int?
If you supply data with decimal point you get much higher precision:
-- E3
SELECT ROUND((41.0/99.0), 20);
-- 0.41414141414141414100
SELECT CAST((41.0/99.0) AS DECIMAL(21,20));
-- 0.41414141414141414100
It is important to me to avoid floating point datatypes due to their approximation of decimals. If the data be coming from table column the column will be decimal datatype. But data for calculations may be also hardcoded.
mysql select precision decimal-point
1
Possible duplicate of How MySQL does the math calculation of floating point addition?
– Raymond Nijland
Mar 24 at 23:17
" Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:" No will have to need to use implicit datatypes in the tables or a implicit cast nin the select like the SQL standards define to get higher precision .. If there is i never came acros this higher precision setting in MySQL.
– Raymond Nijland
Mar 24 at 23:20
Also i believe thatSELECT (41/99)
should be0
by SQL standards but MySQL and MariaDB allowes this, in some database like PostgreSQL, SQL Server it will give0
soSELECT (41/99);
is not portable.
– Raymond Nijland
Mar 24 at 23:24
@Raymond Nijland the question isn't about floating point but about achieving fixed precision of decimals therefore it is not a duplicate.
– Jimmix
Mar 24 at 23:36
1
seams there is a MySQL setting i just found it for the first first div_precision_increment
– Raymond Nijland
Mar 25 at 0:11
|
show 5 more comments
I'm trying to achieve the same amount of precision (number of digits after decimal point) for results coming from a SELECT that does some equations.
- Is there any difference in terms of performance, good practice of use in case of achieving wanted precision between CAST() or ROUND() besides rounding by the last one? Is there any better alternative?
For the sake of simplicity values in all examples below are hardcoded, they may or may not come from table's columns
I'm using MySQL 8.
If you run example E1
:
-- E1
SELECT (41/99);
-- 0.4141
you'll get 4 digits after decimal point.
Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:
-- E2
SELECT ROUND((41/99), 20);
-- 0.41414141400000000000-- or
SELECT CAST((41/99) AS DECIMAL(21,20));
-- 0.41414141400000000000How to get more decimal points precision from
E2
in case data used for calculation is int?
If you supply data with decimal point you get much higher precision:
-- E3
SELECT ROUND((41.0/99.0), 20);
-- 0.41414141414141414100
SELECT CAST((41.0/99.0) AS DECIMAL(21,20));
-- 0.41414141414141414100
It is important to me to avoid floating point datatypes due to their approximation of decimals. If the data be coming from table column the column will be decimal datatype. But data for calculations may be also hardcoded.
mysql select precision decimal-point
I'm trying to achieve the same amount of precision (number of digits after decimal point) for results coming from a SELECT that does some equations.
- Is there any difference in terms of performance, good practice of use in case of achieving wanted precision between CAST() or ROUND() besides rounding by the last one? Is there any better alternative?
For the sake of simplicity values in all examples below are hardcoded, they may or may not come from table's columns
I'm using MySQL 8.
If you run example E1
:
-- E1
SELECT (41/99);
-- 0.4141
you'll get 4 digits after decimal point.
Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:
-- E2
SELECT ROUND((41/99), 20);
-- 0.41414141400000000000-- or
SELECT CAST((41/99) AS DECIMAL(21,20));
-- 0.41414141400000000000How to get more decimal points precision from
E2
in case data used for calculation is int?
If you supply data with decimal point you get much higher precision:
-- E3
SELECT ROUND((41.0/99.0), 20);
-- 0.41414141414141414100
SELECT CAST((41.0/99.0) AS DECIMAL(21,20));
-- 0.41414141414141414100
It is important to me to avoid floating point datatypes due to their approximation of decimals. If the data be coming from table column the column will be decimal datatype. But data for calculations may be also hardcoded.
mysql select precision decimal-point
mysql select precision decimal-point
edited Mar 25 at 0:23
user207421
266k26219373
266k26219373
asked Mar 24 at 23:12
JimmixJimmix
1,020818
1,020818
1
Possible duplicate of How MySQL does the math calculation of floating point addition?
– Raymond Nijland
Mar 24 at 23:17
" Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:" No will have to need to use implicit datatypes in the tables or a implicit cast nin the select like the SQL standards define to get higher precision .. If there is i never came acros this higher precision setting in MySQL.
– Raymond Nijland
Mar 24 at 23:20
Also i believe thatSELECT (41/99)
should be0
by SQL standards but MySQL and MariaDB allowes this, in some database like PostgreSQL, SQL Server it will give0
soSELECT (41/99);
is not portable.
– Raymond Nijland
Mar 24 at 23:24
@Raymond Nijland the question isn't about floating point but about achieving fixed precision of decimals therefore it is not a duplicate.
– Jimmix
Mar 24 at 23:36
1
seams there is a MySQL setting i just found it for the first first div_precision_increment
– Raymond Nijland
Mar 25 at 0:11
|
show 5 more comments
1
Possible duplicate of How MySQL does the math calculation of floating point addition?
– Raymond Nijland
Mar 24 at 23:17
" Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:" No will have to need to use implicit datatypes in the tables or a implicit cast nin the select like the SQL standards define to get higher precision .. If there is i never came acros this higher precision setting in MySQL.
– Raymond Nijland
Mar 24 at 23:20
Also i believe thatSELECT (41/99)
should be0
by SQL standards but MySQL and MariaDB allowes this, in some database like PostgreSQL, SQL Server it will give0
soSELECT (41/99);
is not portable.
– Raymond Nijland
Mar 24 at 23:24
@Raymond Nijland the question isn't about floating point but about achieving fixed precision of decimals therefore it is not a duplicate.
– Jimmix
Mar 24 at 23:36
1
seams there is a MySQL setting i just found it for the first first div_precision_increment
– Raymond Nijland
Mar 25 at 0:11
1
1
Possible duplicate of How MySQL does the math calculation of floating point addition?
– Raymond Nijland
Mar 24 at 23:17
Possible duplicate of How MySQL does the math calculation of floating point addition?
– Raymond Nijland
Mar 24 at 23:17
" Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:" No will have to need to use implicit datatypes in the tables or a implicit cast nin the select like the SQL standards define to get higher precision .. If there is i never came acros this higher precision setting in MySQL.
– Raymond Nijland
Mar 24 at 23:20
" Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:" No will have to need to use implicit datatypes in the tables or a implicit cast nin the select like the SQL standards define to get higher precision .. If there is i never came acros this higher precision setting in MySQL.
– Raymond Nijland
Mar 24 at 23:20
Also i believe that
SELECT (41/99)
should be 0
by SQL standards but MySQL and MariaDB allowes this, in some database like PostgreSQL, SQL Server it will give 0
so SELECT (41/99);
is not portable.– Raymond Nijland
Mar 24 at 23:24
Also i believe that
SELECT (41/99)
should be 0
by SQL standards but MySQL and MariaDB allowes this, in some database like PostgreSQL, SQL Server it will give 0
so SELECT (41/99);
is not portable.– Raymond Nijland
Mar 24 at 23:24
@Raymond Nijland the question isn't about floating point but about achieving fixed precision of decimals therefore it is not a duplicate.
– Jimmix
Mar 24 at 23:36
@Raymond Nijland the question isn't about floating point but about achieving fixed precision of decimals therefore it is not a duplicate.
– Jimmix
Mar 24 at 23:36
1
1
seams there is a MySQL setting i just found it for the first first div_precision_increment
– Raymond Nijland
Mar 25 at 0:11
seams there is a MySQL setting i just found it for the first first div_precision_increment
– Raymond Nijland
Mar 25 at 0:11
|
show 5 more comments
1 Answer
1
active
oldest
votes
MySQL uses 64-bit IEEE-754 floating point (aka DOUBLE
) for its internal computations unless you specifically get it to use integer or decimal arithmetic by casting your constants.
When displaying numbers it does its best to render them in decimal as accurately as possible. With DOUBLE
, that requires a conversion to decimal. If you don't want the default rendering accuracy, but rather want to control it yourself, you may use the ROUND()
or TRUNCATE()
functions. That's how you control it.
There's not much performance penalty for using these functions. Many programmers who use plain SQL (rather than SQL retrieved by an application program in Java, PHP, or another language) always use one of the functions to retain control over the rendering.
Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE. Or, better yet, use a strongly typed language to gain precise control over your arithmetic.
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.
– O. Jones
Mar 25 at 0:32
By the way i found something else if MySQL would useIEEE-754 floating point (aka DOUBLE)
internal whySELECT (0.1 + 0.3) = 0.4
results in1
it should result in0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible
– Raymond Nijland
Mar 25 at 0:33
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55329477%2fmysql-select-precision-of-calculation-digits-after-decimal-point%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
MySQL uses 64-bit IEEE-754 floating point (aka DOUBLE
) for its internal computations unless you specifically get it to use integer or decimal arithmetic by casting your constants.
When displaying numbers it does its best to render them in decimal as accurately as possible. With DOUBLE
, that requires a conversion to decimal. If you don't want the default rendering accuracy, but rather want to control it yourself, you may use the ROUND()
or TRUNCATE()
functions. That's how you control it.
There's not much performance penalty for using these functions. Many programmers who use plain SQL (rather than SQL retrieved by an application program in Java, PHP, or another language) always use one of the functions to retain control over the rendering.
Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE. Or, better yet, use a strongly typed language to gain precise control over your arithmetic.
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.
– O. Jones
Mar 25 at 0:32
By the way i found something else if MySQL would useIEEE-754 floating point (aka DOUBLE)
internal whySELECT (0.1 + 0.3) = 0.4
results in1
it should result in0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible
– Raymond Nijland
Mar 25 at 0:33
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
add a comment |
MySQL uses 64-bit IEEE-754 floating point (aka DOUBLE
) for its internal computations unless you specifically get it to use integer or decimal arithmetic by casting your constants.
When displaying numbers it does its best to render them in decimal as accurately as possible. With DOUBLE
, that requires a conversion to decimal. If you don't want the default rendering accuracy, but rather want to control it yourself, you may use the ROUND()
or TRUNCATE()
functions. That's how you control it.
There's not much performance penalty for using these functions. Many programmers who use plain SQL (rather than SQL retrieved by an application program in Java, PHP, or another language) always use one of the functions to retain control over the rendering.
Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE. Or, better yet, use a strongly typed language to gain precise control over your arithmetic.
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.
– O. Jones
Mar 25 at 0:32
By the way i found something else if MySQL would useIEEE-754 floating point (aka DOUBLE)
internal whySELECT (0.1 + 0.3) = 0.4
results in1
it should result in0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible
– Raymond Nijland
Mar 25 at 0:33
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
add a comment |
MySQL uses 64-bit IEEE-754 floating point (aka DOUBLE
) for its internal computations unless you specifically get it to use integer or decimal arithmetic by casting your constants.
When displaying numbers it does its best to render them in decimal as accurately as possible. With DOUBLE
, that requires a conversion to decimal. If you don't want the default rendering accuracy, but rather want to control it yourself, you may use the ROUND()
or TRUNCATE()
functions. That's how you control it.
There's not much performance penalty for using these functions. Many programmers who use plain SQL (rather than SQL retrieved by an application program in Java, PHP, or another language) always use one of the functions to retain control over the rendering.
Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE. Or, better yet, use a strongly typed language to gain precise control over your arithmetic.
MySQL uses 64-bit IEEE-754 floating point (aka DOUBLE
) for its internal computations unless you specifically get it to use integer or decimal arithmetic by casting your constants.
When displaying numbers it does its best to render them in decimal as accurately as possible. With DOUBLE
, that requires a conversion to decimal. If you don't want the default rendering accuracy, but rather want to control it yourself, you may use the ROUND()
or TRUNCATE()
functions. That's how you control it.
There's not much performance penalty for using these functions. Many programmers who use plain SQL (rather than SQL retrieved by an application program in Java, PHP, or another language) always use one of the functions to retain control over the rendering.
Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE. Or, better yet, use a strongly typed language to gain precise control over your arithmetic.
answered Mar 24 at 23:56
O. JonesO. Jones
61.6k977116
61.6k977116
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.
– O. Jones
Mar 25 at 0:32
By the way i found something else if MySQL would useIEEE-754 floating point (aka DOUBLE)
internal whySELECT (0.1 + 0.3) = 0.4
results in1
it should result in0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible
– Raymond Nijland
Mar 25 at 0:33
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
add a comment |
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.
– O. Jones
Mar 25 at 0:32
By the way i found something else if MySQL would useIEEE-754 floating point (aka DOUBLE)
internal whySELECT (0.1 + 0.3) = 0.4
results in1
it should result in0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible
– Raymond Nijland
Mar 25 at 0:33
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
you've scared me: "Test carefully if you're depending on DECIMAL-data-type accuracy in computations: MySQL really wants to do them in DOUBLE". But if I use CAST with AS DECIMAL everywhere in SELECT where I operate at data and everywhere before INSERT I am covered and no surprise should happen or not?
– Jimmix
Mar 25 at 0:13
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like
10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.– O. Jones
Mar 25 at 0:32
With respect, I intended to scare you. Be very careful with this arithmetic-in-SQL application. You may be OK. But you should test cases like
10000000000000 + 1
to convince yourself you are not losing precision. If precision is mission-critical you really should do this stuff in a strongly typed language.– O. Jones
Mar 25 at 0:32
By the way i found something else if MySQL would use
IEEE-754 floating point (aka DOUBLE)
internal why SELECT (0.1 + 0.3) = 0.4
results in 1
it should result in 0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible– Raymond Nijland
Mar 25 at 0:33
By the way i found something else if MySQL would use
IEEE-754 floating point (aka DOUBLE)
internal why SELECT (0.1 + 0.3) = 0.4
results in 1
it should result in 0
if MySQL would? MySQL seams to be defaulting to Precision Math (a.k.a DECIMAL-data-type accuracy) where possible– Raymond Nijland
Mar 25 at 0:33
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
It seems to me CAST() everywhere + div_precision_increment as a fail over + lack of trust to numbers as the right approach. Need to check my pocket calc batteries to be prepared.
– Jimmix
Mar 25 at 0:42
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55329477%2fmysql-select-precision-of-calculation-digits-after-decimal-point%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Possible duplicate of How MySQL does the math calculation of floating point addition?
– Raymond Nijland
Mar 24 at 23:17
" Is there any MySQL setting that can bring higher precision right out of the box so I don't need to use:" No will have to need to use implicit datatypes in the tables or a implicit cast nin the select like the SQL standards define to get higher precision .. If there is i never came acros this higher precision setting in MySQL.
– Raymond Nijland
Mar 24 at 23:20
Also i believe that
SELECT (41/99)
should be0
by SQL standards but MySQL and MariaDB allowes this, in some database like PostgreSQL, SQL Server it will give0
soSELECT (41/99);
is not portable.– Raymond Nijland
Mar 24 at 23:24
@Raymond Nijland the question isn't about floating point but about achieving fixed precision of decimals therefore it is not a duplicate.
– Jimmix
Mar 24 at 23:36
1
seams there is a MySQL setting i just found it for the first first div_precision_increment
– Raymond Nijland
Mar 25 at 0:11