HP Forums
Food for thought: Unums - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not remotely HP Calculators (/forum-9.html)
+--- Thread: Food for thought: Unums (/thread-6631.html)

Food for thought: Unums - matthiaspaul - 07-30-2016 11:29 PM

Have you heard about ''unums'' (for "universal numbers") already?

This is a new number format and arithmetic environment proposed by John Gustafson since 2013. It is meant to be a superset of or long-term even a replacement for traditional floating point arithmetic as defined in IEEE 754 etc. It claims to address many of the shortcomings of floating point and interval arithmetic in general, while also being better suited for modern and future number crunching hardware (high integration, cheap transistors, parallel cores, but thermal and power limitations). One of the ideas is to use today's technology and progress to provide mathematically better solutions of limited precision with known accuracy, not necessarily more solutions per time or solutions with extreme precision but sometimes still only very limited accuracy.

Unums must be considered a work in progress. There are meanwhile two considerable different proposals, unum I and II. So far, there are a few software emulations (obviously very slow), but no hardware implementations.

The proposal has generated some heated discussions about the pros and cons of the format already (including one between Kahan and Gustafson). While I don't consider unums in their present form to be "the one-and-only solution", I find some of the underlying ideas very interesting and thought-provoking. While I love to push existing technologies to the limits, I also think it is important to reevaluate issues from new perspectives from time to time.

Well, since there are many people in this forum, who are interested in mathematics and computer sciences, some might be interested to learn about unums as well. I have therefore compiled a list of unum resources I am aware of.

What do you think about the unum proposal?



Unum I presentations
Unum II presentations
The Great Debate

RE: Food for thought: Unums - Vtile - 07-31-2016 12:39 AM

Really cool, way over my brains at times, but HP calculator spotted.

Sorry, offtopic.

RE: Food for thought: Unums - Paul Dale - 07-31-2016 01:32 AM

Looks interesting!

- Pauli

RE: Food for thought: Unums - cruff - 08-01-2016 12:46 AM

There was some discussion of this in the Usenet comp.arch group a while back. You can search for "comp.arch unums" on Google to pick it up. Several people didn't seem to think it really solved anything, but I didn't follow the discussion closely.

RE: Food for thought: Unums - Claudio L. - 08-01-2016 01:06 AM

Really interesting. The first part has a few concepts that are already implemented in newRPL:
* Numbers use minimum storage needed, and auto promote themselves to larger storage only when needed: newRPL uses small integers in the range +/-130000 that only have a prolog and no storage, then auto-promoted to 64-bit integers (prolog+64-bits), then auto-promoted to arbitrary precision reals which only store the needed digits in packs of 8, so the number 1.5 only stores 1 pack of 8 digits even though precision might be set to 32.
* A bit to indicate if the quantity is exact or inexact.
* A "tag" to indicate the number of digits in the number.

But that's about where the similarities end, as newRPL sticks with the traditional floating point concept from there on.

Those "unums" are interesting, though I'm not sure how they would work in real problems. I particularly like the idea to represent "exactly" the inverses of all the integers in the fractional part of the number, so any integer number can be inverted back and forth with no loss of precision, ever (3 INV INV --> 3 is like a dream come true!).
But for general arithmetic I'm not so sure it's practical, I imagine a number that's an inverse of an integer:
1/13 + 1/23 --> Storing the result would need a storage system capable of storing the inverse of 13*23, and things can quickly escalate from there, requiring the use of large precision numbers very quickly. And what happens when you reach the maximum system precision? Then the result would be approximated (rounded? more like "snapped" into the grid of the uneven spacing of the discrete fractions that can be represented) much like in the current floating point but perhaps with a harder to determine bias.
So in the end it's a cool idea, I think it saves storage up to a point, then it just becomes the same thing (assuming you can't scale this up to massive amounts of digits), unless you are willing to work with those SORN (Sets-Of-Real-Numbers) which is a different animal.

Or have I misinterpreted their concept?