13.11.2016 19:18, Alex Peshkoff wrote: > > SQL> SELECT * FROM TESTDECFLOAT; > > FEE_DECFLOAT FEE_REAL PERCENTAGE > ======================== ============== ======================== > 0.70 0.69999999 0.05
I do see the difference with REAL but I'm asking for a difference with NUMERIC backed by int32/int64. I don't mind DECFLOAT being a "better float" than FLOAT / DOUBLE PRECISION but so far I don't see how it's better than NUMERIC/DECIMAL (which also stores exactly 0.70 in dialect 3). >> Moreover, what are we going to do when people ask as for precisions >> beyond the 34 decimal digits? Introduce blr_dec256/blr_dec512/etc or >> switch to blr_varydec backed by decNumber (and probably stored as packed >> BCD)? Are there any reasons why the current implementation doesn't >> follow this way other than hardware accelerated computations for 64/128 >> bits? > > Use of unlimited length fields is certainly great but I suppose we > should switch to it in future versions (including unlimited length > strings). Better precision calculations are needed right now, in v.4. My question wasn't about v4 but rather about extensibility in general, how do you plan to support longer precisions? By increasing bits or by switching to some variable-length implementation? If the latter, why is dec64/dec128 better *now* than varydec? Just hardware backed computations or anything else? Dmitry ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
