Question: I have the following DataSet on a SSRS report:

```
SELECT
  VariationCode.Code
  ,VariationCoding.Comment
  ,VariationCoding.SubmissionDate
  ,VariationCoding.Id
FROM
  VariationCode
  INNER JOIN VariationCoding
    ON VariationCode.Id = VariationCoding.VariationCodeId
WHERE VariationId = @VariationId

```

I am showing static headers on the left and data on the right which works fine but I'm struggling to group the results by ID and show them as a separate table per grouping.

Grouping the row by parent using VariationCoding.Id shows one table with no grouping at all. I suspect having the headers on the left is the problem since most solutions I've seen have the headers on top.

How can I show static headers on the left and group the results by VariationCoding.Id in such a way that each result will be displayed in a separate table?

Answer: 
n bits can represent 2n different values. (The first bit can have two values \* the second bit can have two values \* the third bit can have two values \* ...)

For example, 3 bits can form 23 = 8 different bit patterns, and thus up to 8 different values.

```
000
001
010
011
100
101
110
111

```

If each bit pattern represents an integer, then an n-bit integer can represent 2n different integers. For example,

* It could represent the integers from 0 to 2n-1 inclusively  
(because (2n-1) - (0) + 1 = 2n different values).

For example,

```
  000   0
  001   1
  010   2
  011   3
  100   4
  101   5
  110   6
  111   7

```
* It could represent the integers from -(2n-1) to 2n-1-1 inclusively  
(because (2n-1-1) - (-(2n-1)) + 1 = 2n different values).

For example,

```
  100  -4
  101  -3
  110  -2
  111  -1
  000   0
  001   1
  010   2
  011   3

```

You could assign any meaning to these values, but the previously stated ranges are the ones understood by twos'-complement machines for unsigned integers and signed integers respectively.[1]

---

1. On a [ones'-complement](https://en.wikipedia.org/wiki/Ones%27_complement) machine, there are two ways of writing zero (0000...00002 and 1000...00002), so the range is only -(2n-1-1) to 2n-1-1. I think all modern machines are [twos'-complement](https://en.wikipedia.org/wiki/Two%27s_complement) machines, though.
For an unsigned integer type, the value -1 is **out of range** and cannot be represented in a variable of that type. If you try to assign -1 to an `unsigned int` a **conversion** occurs according to the rules of the C standard.

The conversion of a signed value to an unsigned integer type is specified in section 6.3.1.3p2 of the [C standard](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):

> 
> Otherwise, if the new type is unsigned, the value is 
>  converted by repeatedly adding or subtracting one more than 
>  the maximum value that can be represented in the new type
>  until the value is in the range of the new type.60
> 
> 
> ...
> 
> 
> 60) The rules describe arithmetic on the mathematical value, not the value of a given type of expression
> 
> 
> 

Assuming as in your example that `unsigned int` has a value range of 0 to 4,294,967,295 the value -1 is converted by adding -1 + 4,294,967,296 = 4,294,967,295. Note that this conversion happens regardless of how negative numbers are represented on the given system. It is the same for two's complment, ones' compliment, or sign-and-magnitude.

Note that this means that the representation of the converted value need not be the same as the representation of -1.

Using a 4-bit type as an example, converting the value -1 to an unsigned type results in the value 15. The representation of these numbers is as follows:

```none
                sign-and magnitude    ones' complement   two's complement
  -1   (signed)               1001                1110               1111
  15 (unsigned)               1111                1111               1111

```

While in the two's complement case the result of the conversion keeps the same representation, it changes in the other two cases. For one's complement the representation of -1 is the same as for 14, and for sign-and-magnitude the representation of -1 is the same as for 9.

So what other answers have described regarding two's complement is most likely how those implementations do it (i.e. reinterpreting the representation of -1 as an unsigned value), however from the perspective of C language as an abstract machine what I've described is the only correct way of performing this conversion.