Unums.jl
Unums.jl copied to clipboard
Decimal/Integer Unums
Lets discuss the relative merits of different formulations that decimal unums could take.
Below, e
is the binary value of the exponent, f
is the binary value of the "fraction". ESS/FSS are the "size size" fields for exponent and fraction.
The formula for an arbitrary base, equivalent to binary unums would be (I think, normalized version):
# nonzero exponent
(-1)^signbit * base ^ (e - 2^(ESS-1) - 1) * (1 + (base-1) * f / (2^FSS))
However, this has the problem that decimals aren't nicely represented. So an alternative might be the unnormalized version (also called dual-integer encoding, I believe):
x = (-1)^signbit * base ^ (e - 2^(ESS-1)) * f
But... it could be incredibly useful to define a minimum exponent, making the formula:
x = (-1)^signbit * base ^ (e + EMIN) * f
This last form gives us the following definitions: (ESS, EMIN) == (0, 0)) ===> "integers" (ESS, EMIN) == (ess>=0, emin>=0)) ===> "integers multiples of 10^emin, then multiples of 10^(emin+1), ... etc" (ESS, EMIN) == (0, emin<0)) ===> "decimal fixed point" (ESS, EMIN) == (ess>0, emin==2^(ESS-1))) ===> "decimal floating point"
This form is not as space efficient as alternatives (a number is not necessarily uniquely represented), but it might be a good way to represent many very useful types of numbers.
Thoughts??
I've actually found, esp. for decimal floats, that not worrying about having numbers uniquely represented is a big plus, because when operating on them (which, because of the lack of decimal float hardware, is in software), frequently you are doing trivial things with them, such as add/subtract, multiply by 10 or 100, or divide by 10/100, and for the add/substract, it because just a integer add/subtract (checking for overflow) if the scales are the same.
I've got to think more about your EMIN proposal (after some more coffee!), but it looks interesting to me.