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

Re:Unum Computing: An Energy Efficient and Massively Paralle... by Lawtonfogle on Friday July 24, 2015 @04:53PM (#9945109)

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. It isn't as useful, but boy are there savings on storage, cost, and computation time.

Unums shouldn't be seen as better than ints, longs, floats, or doubles anymore than a double is seen as better than an int. They have different uses and strengths, and there are problems where none are a good choice. Perhaps unums are the best choice for some problems. Perhaps they are clearly and significantly better in some areas. But they should be thought of as an alternative to the existing formats and not a superior replacement.

[ Parent | on HN ]

Re:Unum Computing: An Energy Efficient and Massively Paralle... by methodOverdrive on Friday July 24, 2015 @05:09PM (#9945207)

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 fast as existing FPUs, but Gustafson makes a good argument for his format. Personally, I'm more interested in the correctness benefits than the space/power/time savings - even if unums are never faster than 64-bit floats, they present an interesting way to do real-number arithmetic and my brief exposure to them leaves me much more confident that I could write numerical algorithms correctly than with doubles - I do numerical/statistical algorithms with doubles in my work, and it's really a pain to reason about things that the "uncertain" (open-inverval) values of the unum format would greatly simplify.

They're also an inferior replacement in the case that you want to take advantage of highly-optimized hardware, and that getting a correct answer doesn't really matter. I don't see unums replacing floats for, say, video game graphics. But for numerical computation, it seems like the only real flaw with unums compared to doubles is the nonexistence of a hardware implementation, and the existing popularity of doubles.

[ Parent | on HN ]

Re:Unum Computing: An Energy Efficient and Massively Paralle... by dnautics on Friday July 24, 2015 @05:22PM (#9945276)

Agreed. For neural networks. I would argue the opposite is true, you should just have a 16bit float that casts really large values to infinity silently without throwing errors, with a logistic lookup that maps "inf" to +/- 1... A mathematically incorrect float is operationally superior to the correct one.

[ Parent | on HN ]

Re:Unum Computing: An Energy Efficient and Massively Paralle... by methodOverdrive on Saturday July 25, 2015 @06:46PM (#9949343)

Bonus points if values near 0 are treated as 0 (encourages sparsity!)

[ Parent | on HN ]

Re:Unum Computing: An Energy Efficient and Massively Paralle... by GFK_of_xmaspast on Friday July 24, 2015 @07:23PM (#9945828)

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.

[ Parent | on HN ]