>> select 1.0 / 1.00 from rdb$database
DY> I suppose this particular case (and maybe some others of the same kind)
DY> can be worked around. Perhaps we could truncate intermediate results to
DY> fit the maximum supported bitness if and only if the trailing bytes are
DY> insignifica
07.12.2015 19:21, Carlos H. Cantu wrote:
> With currently logic, the result of multiplications or divisions will
> have Scale = Sum of the scale of its members. This cause nonsense
> situations like the following:
>
> select 1.0 / 1.00 from rdb$database
>
> resulting in:
> Arithmet
08.12.2015 13:29, Mark Rotteveel wrote:
> I'd prefer if anything is changed, this is not done without resorting
> hackish solutions that will just create another set of confusion, but
> instead by using generally accepted arbitrary precision decimal
> calculation rules from standards like ANSI X3.
MR> The SQL Standard - intentionally - does not specify behavior for
MR> division. When dialect 3 was implemented, Borland opted to use the same
MR> rules as the SQL standard specifies for multiplication.
Thanks Borland
MR> I'm not so sure this is so easy to do. You either have additional space
SS> OK, can you make example how engine (with you extension) will handle this:
SS> select 1.0 / 1.00 from rdb$database
SS> select 0.1 / 9.00 from rdb$database
SS> select 1.1 / 0.01 from rdb$database
There is no such thing like "my extension". I poin
On 8-12-2015 11:37, Adriano dos Santos Fernandes wrote:
> On 08/12/2015 08:29, Mark Rotteveel wrote:
>> I'd prefer if anything is changed, this is not done without resorting
>> hackish solutions that will just create another set of confusion, but
>> instead by using generally accepted arbitrary pre
On 08/12/2015 08:29, Mark Rotteveel wrote:
> I'd prefer if anything is changed, this is not done without resorting
> hackish solutions that will just create another set of confusion, but
> instead by using generally accepted arbitrary precision decimal
> calculation rules from standards like ANS
On 7-12-2015 17:21, Carlos H. Cantu wrote:
> I want to discuss an implementation/enhancement to avoid "unnecessary"
> overflow errors with calculations using currently exact types
> (numeric, decimal - dialect 3).
>
> With currently logic, the result of multiplications or divisions will
> have Scal
08.12.2015 1:39, Carlos H. Cantu wrote:
> I guess the proposed
> enhancement will be useful for 99% of the cases, when user don't care
> about loosing some accuracy in the middle of the calculation, but
> still cares about accuracy of stored data (what you store is exactly
> what you get when you r
> SS> Yes, but now you have to told to FB explicitly which part of number have
> SS> to be discarded.
>
> And you still could do this, as you wish :) You remain with full
> control, if/when you prefer to have it. I guess the proposed
> enhancement will be useful for 99% of the cases, when user don
This link may be useful to such a discussion:
http://speleotrove.com/decimal/
It's been around a long time, so you may already be familiar
with it. A project I have been involved with wrote a system
based on that reference library storing 34 digit numbers in
text fields (with appropriate collatio
> -Original Message-
> From: Carlos H. Cantu [mailto:lis...@warmboot.com.br]
> Sent: Lunes, 07 de Diciembre de 2015 21:40
>
> SS> The final solution will be support for high precision arithmetics.
> SS> https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
>
> Maybe. But will some
The original Interbase implementation had rational, aka reasonable,
arithmetic semantics.Your example is an excellent example of idiotic
semantics. Borland rewrote the code to conform what they, severely
lacking in working neurons, interrupted the SQL standard to require.
I care very littl
SS> Yes, but now you have to told to FB explicitly which part of number have
SS> to be discarded.
And you still could do this, as you wish :) You remain with full
control, if/when you prefer to have it. I guess the proposed
enhancement will be useful for 99% of the cases, when user don't care
abo
> SS> 1. Decimal or Numeric is used for to keep exact accuracy.
> SS>If you don't need this accuracy use float point data types.
>
> You didn't get the point. There is no loss of accuracy. The data types
> will continue working as is. Remember, as I said, today you already have to
> cast
> if
I have several points against this idea:
1. Decimal or Numeric is used for to keep exact accuracy.
If you don't need this accuracy use float point data types.
2. System that will produce unpredictable results in math is really hard
to use.
Some numbers will rounded, truncated or modified.
SS> I have several points against this idea:
You opinion is welcome :)
SS> 1. Decimal or Numeric is used for to keep exact accuracy.
SS>If you don't need this accuracy use float point data types.
You didn't get the point. There is no loss of accuracy. The data types
will continue working as
17 matches
Mail list logo
