Aggregation on double column in different monetdb version
Hi, I am currently migrating monetdb from an old version to the current release, and I noticed that sum on double precision columns is returning a slightly different result between both versions. The only difference between the system is HugeInt enabled on the newer version. ex: To reproduce the mismatch (subset of values extracted from the table) SELECT sum(cast(c1 as double)) --, sum(c1) FROM (VALUES (218.5792349726776),(792.3497267759564),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(657.5342465753424),(4109.58904109589),(4234.972677595628),(3961.748633879781),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4098.360655737704),(273.224043715847),(219.1780821917808),(821.917808219178),(849.3150684931506),(846.9945355191256),(792.3497267759564),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(846.9945355191256),(819.6721311475409),(655.7377049180328),(249.3150684931507),(1104.109589041096),(1101.092896174863),(1030.054644808743),(1101.092896174863),(1065.573770491803),(1101.092896174863),(1065.573770491803),(1101.092896174863),(1101.092896174863),(1065.573770491803),(1101.092896174863),(852.4590163934427),(219.1780821917808),(1698.630136986301),(1643.835616438356),(1698.630136986301),(1693.989071038251),(1584.699453551912),(1693.989071038251),(1639.344262295081),(1693.989071038251),(1639.344262295081),(1693.989071038251),(1693.989071038251),(1475.409836065573),(60.27397260273972),(1868.493150684931),(1808.219178082191),(1868.493150684931),(1863.387978142076),(1743.169398907103),(1863.387978142076),(1803.27868852459),(1863.387978142076),(1803.27868852459),(1863.387978142076),(1863.387978142076),(1803.27868852459),(258.9041095890410),(381.1475409836065),(356.5573770491803),(381.1475409836065),(368.8524590163934),(381.1475409836065),(368.8524590163934),(381.1475409836065),(381.1475409836065),(368.8524590163934),(381.1475409836065),(368.8524590163934),(135.2459016393442),(542.4657534246575),(904.1095890410959),(934.2465753424657),(931.6939890710382),(871.5846994535519),(931.6939890710382),(901.639344262295),(931.6939890710382),(901.639344262295) ) t1 (c1) old-V11.27.11: 137756.87551463424 new-V11.43.15: 137756.8755146343 ExactValue: 137756.87551463430452 The aggregation over double columns should return the same result regardless of the engine versions, as the double precision type did not change, unless there was a bug reported and it was fixed. Any idea what could affect the result difference. Regards.
11.27.11 is too long ago to remember what changed. But I can tell you this: the value that you get in 11.43.15 is correct. It is the most precise value that you can get that fits in a double. A decimal has a bit more precision, so you get the extra decimal values. On 03/08/2022 18.01, imad hajj chahine wrote:
Hi,
I am currently migrating monetdb from an old version to the current release, and I noticed that sum on double precision columns is returning a slightly different result between both versions. The only difference between the system is HugeInt enabled on the newer version.
ex: To reproduce the mismatch (subset of values extracted from the table) SELECT sum(cast(c1 as double)) --, sum(c1) FROM (VALUES (218.5792349726776),(792.3497267759564),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(657.5342465753424),(4109.58904109589),(4234.972677595628),(3961.748633879781),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4098.360655737704),(273.224043715847),(219.1780821917808),(821.917808219178),(849.3150684931506),(846.9945355191256),(792.3497267759564),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(846.9945355191256),(819.6721311475409),(655.7377049180328),(249.3150684931507),(1104.109589041096),(1101.092896174863),(1030.054644808743),(1101.092896174863),(1065.573770491803),(1101.092896174863),(1065.573770491803),(1101.092896174863),(1101.092896174863),(1065.573770491803),(1101.092896174863),(852.4590163934427),(219.1780821917808),(1698.630136986301),(1643.835616438356),(1698.630136986301),(1693.989071038251),(1584.699453551912),(1693.989071038251),(1639.344262295081),(1693.989071038251),(1639.344262295081),(1693.989071038251),(1693.989071038251),(1475.409836065573),(60.27397260273972),(1868.493150684931),(1808.219178082191),(1868.493150684931),(1863.387978142076),(1743.169398907103),(1863.387978142076),(1803.27868852459),(1863.387978142076),(1803.27868852459),(1863.387978142076),(1863.387978142076),(1803.27868852459),(258.9041095890410),(381.1475409836065),(356.5573770491803),(381.1475409836065),(368.8524590163934),(381.1475409836065),(368.8524590163934),(381.1475409836065),(381.1475409836065),(368.8524590163934),(381.1475409836065),(368.8524590163934),(135.2459016393442),(542.4657534246575),(904.1095890410959),(934.2465753424657),(931.6939890710382),(871.5846994535519),(931.6939890710382),(901.639344262295),(931.6939890710382),(901.639344262295) ) t1 (c1) old-V11.27.11: 137756.87551463424 new-V11.43.15: 137756.8755146343 ExactValue: 137756.87551463430452
The aggregation over double columns should return the same result regardless of the engine versions, as the double precision type did not change, unless there was a bug reported and it was fixed.
Any idea what could affect the result difference.
Regards.
_______________________________________________ users-list mailing list -- users-list@monetdb.org To unsubscribe send an email to users-list-leave@monetdb.org
-- Sjoerd Mullender
Hi Sjoerd,
I agree with you that we still have a very old version in one of our
production installations, hence the effort to migrate to a newer release.
I don't want to compare double to decimal precision especially when hugeint
is enabled and decimal can have 38 precision,
but I expect if I use the same type having same precision, in my case
"double", I should get the same result as the "double" precision didn't not
change from 11.27.11 to 11.43.15.
result using double type
old-V11.27.11: 137756.87551463424
new-V11.43.15: 137756.8755146343
If it's a matter of precision I would expect a few digits less or more, not
a completely different result, (knowing that all the values are in a column
of type "double" not "decimal")
It's essential for me to understand the difference in result as I am doing
a reconciliation after the migration.
Appreciate your explanation of what could have changed causing an offset to
the result.
Thanks.
On Wed, Aug 3, 2022 at 7:49 PM Sjoerd Mullender
11.27.11 is too long ago to remember what changed. But I can tell you this: the value that you get in 11.43.15 is correct. It is the most precise value that you can get that fits in a double. A decimal has a bit more precision, so you get the extra decimal values.
On 03/08/2022 18.01, imad hajj chahine wrote:
Hi,
I am currently migrating monetdb from an old version to the current release, and I noticed that sum on double precision columns is returning a slightly different result between both versions. The only difference between the system is HugeInt enabled on the newer version.
ex: To reproduce the mismatch (subset of values extracted from the table) SELECT sum(cast(c1 as double)) --, sum(c1) FROM (VALUES
(218.5792349726776),(792.3497267759564),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(657.5342465753424),(4109.58904109589),(4234.972677595628),(3961.748633879781),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4234.972677595628),(4098.360655737704),(4234.972677595628),(4098.360655737704),(273.224043715847),(219.1780821917808),(821.917808219178),(849.3150684931506),(846.9945355191256),(792.3497267759564),(846.9945355191256),(819.6721311475409),(846.9945355191256),(819.6721311475409),(846.9945355191256),(846.9945355191256),(819.6721311475409),(655.7377049180328),(249.3150684931507),(1104.109589041096),(1101.092896174863),(1030.054644808743),(1101.092896174863),(1065.573770491803),(1101.092896174863),(1065.573770491803),(1101.092896174863),(1101.092896174863),(1065.573770491803),(1101.092896174863),(852.4590163934427),(219.1780821917808),(1698.630136986301),(1643.835616438356),(1698.630136986301),(1693.989071038251),(1584.699453551912),(1693.989071038251),(1639.344262295081),(1693.989071038251),(1639.344262295081),(1693.989071038251),(1693.989071038251),(1475.409836065573),(60.27397260273972),(1868.493150684931),(1808.219178082191),(1868.493150684931),(1863.387978142076),(1743.169398907103),(1863.387978142076),(1803.27868852459),(1863.387978142076),(1803.27868852459),(1863.387978142076),(1863.387978142076),(1803.27868852459),(258.9041095890410),(381.1475409836065),(356.5573770491803),(381.1475409836065),(368.8524590163934),(381.1475409836065),(368.8524590163934),(381.1475409836065),(381.1475409836065),(368.8524590163934),(381.1475409836065),(368.8524590163934),(135.2459016393442),(542.4657534246575),(904.1095890410959),(934.2465753424657),(931.6939890710382),(871.5846994535519),(931.6939890710382),(901.639344262295),(931.6939890710382),(901.639344262295)
) t1 (c1) old-V11.27.11: 137756.87551463424 new-V11.43.15: 137756.8755146343 ExactValue: 137756.87551463430452
The aggregation over double columns should return the same result regardless of the engine versions, as the double precision type did not change, unless there was a bug reported and it was fixed.
Any idea what could affect the result difference.
Regards.
_______________________________________________ users-list mailing list -- users-list@monetdb.org To unsubscribe send an email to users-list-leave@monetdb.org
-- Sjoerd Mullender _______________________________________________ users-list mailing list -- users-list@monetdb.org To unsubscribe send an email to users-list-leave@monetdb.org
participants (2)
-
imad hajj chahine -
Sjoerd Mullender