Slide 9 illustrates an 8-value unum (3 bits wide), then says the corresponding SORN is 8 bits wide. I don't know how else to interpret this unless we're talking about the full power set of values. Likewise for the explanation a few slides earlier about filled vs. empty values being represented as bits.
But of course we can take a step back from this idea and think of representing an interval using two values. But then this has nothing to do with unums.... you can do the same with floats or fixed points or any representation you can think of. And the way unums do it (as far as I understand, which can't really be done because it is not adequately explained) is really pretty clumsy, because it seems to burn an entire bit to differentiate between the open interval (0,1) and the half-open interval (0,1]. There is no way this is a good use of a bit. -Ethan On Fri, Apr 15, 2016 at 12:30 PM, Evan Balster <e...@imitone.com> wrote: > Ethan: Take care not to overlook the solution proposed for SORN size: > Yes, a comprehensive SORN for the set of N-bit unums takes 2^N bits. But > in most practical applications we'll use SORNS representing continuous > ranges of unums on the "circle" (which may cross infinity). As the author > notes, common operations (+-*/^) on continuous ranges produces another > continuous range. We can represent these ranges with 2N bits which are > homologous to two unums, where the range is the clockwise path from the > first to the second.* (I'll confess this took me a while to understand as > the presentation doesn't explain it clearly.) > > To operate on practical (range) SORNs, we simply need to apply the > operation to each range, such that the new range is the union of all > possible results. We can define this in terms of operator implementations > which yield the "most clockwise" and "least clockwise" results given the > four argument values. So a SORN addition (a+b) would yield (a.min+b.min, > a.max+b.max). > > All this said, I won't necessarily disagree with the "snake oil and > conspiracy theories" argument yet -- but *if this system can be made into > something practical* it would certainly yield some interesting benefits. > Even if it can't, perhaps it can inspire something better. > > > * In the case of the complete set and the zero set, the two halves of the > range equal; in this case we would want to use an odd or even MSB, or some > other pattern, to distinguish between the special cases. > > – Evan Balster > creator of imitone <http://imitone.com> > > On Fri, Apr 15, 2016 at 9:38 AM, Ethan Fenn <et...@polyspectral.com> > wrote: > >> Sorry, you don't need 2^256 bits, my brain was just getting warmed up and >> I got ahead of myself there. There are 2^256 different SORNs in this >> scenario and you need 256 bits to represent them all. But the point stands >> that if you actually want good precision (2^32 different values, for >> instance), the SORN concept quickly becomes untenable. >> >> -Ethan >> >> >> >> On Fri, Apr 15, 2016 at 9:03 AM, Ethan Fenn <et...@polyspectral.com> >> wrote: >> >>> I really don't think there's a serious idea here. Pure snake oil and >>> conspiracy theory. >>> >>> Notice how he never really pins down one precise encoding of unums... >>> doing so would make it too easy to poke holes in the idea. >>> >>> For example, this idea of SORNs is presented, wherein one bit represents >>> the presence or absence of a particular value or interval. Which is fine if >>> you're dealing with 8 possible values. But if you want a number system that >>> represents 256 different values -- seems like a reasonable requirement to >>> me! -- you need 2^256 bits to represent a general SORN. Whoops! But of >>> course he bounces on to a different topic before the obvious problem comes >>> up. >>> >>> -Ethan >>> >>> >>> >>> On Fri, Apr 15, 2016 at 4:38 AM, Marco Lo Monaco < >>> marco.lomon...@teletu.it> wrote: >>> >>>> I read his slides. Great ideas but the best part is when he challenges >>>> Dr. Kahan with the star trek trasing/kidding. That made my day. >>>> Thanks for sharing Alan >>>> >>>> >>>> >>>> Inviato dal mio dispositivo Samsung >>>> >>>> >>>> -------- Messaggio originale -------- >>>> Da: Alan Wolfe <alan.wo...@gmail.com> >>>> Data: 14/04/2016 23:30 (GMT+01:00) >>>> A: A discussion list for music-related DSP < >>>> music-dsp@music.columbia.edu> >>>> Oggetto: [music-dsp] Anyone using unums? >>>> >>>> Apologies if this is a double post. I believe my last email was in >>>> HTML format so was likely rejected. I checked the list archives but >>>> they seem to have stopped updating as of last year, so posting again >>>> in plain text mode! >>>> >>>> I came across unums a couple weeks back, which seem to be a plausible >>>> replacement for floating point (pros and cons to it vs floating >>>> point). >>>> >>>> One interesting thing is that division is that addition, subtraction, >>>> multiplication and division are all single flop operations and are on >>>> "equal footing". >>>> >>>> To get a glimpse, to do a division, you do a 1s compliment type >>>> operation (flip all bits but the first 1, then add 1) and you now have >>>> the inverse that you can do a multiplication with. >>>> >>>> Another interesting thing is that you have different accuracy >>>> concerns. You basically can have knowledge that you are either on an >>>> exact answer, or between two exact answers. Depending on how you set >>>> it up, you could have the exact answers be integral multiples of some >>>> fraction of pi, or whatever else you want. >>>> >>>> Interesting stuff, so i was curious if anyone here on the list has >>>> heard of them, has used them for dsp, etc? >>>> >>>> Fast division and the lack of denormals seem pretty attractive. >>>> >>>> http://www.johngustafson.net/presentations/Multicore2016-JLG.pdf >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >> >> _______________________________________________ >> 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 >
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
