fixpnts, classic floats, posits, and IEEE-754

[theo]

The Universal library now supports a broad range of floating-point types and provides a full spectrum of different samplings of the Real numbers, ranging from fixed-point, classic floating-point, tapered floating-point, and IEEE-754.

I came across this cute mathematical proof that answers the question if an irrational number raised to another irrational number could ever be rational. The answer is yes, and I wanted to see how this impacts different precisions. The equation in question is

sqrt(2)^sqrt(2)^sqrt(2) = 2

          class sw::universal::fixpnt<32,16,1,unsigned char>:   1.41421^(1.41421)^(1.41421) = 2.0000152587890625

                             class sw::universal::posit<8,2>:   1.41421^(1.41421)^(1.41421) = 1.75

                            class sw::universal::posit<16,2>:   1.41421^(1.41421)^(1.41421) = 1.99951

                            class sw::universal::posit<32,2>:   1.41421^(1.41421)^(1.41421) = 2

                            class sw::universal::posit<64,2>:   1.41421^(1.41421)^(1.41421) = 2

                           class sw::universal::posit<128,2>:   1.41421^(1.41421)^(1.41421) = 2

        class sw::universal::cfloat<8,2,unsigned char,1,1,0>:   1.41421^(1.41421)^(1.41421) = 1.96875

       class sw::universal::cfloat<16,5,unsigned char,1,1,0>:   1.41421^(1.41421)^(1.41421) = 1.99902

       class sw::universal::cfloat<32,8,unsigned char,1,1,0>:   1.41421^(1.41421)^(1.41421) = 2

                                                       float:   1.41421^(1.41421)^(1.41421) = 2

This gives some credence to the observation that if your representation has 'enough' precision bits, it tends to be forgiving numerically. Of course, it would be horrible energy inefficient, and that is where the mixed-precision/tailored-precision algorithm optimization features of the Universal library come in handy.

Does anyone have interesting empirical computations that they want to optimize? We are looking for good floating-point benchmarks to drive FPBench tooling as well. 

[John Gustafson]

Interesting example, Theo! I have a few comments.

First, make sure you parenthesize the expression. It's a little obscure, but x^y^z without parentheses is generally parsed as x^(y^z), and with good reason. (x^y)^z is the same as x^(y*z) so there would be no reason to write x^y^z unless the grouping is x^(y^z). So your test problem is

(sqrt(2)^sqrt(2)) ^ sqrt(2)

with the understanding that no algebra is permitted to automatically rearrange that to sqrt(2) ^ (sqrt(2) * sqrt(2)).

Second, I've been working on the logarithmic version of posits lately, where the meaning of the fraction bits f changes from 1.f to 2^f. That means the posit midway between 1 and 2 is, in fact, sqrt(2) exactly! So if I apply log posits to your problem, I get exact computation of the correct result, 2, with no rounding errors along the way. Even logposit<7,2> can do this.

Third, linear posits produce an answer that rounds to 2 for posit<20,2>, the smallest precision that does so. But it is off by 1 ULP for posit<21,2> and there is no clear pattern of it being exact beyond a certain precision; it seems to be off by as much as 2 ULPs in either direction. I wonder if it is misleading to use a benchmark where rounding of the result can "trammel" the computed answer into the exact mathematical answer. This point is covered in The End of Error: Unum Computing in Section 18.2 (pp 261–270).

For purposes of accuracy benchmarking, it would be best if the correct mathematical answer is not expressible exactly in the numerical format, to avoid the trammeling effect.

Best,

John

--
You received this message because you are subscribed to the Google Groups "Unum Computing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unum-computin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/14c1ed36-6274-42d9-bf96-a28b7fb10d67n%40googlegroups.com.