Need help figuring out a way to convert IEEE 754 representation to Posit

[A Avinash]

Is there a simple algorithm to convert IEEE 754 representation to Posit form without converting to decimal first ?

I understand how I can extract the sign bit and the mantissa bits but I'm having trouble figuring out the other bits. I'm guessing there is a simpler way to do the conversion, as posit is supposed to be a good replacement to floating type in the hardware level.

Sorry, if its a silly question. I've recently come across posits and still figuring stuff out.

Thanks

[Theodore Omtzigt]

Here is the algorithm we are using in Universal. It is part of a larger design based on bit-level manipulation. For fast conversions for standard posits, you can look at the specialized implementations in https://github.com/stillwater-sc/universal

[John Gustafson]

There is an algorithm in SoftPosit to convert various precision posits to various precision floats, and one for floats to posits. It's clearly NOT a silly question, because I've been informed that Oxford professor Milan Kloewer, who uses 16-bit posits to do weather and climate modeling, found a way to do conversion much faster, at least for the precisions he uses. Like, 20 times faster.

https://www.youtube.com/watch?v=wp7AYMWlPLw

Look on Github for his library… his method is open-source. I can see how converting 16-bit posits to 32-bit floats could be super-fast because you know the 32-bit floats are a superset of the 16-bit posit vocabulary, and you won't experience overflow or underflow or subnormals. Going in the other direction is trickier but I think he figured out a way to do that quickly as well. Encoding the regime value k into a run of 0 or 1 bits just involves some shifting by k and integer ops. In general you have to round, though, which will add a clock cycle or two.

Since SoftPosit is general for posit precisions up to 32 and float precisions up to 64, it first decodes the posit or float into the sign, the integer exponent, and the significand, and then re-encodes those into the other format with tests for exception conditions. Obviously, that's going to be a lot slower than it needs to be when converting 16-bit posits to 32-bit floats.

Another reason this is not a silly question is that posits may offer immediate bandwidth relief even before we have modern CPUs with full custom VLSI support for posits. If you can build float-posit convertors between 32-bit posits and 64-bit floats, or 16-bit posits and 32-bit floats, then posits can serve as a compression method for floats stored in memory. This has already been considered, for example, by the Square Kilometer Array project.

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/36f5f5e8-3f8c-482b-9b1c-dda3f20c0012n%40googlegroups.com.

[Himeshi De Silva]

In addition to the very comprehensive answer Professor Gustafson has provided, you might find helpful the conversion functions in the stripped down version of Caffe [1]  as a starting point for some code to hack on....

[1]caffe-stripped/fp16.cpp at posit16 · Himeshi/caffe-stripped (github.com)

Thank you,

-Himeshi.

To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/7FBE2B07-320B-45B9-AA87-66CF3D62C5E9%40earthlink.net.

[A Avinash]

Thank you all for helping me out.

I looked into professor Milan Kloewer's Github and things are more clear now. Just wanted to know if I am converting to Posit<X,Y> from floats, will the right arithmetic bit shift of the exponent obtained(after removing bias), by the value Y always yield the correct k value (assuming no exceptions occur like underflow, overflow etc..)  ? And will the corresponding exponent bits for Posit be the last Y bits of the exponent from Float ?

[John Gustafson]

My approach in converting a float to a posit is to first separate the sign from the magnitude (note the sign, then set the bit to zero); then check if the magnitude is zero, in which case return posit zero (all 0 bits). 

If the magnitude is ∞ or NaN (all exponent bits are 1 bits, so a single conditional test suffices), return the posit NaR (1 followed by all 0 bits). 

If the magnitude is nonzero, check if it is less than minPos (in which case return signed minPos) or greater than maxPos (in which case return signed maxPos). (If the posit dynamic range is larger than the float dynamic range, you can skip this step.)

Once you do that, the conversion of float exponent value to posit regime+exponent should always work. The only conditional test needed is whether the float magnitude is less than 1, so the regime is a run of 0 bits instead of a run of 1 bits. If you're clever, you can use a Boolean value of the conditional test to cover both cases correctly. 

If the posit has an exponent size of eS bits, then the exponent of the posit will be the value of the float exponent (after correcting for the bias) modulo 2^eS. Like, for standard posits with eS = 2, those two bits will hold the float exponent value modulo 4.

I'm telling you how SoftPosit does it and how my Mathematica library does it… perhaps Milan Kloewer found some insanely clever shortcuts, but I haven't had time to study his code. If you find that he did discover shortcuts to the above steps, please inform this forum!

Best,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/478a4ee6-afcf-4d51-93cf-ff8b7477f7f3n%40googlegroups.com.

[MitchAlsup]

Note: This is untested and "just a guess".

On Saturday, February 18, 2023 at 4:41:05 PM UTC-6 johngustafson wrote:

My approach in converting a float to a posit is to first separate the sign from the magnitude (note the sign, then set the bit to zero); then check if the magnitude is zero, in which case return posit zero (all 0 bits). 

I would separate into S, E, and 1.F (I am a HW guy so this is the way I think)

Access a table[E] containing {pE, pEs, pF} pE is the posit regime+exponent, pF is a shift applied to 1.F to put it in the proper position in the posit.

pFr = pF > 0 : 1.F >> pF /*you could add rounding on the bits falling off the end here */ : 1.F << -pF;

Now::

p = {S<<63 | pE << pEs | pFr}; is the posit when no boundary conditions are encountered.  

Now we make the table values handle certain special cases::

E = all 1s -> {NaN or Infinity} pF = 63 (thus the shift will eliminate all 1.F bits without making shifters on various architectures cranky)

E = all 0s -> denormalized {and I don't remember what posits do with denorms}

The table[2048] is easy to construct. Using E directly as an index to the table eliminates having to understand the bias, it is just mapping E to pE<<pEs. If you are going to have to consume (blow) a doubleword for regime+exponent then you can eliminate the shift (saving an instruction (below)).

Milan Kloewer's use of posits has in a very restricted range, so his table[E] will hardly damage his cache's

data footprint. He may ignore infinities and underflow conditions due to his restricted range.

In my ISA, this is 14 instructions (less rounding).

Best,

John

Mitch