Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IEEE-754 conversion to posit #2

Open
Ravenwater opened this issue Mar 3, 2022 · 2 comments
Open

IEEE-754 conversion to posit #2

Ravenwater opened this issue Mar 3, 2022 · 2 comments
Assignees

Comments

@Ravenwater
Copy link
Member

Herbie considers the reals to be covered by the interval (-inf, +inf). Posit rounding of -inf/+inf to NaR breaks that approach.

What was the reason that inf got mapped to NaR instead of maxpos?

@lindstro
Copy link

lindstro commented Mar 3, 2022

John can correct me if I'm wrong, but I believe that NaR originally was meant only to represent the point at infinity in the projective reals (a vestige from type-II unums) but later came to be a catch all for anything not real, including indeterminate forms. Would interpreting (NaR, NaR) as (-inf, +inf) solve the problem you're alluding to? I suspect not.

Rounding inf to maxpos would break indeterminate forms involving infinities. I do not think we want inf - inf = 0, inf / inf = 1, 0 * inf = 0, inf / 2 = maxpos / 2, etc.

Another issue is when converting a lower precision "infinite" posit to a higher precision, where maxpos at lower precision would round to a finite real smaller than the higher-precision maxpos, so infinity could through rounding and conversion become a "small" finite number.

One issue I see with the current standard is that 1 / inf = NaR, while you'd expect it to be zero.

I've thought about reserving four posits for +/- inf and +/- epsilon (a sign-preserving reciprocal of +/- inf), but again that fails when extending precision unless special, possibly expensive rounding rules are introduced. I've also meant to look more closely at wheel theory to see if it may provide a clean solution.

@boomshroom
Copy link

I remember some versions of posits being accompanied by Valids, which as far as I can remember are composed of posits with an uncertainty bit. A posit with an uncertainty bit set is supposed to represent the entire range between its two neighboring posits, and then it usually acts like the least significant bit. Given that it only requires 1 bit, you can basically turn an N-bit posit into an N-1 bit posit with a u-bit.

This would effectively make for two infinities and two infinitesimals, serving as the intervals between NaR and positive and negative max_pos, and between 0 and positive and negative min_pos. These infinities and infinitesimals would honestly be better mappings for IEEE +0, -0, +∞, and -∞, since they two really represent ranges of numbers rather than individual points. (This also means that -0 and +0 are the only non-NaN floats with overlapping ranges, and no true 0 to squeeze between them.) Oh, and the uncertainty bit also acts as a handy built-in inexact flag, rather than needing to set a CPU register that will never be read.

Of course this would work out a lot better if there was a Valid specification in addition to the Posit specification. I think Valids were supposed to be intervals with 2 u-posits, but I'm not entirely sure, nor am I sure how to calculate with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants