I still having figured out how this would tie in with decimal floating point, but I really do like a few key things:
1. single type for all sizes of integers and floating point values (which I already have, except with decimal values) 2. being able to represent both - and + underflow, unlike the IEEE standard 3. being able to distinguish between +/- overflow, and real +/- Infinite values (and knowing what overflowed #s are bounded by a particular X and infinity) 4. being able to distinguish between exact numbers and inexact numbers 5. variable sized scale (in my own format, I have 0, 1, or 2 bytes, but this is maybe more flexible) 6. compactness of representation (I already have that also, in my own packing format) So, while I already have 1,5,6, this adds 2,3,4 for me. On Wednesday, July 29, 2015 at 9:50:21 AM UTC-4, Steven G. Johnson wrote: > > > > On Sunday, July 26, 2015 at 9:09:19 AM UTC-4, Tom Breloff wrote: >> >> For example, I have a specialized solution to represent financial prices >> which have a fixed accuracy, but I want to be able to do floating point >> arithmetic on them. > > > Why not use decimal floating-point for that? > > Regarding, unums, without hardware support, at first glance they don't > sound practical compared to the present alternatives (hardware or software > fixed-precision float types, or arbitrary precision if you need it). And > the "ubox" method for error analysis, even if it overcomes the problems of > interval arithmetic as claimed, sounds too expensive to use on anything > except for the smallest-scale problems because of the large number of boxes > that you seem to need for each value whose error is being tracked. >
