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;








0















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.



  1. 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.




  1. 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.41414141400000000000



  2. How 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.










share|improve this question



















  • 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 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






  • 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

















0















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.



  1. 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.




  1. 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.41414141400000000000



  2. How 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.










share|improve this question



















  • 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 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






  • 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













0












0








0








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.



  1. 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.




  1. 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.41414141400000000000



  2. How 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.










share|improve this question
















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.



  1. 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.




  1. 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.41414141400000000000



  2. How 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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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






  • 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





    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 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






  • 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












1 Answer
1






active

oldest

votes


















2














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.






share|improve this answer























  • 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












  • 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











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
);



);













draft saved

draft discarded


















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









2














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.






share|improve this answer























  • 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












  • 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















2














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.






share|improve this answer























  • 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












  • 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













2












2








2







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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 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












  • 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











  • 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












  • 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



















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현