General discussion

[tbreloff]

Open topic... what are your thoughts on Unums? Where are they useful? When not? Anything goes...

[JobLeonard]

I don't know enough about the subject to judge if they are a good idea, although the ubit thing looks really elegant to me, but what do I know? I admit being biased towards hoping they will work as advertised, because:

1. what is advertised is awesome
2. I love the idea of witnessing scientific breakthroughs like this, where it is breaking out of a local maximum by doing things differently instead of just faster

What I want should not matter of course, but I just mention it for full disclosure.

Realistically I think it's too early to tell though. There are people who have read the book and think it's great, there are people who really know a lot about the old ways of doing floating point math and traditional interval methods and so far they seem very skeptical, but the intersection between the two seems to be limited for now, so I'm still waiting for the experts to read the book and give feedback with full information on the proposal.

I can say that the book was very accessible and that I learned a lot about the topic of floating point numbers on specific details where I had trouble understanding before.

[jwmerrill]

For reference, there's some interesting discussion so far on the julia-users mailing list: https://groups.google.com/forum/#!topic/julia-users/LbFCCeMv76M

[JohnLGustafson]

Thanks for starting this discussion site, and for the kind words about the idea! I hope to be able to respond quickly to questions about unum arithmetic here.

[tbreloff]

Thanks John! As I read the book there were some concepts that just "made sense" to me, and it's great to have a very easy to read book with enough visuals to both stay entertained and not get lost. I do think that 90% of the value of unums lie in their potential as a great replacement to floats, but that could possibly be lessened with a good software implementation. I hope I can help with that!

[jwmerrill]

Since it's possible (and probable) for arithmetic on unums to produce ubounds, and ubounds are the objects that are closed under arithmetic, I think it might make sense to make ubounds be the first class objects, and consider alternative representations for them besides a pair of unums.

The main properties of ubounds are:

1. They represent a contiguous subset of real numbers.
2. Their endpoints may be independently open or closed.
3. Their endpoints are rational numbers where the numerator has a specified number of bits, and the denominator is of the form 2^n, where n may be positive or negative, and also has a specified maximum number of bits.
4. Arithmetic over them operates as specified in Gustafson's book.

It seems like the pair-of-unums representation has some redundancy that might be worth trying to eliminate. Here's one alternative encoding that I think can have the same 4 properties above:

1. The left endpoint is specified as a unum, and its ubit determines whether that endpoint is open or closed.
2. The width of the interval is specified by an integer giving the "counting distance" from the left endpoint to the right endpoint, where "counting distance" means to layout the the unums with the same utag as the left endpoint in value order, and count them. Every other one of these is open, and if the width causes the right endpoint to land on an open interval, then the right endpoint of the interval is open.

If you used a fixed size integer for the width width, this saves you 1 utag. Alternatively, you could use a variable length encoding for the width, and then in the case of small intervals, which I suspect is the most common case, it lets you compress the width by a decent factor.

Since this format represents the same information as the pair-of-unums ubound, it should be possible to implement the same arithmetic on it. I'm not yet sure whether the implementation of that arithmetic would be more or less elegant and efficient than for the pair-of-unums ubound.

[JohnLGustafson]

Did you read the part of the book about the "unify" and "smartunify" functions? They cover what you are suggesting.

[jwmerrill]

I did read that part of the book. I might have misunderstood something, but I was under the impression that unify and smartunify always return either a single unum, or in the case of smartunify, sometimes the same ubound that was used as input.

It seems useful to me to have a representation for ubounds that can't be faithfully unified to a single unum (e.g. because they span 0) that is as compact as possible.

[ityonemo]

Wow! I have been working on my own unum implementation in julia for the last few weeks and all of a sudden my roommate checks and finds two others! Ok... So Tom - One difference between what I'm doing and what you are is that I'm padding my unums to align with architectural word size (a concession to the 'tyranny of the word size' as Gustafson says). I'm not ready to push to github yet, but perhaps when I have mine up we can come up with some performance tests and see how things look?

[tbreloff]

Cool... Can you expand on how you are doing padding/alignment differently? If you have any other thoughts on implementation please let me know... It's not set in stone yet.

Just curious... Why aren't you ready to push to github? Most github projects are unfinished (just put a warning in the readme like I do)

On Aug 6, 2015, at 4:28 AM, ityonemo notifications@github.com wrote:

Wow! I have been working on my own unum implementation in julia for the last few weeks and all of a sudden my roommate checks and finds two others! Ok... So Tom - One difference between what I'm doing and what you are is that I'm padding my unums to align with architectural word size (a concession to the 'tyranny of the word size' as Gustafson says). I'm not ready to push to github yet, but perhaps when I have mine up we can come up with some performance tests and see how things look?

— Reply to this email directly or view it on GitHub.

[jwmerrill]

Has anyone thought about the implementation of the g-layer yet?

It seems like that is by far the biggest challenge for an efficient software arithmetic implementation. It sounds like implementing some of the fused accumulation operations, like fdotu, will require rather large integer operations in the g layer. It seems like it will be painful to allocate new large storage areas for every arithmetic operation, but maybe there's no getting around it.