Re: [music-dsp] R: Anyone using unums?

[Ethan Fenn]

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  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 
>
> On Fri, Apr 15, 2016 at 9:38 AM, Ethan Fenn 
> 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 
>> 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 
 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
 

Re: [music-dsp] R: Anyone using unums?

[Alan Wolfe]

Your ideas are interesting Evan and it's interesting that you mention lattices.

An off topic usage case I was thinking about for these is actually for
lattice based homomorphic encryption. (like gentry's or homomorphic
encryption over the integers)

When it takes 10 minutes per logic gate, a simpler math method would be nicer.

At first glance, it might seem like lookup tables could be more
efficient yet (like, with CADET as someone mentioned), but in this
case of homomorphic encryption the encoding of the reciprocals on the
numberline is still useful since now you can have fractions. The
operations of unums themselves could all boil down to lookup tables
(homomorphic encryption uses XOR and AND, so going from lookup table
to ANF would be a good start, and then you could simplify the ANF),
but the unum encoding is still nice for having better accuracy at
lower bit counts it seems.

But hey, for all i know there's a better solution for that than unums,
for the H.E. case :P


On Fri, Apr 15, 2016 at 9:30 AM, Evan Balster  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
>
> On Fri, Apr 15, 2016 at 9:38 AM, Ethan Fenn  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 
>> 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
>>>  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 
 Data: 14/04/2016 23:30 (GMT+01:00)
 A: A discussion list for music-related DSP
 
 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, 

Re: [music-dsp] R: Anyone using unums?

[Evan Balster]

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 

On Fri, Apr 15, 2016 at 9:38 AM, Ethan Fenn  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 
> 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 
>>> Data: 14/04/2016 23:30 (GMT+01:00)
>>> A: A discussion list for music-related DSP 
>>>
>>> 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
>>>
>>>
>>>
>>> 

Re: [music-dsp] R: Anyone using unums?

[Ethan Fenn]

My money's still on this being not merely impractical but complete nonsense.

People with actual interesting new ideas tend to present them in a
straightforward way, rather than filling a slide deck with "What Big
Mathematics Doesn't Want You To Know About This New Encoding."

-Ethan



On Fri, Apr 15, 2016 at 11:19 AM, Bjorn Roche  wrote:

> On Fri, Apr 15, 2016 at 11:09 AM, Alan Wolfe  wrote:
>
>> They aren't full sized lookup tables but smaller tables. There are
>> multiple lookups ORd together to get the final result.
>>
> Ah, I see. I was confused by the relationship between the ORs and the LUTs.
>
>> I don't understand them fully yet, but I ordered his book and am going to
>> start trying to understand them and make some blog posts with working
>> example C code.  I'll share with the list (:
>>
> Looking forward. Personally, I find this interesting even if there's no
> immediate application.
>
> --
> Bjorn Roche
> @shimmeoapp
>
> ___
> 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

Re: [music-dsp] R: Anyone using unums?

[Bjorn Roche]

On Fri, Apr 15, 2016 at 11:09 AM, Alan Wolfe  wrote:

> They aren't full sized lookup tables but smaller tables. There are
> multiple lookups ORd together to get the final result.
>
Ah, I see. I was confused by the relationship between the ORs and the LUTs.

> I don't understand them fully yet, but I ordered his book and am going to
> start trying to understand them and make some blog posts with working
> example C code.  I'll share with the list (:
>
Looking forward. Personally, I find this interesting even if there's no
immediate application.

-- 
Bjorn Roche
@shimmeoapp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] R: Anyone using unums?

[Alan Wolfe]

They aren't full sized lookup tables but smaller tables. There are multiple
lookups ORd together to get the final result.

I don't understand them fully yet, but I ordered his book and am going to
start trying to understand them and make some blog posts with working
example C code.  I'll share with the list (:
On Apr 15, 2016 8:06 AM, "Bjorn Roche"  wrote:

> I can see this being applicable to:
>
> - GPUs, especially embedded GPUs on mobile, where low precision floats are
> super useful, and exact conformity to IEEE isn't (at least, I don't think
> conformity is part of any of the usual specs, but it may be)
> - Storage (I have an application now that could benefit from some sane
> low-precision floats. We are considering IEEE half floats -- yuck!)
>
> However, I am confused by the arithmetic. Is the author seriously
> proposing that all arithmetic be done by LUTs, or am I misunderstanding
> something? Seems like a joke since he literally compares it to "Cant add,
> doesn't even try". For smaller precision, LUTs seem workable, but if you
> have to fetch a number from a large LUT for every operation you can't
> really do that in one clock tick, since, in practice, you have to go off
> die. Anyway, if LUTs made sense for, say, 32-bit floating point math,
> couldn't we also use LUTs for current IEEE floats?
>
> Still, even if this is utter nonsense, I'm glad to see someone rethinking
> floats on a fundamental level.
>
> On Fri, Apr 15, 2016 at 10:38 AM, Ethan Fenn 
> 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 
>> 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 
 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



 

Re: [music-dsp] R: Anyone using unums?

[Bjorn Roche]

I can see this being applicable to:

- GPUs, especially embedded GPUs on mobile, where low precision floats are
super useful, and exact conformity to IEEE isn't (at least, I don't think
conformity is part of any of the usual specs, but it may be)
- Storage (I have an application now that could benefit from some sane
low-precision floats. We are considering IEEE half floats -- yuck!)

However, I am confused by the arithmetic. Is the author seriously proposing
that all arithmetic be done by LUTs, or am I misunderstanding something?
Seems like a joke since he literally compares it to "Cant add, doesn't even
try". For smaller precision, LUTs seem workable, but if you have to fetch a
number from a large LUT for every operation you can't really do that in one
clock tick, since, in practice, you have to go off die. Anyway, if LUTs
made sense for, say, 32-bit floating point math, couldn't we also use LUTs
for current IEEE floats?

Still, even if this is utter nonsense, I'm glad to see someone rethinking
floats on a fundamental level.

On Fri, Apr 15, 2016 at 10:38 AM, Ethan Fenn  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 
> 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 
>>> Data: 14/04/2016 23:30 (GMT+01:00)
>>> A: A discussion list for music-related DSP 
>>>
>>> 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
>



-- 
Bjorn Roche
@shimmeoapp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu

Re: [music-dsp] R: Anyone using unums?

[Ethan Fenn]

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  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  > 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 
>> Data: 14/04/2016 23:30 (GMT+01:00)
>> A: A discussion list for music-related DSP 
>>
>> 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

Re: [music-dsp] R: Anyone using unums?

[Ethan Fenn]

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 
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 
> Data: 14/04/2016 23:30 (GMT+01:00)
> A: A discussion list for music-related DSP 
> 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