Very interesting! Thanks for sharing.
There's a lot of interesting theory to unpack here, but I was
disappointed by a lack of practical discussion. Floats have their
problems, but we've learned to work around them. Modern CPUs let you
turn off denormals, and as for "kinks"... have those ever c
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
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 pre
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), t
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 bene
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
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
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
This is *really* interesting; thanks for bringing it up and expanding my
world a little, Alan. While it's a little difficult to put the concepts
here to practice, they have my brain spinning in some new directions. I'm
curious as to whether there's some lattice whose operations could be easily
an
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,
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 simpl
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 b
Ethan, I havent read the 2016 slides yet, but I was referring to the funnier
one here
http://www.slideshare.net/insideHPC/unum-computing-an-energy-efficient-and-massively-parallel-approach-to-valid-numerics
M.
Da: music-dsp-boun...@music.columbia.edu
[mailto:music-dsp-boun...@music.colum
Original Message
Subject: Re: [music-dsp] Anyone using unums?
From: "Evan Balster"
Date: Fri, April 15, 2016 11:46 am
To: music-dsp@music.columbia.edu
--
>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 expone
Thanks, I'll fix that.
On Thu, Apr 14, 2016 at 6:00 PM, Alan Wolfe wrote:
> ah ok thanks.
>
> This list has been around a long while hehe.
>
> http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html points
> to http://music.columbia.edu/pipermail/music-dsp/
>
> but apparently the real one
16 matches
Mail list logo
