rounding of posits

[sangeeta chowdhary]

Hello,

I am learning about rounding in terms of posits. 

Suppose in <6,3> environment number 000001 is interpreted as 1/(256^4). Here we don't have any fraction bits. What exact posit value is stored for this number? What is the precision?

[John Gustafson]

Hello Sangeeta,

I know this takes some time to get used to, but the hidden bit is always 1. The fraction bits are optional, and can be the empty set. If there are no fraction bits in the decoding, then the significand = 1 + fraction is equal to 1 since there are no fraction bits. That's the beauty of the system... no subnormal numbers.

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 post to this group, send email to unum-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/1b6bdb3f-d00c-436c-b3cf-a4b4aa4186c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Theodore Omtzigt]

@Sangeeta:   I missed this subtlety on first reading of the posit spec as well. You can have configurations like posit<4,4>, heck you could have posit<4,256> if you wanted to. The 'es' configuration of the posit drives useed, but the regime drives the bit fields, both the exponent and fraction bits are subservient to the regime.

Here is a really  funky configuration to illustrate the point: posit<3,3>. This posit will NEVER have any exponent nor fraction bits. Otherwise stated, the parameter ES does not specify the number of exponent bits in the encoding.

[sangeeta chowdhary]

So, in the table format, we have something like this -

Generate Posit Lookup table for a POSIT<6,3> in TXT format

Binary         Decoded       k    sign   scale          regime        exponent        fraction                         value                  posit_format

000001          000001      -4       0     -32           00001             ---               ~   2.328306436538696289063e-10          6.3x01p

value shown as 2.328306436538696289063e-10 is a very small number and it can not be represented with 6 bits with exact precision. I am trying to see what is the closest value stored here and what is the precision for it. I understand that value represented by this bit string is 1/(264^4) but we are not storing rationals. 

In 32- bit floating point number system we have 23 bits of precision, if there is any number which requires more than 23 bits, it is rounded. But in posits precision is not fixed. Now I have set my posit environment to <6,3> and I encountered a very small number say -  2.328306436538696289063e-10. Now to store this number I need to store the closest possible number which can be represented in this environment. 

How should I proceed from here? If you say we should change the environment to store this number then how will I perform computations on numbers with two different environments. It is like saying I have to do addition with float and double, before doing addition with two different precisions, either float is promoted to double or double is truncated to float. How this is achieved in posits.

I am looking for step by step process to do something like this. Please help me for the same.

[Theodore Omtzigt]

the small number is minpos for a posit<6,3> and it is EXACTLY represented by 6.3x01p, or in binary 00'0001.

posit arithmetic is just like float arithmetic in that you gather the exponent and the fraction, align, operate, realign, and optionally round, if you are not using the quire. So a posit<6,3> can 'natively' operate with minpos at 2.32....e-10 and faithfully represent that value with 6 bits.

[Cerlane]

Hi Sangeeta,

I believe what you are trying to ask is that if we convert from binary to decimal, we cannot in actual fact display the decimal value, i.e. 2.328306436538696289063...e-10, exactly. 

John had studied and come up with the following table for standard posits.

posit<8,0> you need maximally 3 decimals to be able to get back the exact same binary.

posit<16,1> 5 decimals

posit<32,2> 10 decimals

posit<64,3> 20 decimals

In the case of attempting to perform arithmetic on mixed posit types (i.e. a different posit size or exponent size(es)), is an ugly can of worms. At this moment, we don't recommend one to do that.

If you have to absolutely do it, I will recommend that you use the higher precision one as the type you will use. This naturally leads to the question if which posit type has a higher precision. This is the ugly can of worms part.

Try to stick to the same es size then your life will be simpler.

I hope I answer your question.

Cerlane

[Cerlane]

One additional point. If you want to check what 2.328306436538696289063e-10 gets converted into for different posit sizes and es, you can use this online widget:

https://posithub.org/widget/plookup

The results look like that:

Posit format            Binary                                        Value                             Relative Error                  Decimals of Accuracy
Posit<6,0>		+00001	                                      0.0625                            268435455			-8.428839876973601
Posit<6,1>		+00001	                                      0.00390625                        16777215			-7.224719870049579
Posit<6,2>		+00001	                                      0.0000152587890625                65535				-4.81647330376525
Posit<6,3>		+00001	                                      2.3283064365386963e-10            0				Infinity
Posit<6,4>		+00100	                                      2.3283064365386963e-10            0				Infinity
Posit<8,0>		+0000001	                              0.015625                          67108863			-7.826779880792019
Posit<8,1>		+0000001	                              0.000244140625                    1048575				-6.020599499103933
Posit<8,2>		+0000001	                              5.960464477539063e-8              255				-2.406540180433955
Posit<8,3>		+0000100	                              2.3283064365386963e-10            0				Infinity
Posit<8,4>		+0010000	                              2.3283064365386963e-10            0				Infinity
Posit<16,0>		+000000000000001	                      0.00006103515625                  262143				-5.418538265246529
Posit<16,1>		+000000000000001	                      3.725290298461914e-9              15				-1.1760912590556813
Posit<16,2>		+000000001000000	                      2.3283064365386963e-10            0				Infinity
Posit<16,3>		+000010000000000	                      2.3283064365386963e-10            0				Infinity
Posit<16,4>		+001000000000000	                      2.3283064365386963e-10            0				Infinity
Posit<32,0>		+0000000000000000000000000000001	      9.313225746154785e-10             3				-0.47712125471966244
Posit<32,1>		+0000000000000000100000000000000	      2.3283064365386963e-10            0				Infinity
Posit<32,2>		+0000000010000000000000000000000	      2.3283064365386963e-10            0				Infinity
Posit<32,3>		+0000100000000000000000000000000	      2.3283064365386963e-10            0				Infinity
Posit<32,4>		+0010000000000000000000000000000	      2.3283064365386963e-10            0				Infinity