>okay, this PDF was more useful than the other. once i got down to slide #31,
> i could see the essential definition of what a "unum" is. >big deeel. >first of all, if the word size is fixed and known (and how would you know how far >to go to get to the extra meta-data: inexact bit, num exponent bits, num fractional >bits, at the end of the word if the word size was not known in advance?), then the >num fractional bits field is a waste of bits. the num fractional bits + num exponent > bits + 1 (the sign bit) adds to the word width. big fat hairy deeel. That older pdf is describing the "V1" unums. The newer stuff in the OP is proposing "V2" unums that don't have those issues. The new ones don't have the fractional bits/exponential bits format, nor the size fields. It's an alternative way of extending fixed point to handle real numbers - rather than adding an exponent field and then dealing with all of the exceptions and (implicit) accuracy issues, you add the concept of sets on the (projective) real line, and explicitly include reciprocals. Seems like the obvious application is more in these robotics/physics simulations where you want to do brute-force constraint checking, and not necessarily at terribly high resolution. The set-theoretic stuff allows you to do this in a rigorous, efficient, parallel manner. Not obvious what uses this might have for music DSP, although the availability of cheap division would obviate the hoops that we are in the habit of jumping through to avoid divisions. Also kind of neat that the format always tells you explicitly whether it is an exact number or a range of possible values, which opens up a new approach to dealing with propagation of round-off error. I.e., in traditional designs the results are rounded to the nearest exact number in each operation, and the associated error is implicit. So we end up having to over-spec systems to allow for that. And if we change the order of operations, we can't expect bit-exact results with floats. With unums the error remains explicit, as does its propagation through series of operations. So you can do things like re-order your operations and still get bit-exact results, and you get to specify exactly where, when, how - or *if* - the rounding to exact numbers occurs. You are not forced to accept some implicit rounding every time you do an operation, and then spec in worst-case error bounds to ensure the desired accuracy. On the other hand, the LUT approach seems like it will not scale well to higher resolutions, and it will probably be quite some time before we have any hardware that implements this stuff... Ethan D On Fri, Apr 15, 2016 at 1:24 PM, robert bristow-johnson < r...@audioimagination.com> wrote: > > > ---------------------------- Original Message ---------------------------- > Subject: Re: [music-dsp] Anyone using unums? > From: "Evan Balster" <e...@imitone.com> > Date: Fri, April 15, 2016 11:46 am > To: music-dsp@music.columbia.edu > -------------------------------------------------------------------------- > > > Tangentally, I read some slides > > <http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf> > > about the previous unum format, which seems to describe a "meta-float" > with > > very different characteristics that the ones here. > > okay, this PDF was more useful than the other. once i got down to slide > #31, i could see the essential definition of what a "unum" is. > > big deeel. > > first of all, if the word size is fixed and known (and how would you know > how far to go to get to the extra meta-data: inexact bit, num exponent > bits, num fractional bits, at the end of the word if the word size was not > known in advance?), then the num fractional bits field is a waste of bits. > the num fractional bits + num exponent bits + 1 (the sign bit) adds to the > word width. big fat hairy deeel. > > > > here are a couple of real number formats i have seen in practice in real > devices (neither had an IEEE floating-point coprocessor): > > 1. essentially the same format as IEEE-754 float except instead of being > sign-magnitude representation (a negative number looks just like its > positive value except the MSB is 1 instead of 0) the format is 2's > complement. the exponent is biased like IEEE and denorms happen when the > exponent bits (of the positive value) are all zeros. the number of > exponent bits might have been different and the word width might have bee > lower (take a look at slide #20, the 16-bit float). there are no NaNs and > there is no negative zero, every bit combination corresponds to a unique > real number. since the positive values are all strictly increasing if the > bit pattern is viewed as a regular binary integer, using the 2's complement > instead of sign-magnitude essentially preserves the integer comparison > result (which does not happen for IEEE if both numbers are negative). > > it is essentially the same format as used by the DEC PDP-10 (see > http://www.quadibloc.com/comp/cp0201.htm ) except that it has denorms > added (and the number of exponent bits may have been different). it's like > running your value through a piecewise-linear approximation of the > arcsinh() function. a bipolar log2() function. > > > > 2. the other interesting format i saw was representing each real number as > a fraction of two 2's complement integers. literally as a rational number. > there were routines to eliminate the redundant prime factors that were > common to the numerator and denominator (what we called "simplifying the > fraction") and to make the denominator always positive, as well as routines > to do arithmetic (add, subtract, multiply, divide, abs value). it was cute > and could represent any rational number (sorta, within its range, which was > dependent on precision) exactly, but it was not one-to-one. there were > multiple bit patterns that were equal to the same value. > > > > i would say that the first real number format (essentially the same > floating point with biased exponent and denorms, but using 2's complement > instead of sign-magnitude) is pretty useful. but both the explicit > fractions of integers and the unums seem not particularly worthwhile to me. > but if hell were to freeze over and IEEE wanted to redefine their standard > away from 754, i would recommend the PDP-10 with denormals format above. > > > -- > > > > > r b-j r...@audioimagination.com > > > > > "Imagination is more important than knowledge." > > > > > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp >
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
