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 <sjoerd@monetdb.org> wrote:
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