On 02/01/18 15:31, Mark Rotteveel wrote:
On 29-1-2018 10:45, Alex Peshkoff via Firebird-devel wrote:
May be taken standalone your suggestion is simpler but in conjunction
with existing logic for numerics based on bigint and smaller integer
values and need to cast between them use of existing impelmentation
appeared to me simpler.
I admit I'm not privy to all the details of the calculation done, but
wouldn't the same behavior be achieved by using the normal Decimal128
division operation, and then rescaling with rounding down (truncation)
to the required scale of -1 * (ScaleOp1 + ScaleOp2).
I agree that same behavior may be achieved using different ways.
And if it is used as a container for a plain big integer, why not
just use a densely packed decimal (the format used in a Decimal128
to encode the coefficient), or 'better', a binary encoded big
integer? Both would allow for even higher precision with the same
storage requirements (or smaller storage requirements for the same
precision).
And have a nihgtmare casting from this 'better' format to Decimal(34)?
You still have some of that nightmare when casting between decfloat
and decimal(34, x).
Ohh, I mistyped a bit, I wanted to say about conversion from binary
encoded big integer to decfloat(34 or 16) and vice versa. Compared with
that current conversions code is simple and straightforward.
Also take into an account that for existing format we already have
support in indices. Alternative formats/libraries were discussed but
decision was taken to use same library for both Decimal and
DecimalFixed.
Point taken, but my suggestion was more that we now don't utilize the
Decimal128 to its fullest for decimal, and users of the direct API now
need to handle decfloat and decimal(19+, x) in a very different manner
even though the underlying datatype is the same (and provides the
convenient feature to communicate the scale inline).
Damned, I still do not catch where is the problem. I reviewed ISQL code
- we have DecFixed interface that provides conversion to/from strings
and BCD. And it's implementation is less that once screen of a code.
The reason for this design seems to be mainly that it was more
convenient internally, and to be honest, I don't think Firebird's
public API (and its wire protocol), should export internal design
problems in this manner.
In any case, if this is a sailed ship, and this is not going to
change, then this needs to be very clearly documented in the release
notes. And preferably even include some code example how to handle
both decfloat and the extended decimal precision for users of both the
old and new API.
For users of new API there are no problems (just use dedicated
interface), and thanks for a docs note - should add them to Using_OO_API.
What about old API - hmm, not sure that we can dup any interface in it.
BTW, DecFixed interface can be used with old API too.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
