Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tFbPP-00EDBd-TO for pgsql-sql@arkaria.postgresql.org; Mon, 25 Nov 2024 15:53:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tFbPO-00G1LZ-9j for pgsql-sql@arkaria.postgresql.org; Mon, 25 Nov 2024 15:53:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tFbPN-00G1LR-SP for pgsql-sql@lists.postgresql.org; Mon, 25 Nov 2024 15:53:54 +0000 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tFbPK-003nBb-QR for pgsql-sql@lists.postgresql.org; Mon, 25 Nov 2024 15:53:53 +0000 Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3e7e2e6ce0aso1738055b6e.0 for ; Mon, 25 Nov 2024 07:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heimdalldata.com; s=google; t=1732550029; x=1733154829; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zvcl3WRXGzyEONWaRVpOXLPiutpIigjaawM9WFsGSuU=; b=B4GnQSyIi/BvTaVj5c+nG61yE2fqngoA+2RX9OEC5gAX7h+o18x8QzoE7mONTweMOU SdtWiqZDYYKz77hjOU0iTymbBcpixnOnTmg8avbh90k11yoPdaMRS7XZ2Y+oK16W1+WV OrZOCPr/5k0beG+TG+Yz3mBN7qk0hvqJuvZto= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732550029; x=1733154829; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zvcl3WRXGzyEONWaRVpOXLPiutpIigjaawM9WFsGSuU=; b=tq6zYSdxqfIwuzsVjPHrauGlvsAm7EEvIooB42z5p17dYRz+z6YLYtj0RVKRXZZ1IZ Yhw9C54sD3+Cl+KU3J5Y/EtpSdrEKuh/fT6g1icWgH0Qc6hfft3yio4oku2TmtVnJhSR zsZRn7DYoUx7Z17ewh3trf2cpd+ghki3mDj9X9/tzFj+Lx9TD3Ln08lnP0QaDnGR9wWj 1/SBmyJmgPOgOnNJpvgErsuLKFQJJPB9qrZvk/ZJt+f+0cWzMjpG+v3z3X69z2njs42S HSUM8XuaXV3UM38r8y5LhGR2QEJ37tri+EYhcHkGLVWUqTrUsJxKJYHBqclsJLJ31oWP ec7Q== X-Gm-Message-State: AOJu0Yw5JCPqb9pxlGvzo8UPGvmRGAd+4JDOTJ22NsAW5m9qaCHWpCly kdmBE+If2hr6JiB7YWFul+AAv1b3VT0KKUv3HDTnHQdPNQm0tgR+oVa9nHOaWcsA7s4rV9VzIkH ixc5Z9iSLbAHV9sb6KceloHhZcvkW3W0xBXJ+KGguK1iy70n2vxQ= X-Gm-Gg: ASbGncvk3KaQLMK2RDP3RMwnH9aRvKQfIBP4dHD9PdfCvxewS4hYqfwZqL/Drb75cSt 9RjVZPi7p8t+9fKjBQjaHfbfmRRrtNuQ= X-Google-Smtp-Source: AGHT+IHfzX7N/UDtRE+Zc7iJPw1rh5eXUNT8/hfqpLkY5HEv1OgcqSam4vgYq3RdROsnkQ3wAvWhO3bv9mXiQplQ/V8= X-Received: by 2002:a05:6358:7e16:b0:1ca:9d84:9b0b with SMTP id e5c5f4694b2df-1ca9d849cebmr134456355d.12.1732550028955; Mon, 25 Nov 2024 07:53:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Brandsberg Date: Mon, 25 Nov 2024 10:53:38 -0500 Message-ID: Subject: Re: Inconsistent results for division and multiplication operations To: szy <598546998@qq.com> Cc: pgsql-sql Content-Type: multipart/alternative; boundary="0000000000000833c20627bebd76" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000000833c20627bebd76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a common issue with using floating point math. You will see the same issue with many systems. Basically, the order of operations can trigger very minor differences in results, but if you round the first result to the same number of significant digits as the input, it would be identical. https://learn.microsoft.com/en-us/office/troubleshoot/access/floating-calcu= lations-info On Mon, Nov 25, 2024 at 10:46=E2=80=AFAM szy <598546998@qq.com> wrote: > > Hi PostgreSQL community, > > I have observed inconsistent results when performing division and > multiplication operations in PostgreSQL. > > postgres=3D# select 1.003/1.002*5.01; > ?column? > -------------------------- > 5.0149999999999999999806 > (1 row) > > postgres=3D# select 1.003*5.01/1.002; > ?column? > -------------------- > 5.0150000000000000 > (1 row) > > However, the expected result should be consistent for both queries. The > actual results differ > > > ------------------------------ > szy > 598546998@qq.com > > > > --0000000000000833c20627bebd76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a common issue with using floatin= g point math.=C2=A0 You will see the same issue with many systems.=C2=A0 Ba= sically, the order of operations can trigger very minor differences in resu= lts, but if you round the first result to the same number of significant=C2= =A0digits as the input, it would be identical.=C2=A0=C2=A0https://learn.microsoft.com/en-us/office/troubleshoot/access/floati= ng-calculations-info


On Mon, Nov 25, 20= 24 at 10:46=E2=80=AFAM szy <59854699= 8@qq.com> wrote:

Hi PostgreSQL community,

I have observed inconsistent results when performing division and m= ultiplication operations in PostgreSQL.

postgres= =3D# select 1.003/1.002*5.01;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0?= column?
--------------------------
=C2=A05.0149999999999999999806=C2=A0=C2=A0
(1 row)

postgres=3D# select 1.003*5.01/1.002;
=C2= =A0 =C2=A0 =C2=A0 ?column?
--------------------
=C2=A05= .0150000000000000
(1 row)

However, the e= xpected result should be consistent for both queries. The actual results di= ffer


=C2=A0
--0000000000000833c20627bebd76--