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 1tFqhZ-00Gi62-4W for pgsql-sql@arkaria.postgresql.org; Tue, 26 Nov 2024 08:13:41 +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 1tFqhX-005NsP-9i for pgsql-sql@arkaria.postgresql.org; Tue, 26 Nov 2024 08:13:39 +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 1tFqhW-005NsH-Qe for pgsql-sql@lists.postgresql.org; Tue, 26 Nov 2024 08:13:38 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tFqhU-0046HL-Bz for pgsql-sql@lists.postgresql.org; Tue, 26 Nov 2024 08:13:38 +0000 Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-2124ccf03edso52361635ad.2 for ; Tue, 26 Nov 2024 00:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1732608814; x=1733213614; 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=k/mNXmRwmiBYM7RFDWtyP0r0k45cmR4MW+AcDENcvXk=; b=AX+imvmRENNtP+gf5qMmX6YnEgo969NhzSrWjZFb+fkktpkKgmevCe2jcuJAIRbXP1 9rBdieNwBzK7RGo9G+LQ+14xEfVyGfcg8AEi+ancgqeN3x88Gj2OWtNBZ4xmZI49TiAr 8Ea+YTKY9Mxdz3oZO8Oobw1N/1dkkv9ZEGlhkDC4og4RWIxXX016ccxs9AXIcvlAw8HD NmWtb9RaeI1mdDcI2TA/ifhGMqr6B5Kk984yQMMMuSrxVBwc+B57NV6jzmQ9nAS3gwNR ktCj4tcQnExnflcsl4Sl7D017Q4Xh0V0SPLTtQQ2zQwHAJtehkur6L80X32aCGpsqKzd NDDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732608814; x=1733213614; 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=k/mNXmRwmiBYM7RFDWtyP0r0k45cmR4MW+AcDENcvXk=; b=it0GDfpybxO3O3NOIdfU/i8nMjyxBV2DgWFP04P7p3uysiSFrCGSuG4nqb2jmVFfpp HNE4hWGRBu8i61wKMUqQvalhyTNYFG9WfdhCJmpxYaLvDFmRosz+Ugn+WXmInJPrtked SCzzYrJueiRYORW2rWLMJoXs/4p+wmEyALlilQ31LOBFWls9qMc9By24GFRLdqrIGSVC wKqaavL3PkfoDLXFxKYHfb4vF3kP7m8uT/eS9uk9Uz2Ect8BYqX+0jWs5qPCqIeDyy4B BUho9h72OcmM0wkZil3QZgtEujrSdPmtbaCzmxW2b+8UUCmwJht77nfd89rouuPTk7RA C7dA== X-Forwarded-Encrypted: i=1; AJvYcCUZTKbRfeI95PZdKGyyuxeMagFuaXqkbiq1PU81FtcnBVqk/D4F+r8GprURcv5P9/DA6naRw3Gr51g=@lists.postgresql.org X-Gm-Message-State: AOJu0Ywwa7fk9WQw94sKyg0giuZ7FWJleJkU1rjIAoALWQo4++xjypmh gkRSrJqFwPB0suTa0CSAAoXy4mVWThNMCEmtw0d3Jaz5lXoSvY88Bag1QoQ+aKb9f2x0qqdOr/5 GutkGKCFI0G5S3TC7owm86ymp2m8= X-Gm-Gg: ASbGncsLYt5BOw7R5PwSvx3ewbTRs6d/d3x7zjJZe6HSpN3jZJf9ZpFDkJEgvw9MyhS aAyzkwO61OULfq2OV+j6+9fdiG9wI X-Google-Smtp-Source: AGHT+IFAI/MiwEGSD25K2Tkgzwmfsy3lsqGn2gGFdAM3mP21i1kg4mMnYECgvgcI1McPdklWJyzyA7p4VW+ZpT995Js= X-Received: by 2002:a17:902:e54f:b0:212:3f36:d985 with SMTP id d9443c01a7336-2129f82ea85mr245126615ad.53.1732608814089; Tue, 26 Nov 2024 00:13:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Martin_Norb=C3=A4ck_Olivers?= Date: Tue, 26 Nov 2024 09:13:22 +0100 Message-ID: Subject: Re: Inconsistent results for division and multiplication operations To: szy <598546998@qq.com> Cc: Erik Brandsberg , pgsql-sql Content-Type: multipart/alternative; boundary="000000000000e60ce10627cc6c5f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e60ce10627cc6c5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2024 at 5:18=E2=80=AFPM szy <598546998@qq.com> wrote: > If the number of significant digits in the input is not fixed, it becomes > challenging to achieve consistent results by rounding. > for example > postgres=3D# select round(1.003/1.002*5.01,2); > ?column? > -------------------------- > 5.01 > (1 row) > > postgres=3D# select round(1.003*5.01/1.002,2); > ?column? > -------------------- > 5.02 > (1 row) > > Correct. That's why you should always use numeric with the desired precision if you want precision numbers. for instance select 1.003/1.002*5.01 :: numeric(10,4) will give the same result as select 1.003*5.01/1.002 :: numeric(10,4) They are much slower to calculate than floating point, however, so if you don't care about precision you can keep using just floating point. Regards, Martin --=20 Martin Norb=C3=A4ck Olivers IT-konsult, Masara AB Telefon: +46 703 22 70 12 E-post: martin@norpan.org K=C3=A4rrh=C3=B6ksv=C3=A4gen 4 656 72 Skattk=C3=A4rr --000000000000e60ce10627cc6c5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On = Mon, Nov 25, 2024 at 5:18=E2=80=AFPM szy <598546998@qq.com> wrote:
If the number of significant digits in the input= is not fixed, it becomes challenging to achieve consistent results by roun= ding.
for example
postgres=3D# select round(1.003/= 1.002*5.01,2);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0?column?
--------------------------
=C2=A05.01= =C2=A0=C2=A0
(1 row)

postgres=3D#= select round(1.003*5.01/1.002,2);
=C2=A0 =C2=A0 =C2=A0 ?column?<= /div>
--------------------
=C2=A05.02
(1 row)
=


Correct. That's why you = should always use numeric with the desired precision if you want precision = numbers.

for instance
select 1.003/1.002*5.01 :: numeric(10,4)will give the same result as
select 1.003*5.01/1.002 :: numeric(10,4)
They are much slower to calculate than floating point, however, so if= you don't care about precision you can keep using just floating point.=

Regards,

Martin=C2=A0

--
Martin Norb=C3=A4ck Olivers
IT-konsult, Masa= ra AB
Telefon: +46 703 22 70 12
K= =C3=A4rrh=C3=B6ksv=C3=A4gen 4
656 72 Skattk=C3=A4rr
--000000000000e60ce10627cc6c5f--