Live data from Hacker News

Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

slideshare.net

41–50 of 58 posts

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#41

Are there any more details on unums available online (i.e. without purchasing his book)? The presentation is quite heavy on promotion, but a bit sparse on details. I also note that he dedicates a page on his website to "Gustafson's law". http://johngustafson.net/glaw.html

Not many. I did go ahead and purchase his book. It's... kind of a weird read, honestly. Useful - it clarified some things about the proposed Unum format - but also written very casually, like "pop science" prose, which seems inappropriate - who would buy a book about a floating-point number format if they didn't want a dry, boring book full of technical details? Some of the arguments are made as though to convince a…

Some would call it an enjoyable read. Definitely not the typical stodgy format of papers, but addressing the reader and throwing a few jokes in doesn't hurt the technical validity. He wrote it so it could be accessible and defends it as such in the prologue. Dry papers get passed over these days, I'm afraid.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#42
post #31

Earlier quoted context omitted.

He's a bit showy about the format. Wish he would just put out a technical paper. Anyway, I guess his motivation might be "you can represent any real number (with finite bits, and therefore finite precision)". In the book, he presents an interesting case: little 4-bit versions of the Unum that can represent: -inf, (-inf, -2), -2, (-2, -1), (-1, -1/2), -1/2, (-1/2, -0), -0, 0, (0, 1/2), 1/2, (1/2, 1), 1, (1, 2), 2, (2,…

If I add (1/2, 1) to (1, 2), then I should get (3/2,3), which is not representable with any of the above values. So what is the result and in what sense is it correct?

I think the correct answer is (0,inf) which is a value you can get by dropping to a lower resolution within the same unum environment.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#43
post #39

Slide 21: > I have been unable to find a problem that breaks unum math. Then perhaps try (x+y) != x, where x is a very large, and y is a very small positive number.

Suppose x and y are exact numbers. Then x+y is represented as the open interval (x, x+ULP) where x+ULP is the smallest representable exact unum greater than x. Since x is disjoint from the open interval (x, x+ULP), it satisfies the inequality.

Folks, if you don't want to buy the book, Amazon lets you do a "look inside the book" that gets enough introduction to explain the unum format, for free.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#44
post #32

This is funny, but even Mathematica gives bad answer for that equation from slide 25...

There are actually quite a number of places where Mathematica gives a wrong answer and unum math does not! For example, if you ask Mathematica to find all real values of x for which 1 == 1, it returns the empty set. Unum math correctly returns the entire real number line.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#45
post #31

Earlier quoted context omitted.

If I add (1/2, 1) to (1, 2), then I should get (3/2,3), which is not representable with any of the above values. So what is the result and in what sense is it correct?

I think the correct answer is (0,inf) which is a value you can get by dropping to a lower resolution within the same unum environment.

Ah, that makes sense. The 4-bit representations do not suffice by themselves, but imply the support of some or all of the smaller representations as well, and I guess you always need a representation for [-inf,inf].

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#46
post #4

Earlier quoted context omitted.

I am not sure that I understand what you're saying. Given a charitable reading of the presentation, the author seems to be saying that his standard explicitly specifies range of values, as opposed to the IEEE Float. It did not seem like he was saying that he could explicitly represent an infinite amount of exact, distinct values using a finite number of bits. Low level data structures are not my area of expertise, so…

Under that reading, he's saying nothing: just represent the interval [-inf, inf] as "0" and call it a day. So assuming that he's saying anything at all, he's at least being imprecise, and the actually claim should be something like "represent any dyadic interval using a finite number of bits".

First of all, a correction: the 4-bit unums can represent any of

-inf, (-inf, -2), -2, (-2, -1), (-1, 0), 0, (0, 1), (1, 2), 2, (2, inf), inf, and both quiet and signaling NaN. They do not represent ±1/2 or use ±1/2 as an endpoint.

If you add, say, 1 to (1,2), you get (2, inf). The open interval means it does not CONTAIN infinity, but ends at a finite value too large to represent. If the largest positive real you can represent is 2, then (2, inf) is a mathematically correct answer.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#47

Earlier quoted context omitted.

Regardless if it is representing number, ranges, or a mix of both, there are still 2^n maximum possible representations for n bits. Perhaps you could create a mix of numbers and ranges equal to (2^n)-2 and then add one range that is from the lowest number represented to negative infinity and add another that does the same for positives. But I can do that system with -, 0, +, NAN. See, I just represented all numbers.…

I would argue that unums are a "superior replacement" for doubles in many cases, though: in the case that you support unums that are "wide" enough, you can represent doubles exactly, plus you have additional values, plus some nice rules about when approximation error occurs/is propagated and not as many bits need to be stored or moved around on buses. It'll be a while before there's an implementation anywhere near as…

For hardware without a FPU, you can do floats in software when accuracy is more important than speed (vs fixed point), one can imagine that if this thing actually works then for hardware without a "UPU" one can just do unums in software when needed.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#48

Earlier quoted context omitted.

There's an even worse disparity in the amount of time required for those two processes. How is that ratio affected by your technology?

We bring the ratio down as well... A load/store to a cores local scratchpad (Our software managed and power efficient version of a traditional L1 cache) is 1 cycle, compared to 4 cycles for an Intel processor. Add in the fact that we have 128KB of memory per scratchpad (compared to 16 to 32KB L1 D$ for Intel), you don't need to go to DRAM as much, greatly increasing performance/throughout on top of the 10x+ efficienc…

Smart that you all used a scratchpad. I've been encouraging their use for years now for the higher efficiency and predictability.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#49
If it delivers on slides' claims, it's pretty awesome stuff. All the floating point nonsense has always aggravated me. I dodged it where I could since I wasn't doing scientific computation. I appreciate any improvements, especially efficient.

Re: Unum Computing: An Energy Efficient and Massively Parallel Approach to Numerics

#50

Earlier quoted context omitted.

Under that reading, he's saying nothing: just represent the interval [-inf, inf] as "0" and call it a day. So assuming that he's saying anything at all, he's at least being imprecise, and the actually claim should be something like "represent any dyadic interval using a finite number of bits".

First of all, a correction: the 4-bit unums can represent any of -inf, (-inf, -2), -2, (-2, -1), (-1, 0), 0, (0, 1), (1, 2), 2, (2, inf), inf, and both quiet and signaling NaN. They do not represent ±1/2 or use ±1/2 as an endpoint. If you add, say, 1 to (1,2), you get (2, inf). The open interval means it does not CONTAIN infinity, but ends at a finite value too large to represent. If the largest positive real you can…

Your list should include -1 and 1 as well, shouldn’t it?

Edit: here was the slide http://i.imgur.com/0eQvvK1.png

Post reply on HN