I'm going to start work on an unum prototype today, but first... a quick poll: what package name is preferred? Unum.jl? Unums.jl? Something else? I expect there to be an "Unum" type, so following other conventions I think maybe Unums.jl is proper.
Also... please get in touch with me if you have interest in collaborating/contributing, or if you have specific test cases you'd like me to try out. On Monday, July 27, 2015 at 3:56:13 PM UTC-4, Scott Jones wrote: > > 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 <scott.pa...@gmail.com> 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). >>>>> >>>>>
