02.09.2021 12:17, Mark Rotteveel wrote:
I find the suggestion to make this configurable an interesting one, but
this wouldn't fundamentally resolve the issue you have, it just would
change the compound error of calculation. For example, we followed your
suggestion and provide an option to use
On 02-09-2021 10:08, Omacht András wrote:
Summary: for our point of view mysql and oracle is the easiest to use as a
programmer (and maybe a data analyst who has the right to write queries).
Postre, mssql bring the solution what at least we expected and what Attila
outlined.
Firebird is
31.08.2021 23:53, Mark Rotteveel wrote:
The only debatable feature of dialect 3 division is the fact the
calculation stops (equivalent to floor rounding), while reduction of
scale through assignment or cast applies half-up rounding
"Whether to round or truncate when performing division is
bird-devel@lists.sourceforge.net
Subject: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
On 2021-09-01 15:40, Molnár Attila wrote:
> Ok, I understand it's not "wrong", works as designed/intended. Just
> put into documentation.
>
> A
01.09.2021 09:29, Molnár Attila wrote:
In dialect 3 you have to cast to double always for not to loose precision.
I believe you may avoid the casts if you store everything as NUMERIC
inside the db, but your procedures use DOUBLE (or better DECFLOAT) for
inputs/outputs/locals.
Dmitry
3 as soon as possible.
András
-Original Message-
From: Alex Peshkoff via Firebird-devel
[mailto:firebird-devel@lists.sourceforge.net]
Sent: Wednesday, September 1, 2021 6:20 PM
To: firebird-devel@lists.sourceforge.net
Cc: Alex Peshkoff
Subject: Re: [Firebird-devel] Dialect 3 inconsis
On 2021-09-01 18:20, Alex Peshkoff via Firebird-devel wrote:
On 9/1/21 7:13 PM, Omacht András wrote:
(Or please support D1 and don’t force developers to rewrite existing
codebase.)
May be I've missed something - but did we have plans to remove Dialect
1? It seems that not.
Technically,
On 9/1/21 7:13 PM, Omacht András wrote:
(Or please support D1 and don’t force developers to rewrite existing codebase.)
May be I've missed something - but did we have plans to remove Dialect
1? It seems that not.
Firebird-Devel mailing list, web interface at
Dialect 3 inconsistent round/trunc - configurable
calculation method needed
On 2021-09-01 15:40, Molnár Attila wrote:
> Ok, I understand it's not "wrong", works as designed/intended. Just
> put into documentation.
>
> Also, how do you expect to people to leave dialect 1 wh
On 2021-09-01 15:40, Molnár Attila wrote:
Ok, I understand it's not "wrong", works as designed/intended. Just
put into documentation.
Also, how do you expect to people to leave dialect 1 when dialect 3
gives no benefit, in both dialect extra effort needed to get
calculations right, plain
eti üzenet-
Feladó: Dimitry Sibiryakov [mailto:s...@ibphoenix.com]
Küldve: 2021. szeptember 1., szerda 11:27
Címzett: For discussion among Firebird Developers
Tárgy: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
Molnár Attila wrote 01.09
Molnár Attila wrote 01.09.2021 8:29:
The problem: why the storage format has affect on calculation. It just feels
wrong.
It is ordinary thing in all programming languages when data types decide
calculation rules. In the Delphi product of integer division used to be floating
point, but
eforge.net
Tárgy: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
On 31-08-2021 16:19, Molnár Attila wrote:
> 127.13 / 3.4618 = 36,72366976717315
It isn't, taken literally in dialect 3, the result is 36,723669 ;).
> EXECUTE BLOCK
> RETURN
31.08.2021 23:53, Mark Rotteveel wrote:
The only debatable feature of dialect 3 division is the fact the calculation stops (equivalent to floor rounding), while reduction
of scale through assignment or cast applies half-up rounding, on the other hand, this behaviour is consistent with integer
On 2021-08-31 21:10, Dimitry Sibiryakov wrote:
Mark Rotteveel wrote 31.08.2021 19:05:
What does SQL standard say about it?
Not much, beyond "iv) The precision and scale of the result of
division are implementation-defined."
So theoretically result of division of two exact numbers can
Mark Rotteveel wrote 31.08.2021 19:05:
What does SQL standard say about it?
Not much, beyond "iv) The precision and scale of the result of division are
implementation-defined."
So theoretically result of division of two exact numbers can be inexact
number like DOUBLE PRECISION but it
On 31-08-2021 16:59, Dimitry Sibiryakov wrote:
Molnár Attila wrote 31.08.2021 16:19:
I think in all case value should be rounded, this behaviour is
inconsistent, and also truncation is unexpected behaviour.
What does SQL standard say about it?
Not much, beyond "iv) The precision and
On 31-08-2021 16:19, Molnár Attila wrote:
127.13 / 3.4618 = 36,72366976717315
It isn't, taken literally in dialect 3, the result is 36,723669 ;).
EXECUTE BLOCK
RETURNS (
c0 NUMERIC(15,10),
c1 NUMERIC(15,10),
c2 NUMERIC(15,6),
c3 NUMERIC(15,5),
c4 NUMERIC(15,4))
AS
DECLARE
Molnár Attila wrote 31.08.2021 16:19:
I think in all case value should be rounded, this behaviour is inconsistent, and
also truncation is unexpected behaviour.
What does SQL standard say about it?
--
WBR, SD.
Firebird-Devel mailing list, web interface at
19 matches
Mail list logo
