Reading temperature value
You already have your answer. But I'll add the following:

This is a "10-Bit Digital Temperature Sensor." Note: Digital. It doesn't produce floating point values, at all. You are supposed to understand what a 10-bit binary value is and, more, you are supposed to understand signed twos-complement notation. If you haven't ever studied any of that, NOW is the time to start. It's an absolute MUST for anyone doing embedded programming work.

Since they provide 10 bits, and since they don't need more than 8 bits for the whole number portion they support, they've placed the integer, whole number part in the upper 8 bits and used the least significant 2 bits for the fractional part. I've taken the liberty to insert that implied binary radix point in column three below.

However, the floating point value is already in the first column. If that is all you wanted, they already provided that. But I think you don't want just that. I think you want a formula so that you can accept the \$DB_9 \dots DB_0\$ value and convert it to a floating point value. That's different. In the meantime, here's the amended table:

$$\begin{array}{rcl}
Temperature &amp; DB_9 \dots DB_0 &amp; Fixed~Point \\
–128^{\circ}\textrm{C} &amp; 10 0000 0000 &amp; 10 0000 00.00 \\
–125^{\circ}\textrm{C} &amp; 10 0000 1100 &amp; 10 0000 11.00 \\
–100^{\circ}\textrm{C} &amp; 10 0111 0000 &amp; 10 0111 00.00 \\
–75^{\circ}\textrm{C} &amp; 10 1101 0100 &amp; 10 1101 01.00 \\
–50^{\circ}\textrm{C} &amp; 11 0011 1000 &amp; 11 0011 10.00 \\
–25^{\circ}\textrm{C} &amp; 11 1001 1100 &amp; 11 1001 11.00 \\
–0.25^{\circ}\textrm{C} &amp; 11 1111 1111 &amp; 11 1111 11.11 \\
0^{\circ}\textrm{C} &amp; 00 0000 0000 &amp; 00 0000 00.00 \\
+0.25^{\circ}\textrm{C} &amp; 00 0000 0001 &amp; 00 0000 00.01 \\
+10^{\circ}\textrm{C} &amp; 00 0010 1000  &amp; 00 0010 10.00 \\
+25^{\circ}\textrm{C} &amp; 00 0110 0100 &amp; 00 0110 01.00 \\
+50^{\circ}\textrm{C} &amp; 00 1100 1000 &amp; 00 1100 10.00 \\
+75^{\circ}\textrm{C} &amp; 01 0010 1100 &amp; 01 0010 11.00 \\
+100^{\circ}\textrm{C} &amp; 01 1001 0000 &amp; 01 1001 00.00 \\
+125^{\circ}\textrm{C} &amp; 01 1111 0100 &amp; 01 1111 01.00 \\
+127^{\circ}\textrm{C} &amp; 01 1111 1100 &amp; 01 1111 11.00 \\
\end{array}
$$

NOTE: I rarely convert things to floating point in embedded work. Data comes into the software in binary formats. Data goes out of the software also in binary formats. There is rarely a need to convert to floating point, in between. Doing so uses mathematics where the constants are truncated and the operations truncate the results and the usual rules in math don't always apply well. Plus, it costs a lot of TIME and SPACE overhead, too. So I have to have a very good reason to use floating point -- other than mere convenience.

You face a problem with 10-bit twos-complement in embedded programming. It's rare that you actually have a 10-bit processor. More common is 8, 16, and 32 bit. Since the result is 10 bits in size, let's go with a 16 assumption about a word size you can use.

I don't know how you actually clock in this 10-bit value into memory, but it's likely that it will either be in the upper 10 bits of a 16 bit result or else in the lower 10 bits. Either way, it's likely that the remaining 6 bits are all zero.

I'm pretty much going to have to assume a programming language for the following code example because the details matter here. I'll use C since it is commonly used.

So here are two functions that will do the job. Which one to use depends on where the value is at (upper 10 or lower 10.) I'll use a special value type of "uint16_t" to indicate an unsigned 16-bit value and "int16_t" to represent a signed 16-bit value.

/*  10-bit value is in upper 10 bits of the 16-bit value 'v'

    Since the value is in the upper 10 bits, just tell C that it
    is signed instead of unsigned, then tell C to cast that into
    a float. C will preserve the signed value during that conversion.
    However, C still considered it to be an integer so there are no
    decimal parts and the value will be 256 times the actual value,
    intended. This is because there are 2 decimal bits in the value
    itself and another 6 unused '0' bits, totaling 8 bits (256) that
    need to be accounted for. So it finally divides by 256.0 in order
    to achieve that final adjustment.
*/
float cvtupper10( uint16_t v ) {
    return ((float) ((int16_t) v)) / 256.0;
}

/*  10-bit value is in lower 10 bits of the 16-bit value 'v'

    This code replicates the logic indicated in the above function,
    except that the 10-bit value here starts out in the lower 10
    bits. Therefore, a 6-bit upward shift is made before performing
    the rest of the operations discussed above.    
*/
float cvtlower10( uint16_t v ) {
    return ((float) ((int16_t) (v &lt;&lt; 6))) / 256.0;
}


You only should use ONE of the above functions, not both. Which one depends upon what kind of 16-bit result you have from clocking in your 10-bit value.