I've compared various possible implementations of high precision
numeric. Except existing in fb4 (decfloat based) were checked native
gcc's __int128 and ttmath (fixed high precision library with pure .h
implementation). Test performed a mix of sum/mult/div operations in a
loop. Native code was
Is this about the format used in Firebird internally, or are you also
proposing to change the format used in the protocol?
Mark
On 21-6-2019 15:53, Alex Peshkoff via Firebird-devel wrote:
I've compared various possible implementations of high precision
numeric. Except existing in fb4 (decfloat
On 21.06.2019 18:15, Mark Rotteveel wrote:
Is this about the format used in Firebird internally, or are you also
proposing to change the format used in the protocol?
Both.
Mark
On 21-6-2019 15:53, Alex Peshkoff via Firebird-devel wrote:
I've compared various possible implementations of high
On 21-6-2019 17:20, Alex Peshkoff via Firebird-devel wrote:
On 21.06.2019 18:15, Mark Rotteveel wrote:
Is this about the format used in Firebird internally, or are you also
proposing to change the format used in the protocol?
Both.
And we're only talking about NUMERIC/DECIMAL, not about DECF
21.06.2019 15:53, Alex Peshkoff via Firebird-devel wrote:
internal binary layout of 128-bit integer is the same for __int128 on x64 (on
x86 unsupported), ttmath's 128-bit class on x64 and ttmath on x86.
128 bits integers are supported on x86. At least I have no problem operate with them
(us
21.06.2019 15:53, Alex Peshkoff via Firebird-devel wrote:
Except existing in fb4 (decfloat based) were checked native gcc's __int128 and
ttmath
BTW, did you check native GCC's decfloat as well?
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lis
On 22.06.2019 13:10, Dimitry Sibiryakov wrote:
21.06.2019 15:53, Alex Peshkoff via Firebird-devel wrote:
internal binary layout of 128-bit integer is the same for __int128 on
x64 (on x86 unsupported), ttmath's 128-bit class on x64 and ttmath on
x86.
128 bits integers are supported on x86. A
24.06.2019 9:56, Alex Peshkoff via Firebird-devel wrote:
I must say I've used rather old gcc 4.8 to try and it does support int128 for x64 b ut
does not support them for x86.
Some intrinsics were broken in 5.1 but I found 5.4 and later working well.
--
WBR, SD.
Firebird-Devel mailing li
21.06.2019 15:53, Alex Peshkoff via Firebird-devel wrote:
Native code was compiled w/o opimization - even with -O1 loop was optimized and test
completed at once.
You always can fool optimizer changing you loop into something like this:
for (int i = 0; i < n; ++i)
{
e += (a /
21.06.2019 15:53, Alex Peshkoff via Firebird-devel wrote:
I.e. I suggest to replace high precision numeric's implementation using decfloat with
native 128-bit integer when possible and ttmath in other cases. That will make it possible
to use 128-bit integers in all cases when 64 is not enough wi
Dimitry Sibiryakov писал(а) в своём письме Tue, 25 Jun
2019 22:54:57 +0300:
21.06.2019 15:53, Alex Peshkoff via Firebird-devel wrote:
I.e. I suggest to replace high precision numeric's implementation using
decfloat with native 128-bit integer when possible and ttmath in other
cases. That
26.06.2019 8:46, Simonov Denis via Firebird-devel wrote:
the DECFLOAT type is defined in the SQL:2016 standard as a separate type, so you don’t
need to remove anything. We are talking only about the implementation of NUMERIC (19+, x)
and DECIMAL (19+, x)
Ok. What's wrong with these types map
On 26.06.2019 11:48, Dimitry Sibiryakov wrote:
26.06.2019 8:46, Simonov Denis via Firebird-devel wrote:
the DECFLOAT type is defined in the SQL:2016 standard as a separate
type, so you don’t need to remove anything. We are talking only about
the implementation of NUMERIC (19+, x) and DECIMAL (1
>I don't think that somebody perform time-critical intensive
> calculations in SQL. From
> my POV it has no sense.
You'd be surprised what people do in SQL. Also it's maybe not about the
calculation itself, but about the number of calculations. I.e. doing some
fairly fine looking calculati
This discussion seems to have halted without a conclusion. What is going
to happen? Will extended precision numerics change to use an int128 (and
maybe extend maximum precision to 38)? Or will the current solution
remain, that is backed by a Decimal128?
Mark
On 21-6-2019 15:53, Alex Peshkoff
On 06.07.2019 12:03, Mark Rotteveel wrote:
This discussion seems to have halted without a conclusion. What is
going to happen? Will extended precision numerics change to use an int128
Yes.
(and maybe extend maximum precision to 38)?
May be.
Firebird-Devel mailing list, web interface at
Alex Peshkoff via Firebird-devel
wrote Fri, 21 Jun 2019 16:53:26 +0300:
I've compared various possible implementations of high precision
numeric. Except existing in fb4 (decfloat based) were checked native
gcc's __int128 and ttmath (fixed high precision library with pure .h
implementatio
On 16.09.2019 23:17, Simonov Denis via Firebird-devel wrote:
Alex Peshkoff via Firebird-devel
wrote Fri, 21 Jun 2019 16:53:26
+0300:
I've compared various possible implementations of high precision
numeric. Except existing in fb4 (decfloat based) were checked native
gcc's __int128 and ttmat
Alex Peshkoff via Firebird-devel
wrote Tue, 17 Sep 2019 13:42:17 +0300:
SQL> select cast(12345678901234567890 as numeric(25, 0)) as n from
rdb$database;
Statement failed, SQLSTATE = 22003
arithmetic exception, numeric overflow, or string truncation
-numeric value is out of range
Tha
Simonov Denis via Firebird-devel
wrote Tue, 17 Sep 2019 15:47:14 +0300:
FIELD_TYPE = 26 - this is bigint
I'm sorry, it seems like I'm wrong.
It would be nice to add a new type to RDB$TYPES.
However, the examples above do not work.
--
Simonov Denis
Firebird-Devel mailing list, web in
17.09.2019 16:42, Simonov Denis via Firebird-devel wrote:
Simonov Denis via Firebird-devel wrote
Tue, 17 Sep 2019 15:47:14 +0300:
FIELD_TYPE = 26 - this is bigint
I'm sorry, it seems like I'm wrong.
It would be nice to add a new type to RDB$TYPES.
Create new database and it will be t
Vlad Khorsun wrote Tue, 17 Sep 2019 17:22:10 +0300:
17.09.2019 16:42, Simonov Denis via Firebird-devel wrote:
Simonov Denis via Firebird-devel
wrote Tue, 17 Sep 2019 15:47:14 +0300:
FIELD_TYPE = 26 - this is bigint
I'm sorry, it seems like I'm wrong.
It would be nice to add a new type
On 17.09.2019 18:05, Simonov Denis via Firebird-devel wrote:
I know. I meant that in the freshly created database, the description
for RDB$TYPE = 26 is missing.
select * from rdb$types
where RDB$FIELD_NAME = 'RDB$FIELD_TYPE'
I understand that there should be RDB$TYPE_NAME = INT128
Added n
23 matches
Mail list logo
