| To be honest I'm a bit confused by your comments but the parts I can understand show some misunderstandings. > lack of NaN/inf makes them fail on lots of other issues You comment repeats several times assertions of the form "fails on lots of stuff", but does not really elaborate further x) But that aside. Posits do have a NaN value, with the difference being that only 1 bit pattern is reserved to it instead of potentially quadrillions of them. This makes a huge difference especially at lower precisions, where NaN bit patterns waste an appreciable amount of the total set of values. They do not have inf, they simply do not overflow. > In my case I knew I'd be doing these in batches, and wanted C/C++ code to auto vectorize and do them in SIMD, and did not want to pay the cost for branches. This speed up the flow by about 8x on almost all larger processors, at the cost of some slots having NaN or inf. Those with NaN or inf had underlying cubics I could discard. Can you point to your code? I'd be very very surprised if it somehow cannot be rendered using posits. Pathological cases do exist, of course. Nobody claims that posits are uniformly better than IEEE floats, such a claim being obviously, trivially nonsensical. > All in standard C++, no hint of parallelization intrinsics, handled by modern compilers perfectly, and getting massive speed gains Speed gains over what? x) I don't get it. Over branchy or scalar IEEE code? If yes, what's the relevance of that? And yes, a 40-year old format with decades of hardware and compiler support works better in practice than any conceivable alternative... because all such alternatives are proof-of-concepts with no hardware or compiler support! There's no commercial hardware of any kind for posits, let alone SIMD. I really fail to see your point here. |