I ended up buying the book, haven't got too far into it yet, definitely am going to work these ideas into my storage format. I've actually been using a form of "universal numbers" for decades, where unlike C, etc. numbers were not typed with certain sizes, actually, numbers originally weren't even a type - semantically, everything was a string, and the operations you performed determined whether you got a "numeric" interpretation of the string. (typed numbers were added much later, to support IEEE binary floating point, instead of just decimal floating point).
On Sunday, July 26, 2015 at 5:06:56 PM UTC-4, Job van der Zwan wrote: > > Here's a Python port (found in the HN comments), might be worth checking > out: > > https://github.com/jrmuizel/pyunum > > > On Sunday, 26 July 2015 16:50:52 UTC+3, Scott Jones wrote: >> >> If you add support for this to Julia, I want to make sure I can add the >> format to my own record storage format efficiently. >> (This sounds great!) >> >> On Sunday, July 26, 2015 at 9:09:19 AM UTC-4, Tom Breloff wrote: >>> >>> Unums as a general concept seem really interesting. I ordered the book, >>> and may start a julia implementation (unless someone else gets there >>> first). Unified integer and floating point with clear accuracy information >>> could provide nice solutions for certain problems in finance and >>> statistics. For example, I have a specialized solution to represent >>> financial prices which have a fixed accuracy, but I want to be able to do >>> floating point arithmetic on them. This requires lots of converting between >>> int and float, rounding, etc. Unums may completely change those operations. >>> >>> If anyone starts an implementation, please post the package link here so >>> we don't duplicate efforts. >>> >>> On Sunday, July 26, 2015, Scott Jones <[email protected]> wrote: >>> >>>> >>>> >>>> On Sunday, July 26, 2015 at 7:51:51 AM UTC-4, Job van der Zwan wrote: >>>>> >>>>> So on an impulse I got the ebook, and even for a physics dropout like >>>>> me it's surprisingly engaging and accessible! There's some stuff in there >>>>> that isn't mentioned in the online slides that might clarify the idea >>>>> better. >>>>> >>>>> For example, floats already have a way to represent the largest >>>>> representable number (maxreal) and positive infinity. Add a ubit gives >>>>> you >>>>> the following: >>>>> >>>>> - maxreal without ubit: largest rep. number >>>>> - maxreal with ubit: interval between maxreal and infinity >>>>> - infinity without ubit: infinity >>>>> - infinity with ubit: the interval between... infinity and beyond? >>>>> >>>>> So what that gives you is a way to represent a number that is bigger >>>>> than what you can represent, but not infinite (maxreal + ubit), and NaN >>>>> (infinity + ubit). For negative numbers, just add sign bit. >>>>> >>>>> On Sunday, 26 July 2015 13:59:33 UTC+3, Scott Jones wrote: >>>>>> >>>>>> Yes, but I could add the information about "inexact" vs. "exact" and >>>>>> keeping track of significant figures to my format as well, while still >>>>>> storing many common values in just 1 byte (including Null, "", and >>>>>> markers >>>>>> for binary and packed Unicode text). >>>>> >>>>> >>>>> Well, at the very least it seems to inspire some ways you might >>>>> improve your format! :) >>>>> >>>> >>>> Yes, and I am interested in hearing about hardware support for the UNUM >>>> format. >>>> I'm also curious about how these ideas interact with decimal floating >>>> point (which is what I'm more familiar with, because for the sorts of >>>> operations important for the use cases I was concerned with, not having >>>> rounding/conversion issues between decimal <-> binary floating point or >>>> string <-> binary floating point was critical). >>>> >>>>
