Question-Urgent-C++
this looks familiar.
the only way I see to make this thing work cleanly is to use binary math.
that is, forcibly arrange your data so that you can just iterate binary numbers.
that is, set it up so that
000
001
010
011
100
101
110
111
are defined so that the above binary values are the index into decoded bits.
that is,
for the case when all 3 bits are zero, that is decodedbits[0].
for the case 001, that is [1], 010 is [2], and so on.
THAT is extensible to a larger problem.
You may have to rearrange some logic somewhere to make this happen, but once you do it, it should be very easy to grow the solution. I think just about any other approach, while it may work, is going to be orders of magnitude more complicated and cause more and more problems to extend it. As a bonus, the above mapping gets rid of the if statements.
it quite simply becomes decodedbits[n] ^= 1 where n is the integer from the bits, which you can get easily
unsigned int n = 0;
n= bit1 + 2*bit2 + 4*bit4+8*bit5... etc
if you get past 64 bits, some PCs have a 'hidden' 128 bit register now. If you get past *that* or don't have it, you may need to grab a big integer class or hand roll the parts you need to make it work.
the only way I see to make this thing work cleanly is to use binary math.
that is, forcibly arrange your data so that you can just iterate binary numbers.
that is, set it up so that
000
001
010
011
100
101
110
111
are defined so that the above binary values are the index into decoded bits.
that is,
for the case when all 3 bits are zero, that is decodedbits[0].
for the case 001, that is [1], 010 is [2], and so on.
THAT is extensible to a larger problem.
You may have to rearrange some logic somewhere to make this happen, but once you do it, it should be very easy to grow the solution. I think just about any other approach, while it may work, is going to be orders of magnitude more complicated and cause more and more problems to extend it. As a bonus, the above mapping gets rid of the if statements.
it quite simply becomes decodedbits[n] ^= 1 where n is the integer from the bits, which you can get easily
unsigned int n = 0;
n= bit1 + 2*bit2 + 4*bit4+8*bit5... etc
if you get past 64 bits, some PCs have a 'hidden' 128 bit register now. If you get past *that* or don't have it, you may need to grab a big integer class or hand roll the parts you need to make it work.
Last edited on
|
|
Dear @tpb thanks for your reply
could you please explain about this piece of code?
could you please explain about this piece of code?
Last edited on
It collects the bits you have in the syndrome vector into an unsigned integer and then uses that bit pattern as an index into decodedBits.
Look up the operators:
<< (shift bits to the left)
| (bitwise OR)
(1 << nrows) - 1 is the maximum value of a value with nrows bits (all 1's).
Look up the operators:
<< (shift bits to the left)
| (bitwise OR)
(1 << nrows) - 1 is the maximum value of a value with nrows bits (all 1's).
he did what I said with more concrete code.
you can shrink bit stuff into gibberish or bloat it out to be more readable, usually if you are careful neither one is significantly faster.
for example you can further shrink that by converting the if statement to a boolean expression and xor with the result. Xor against zero (false) does nothing at all, and xor 1 (true) is what you wanted.
I am still advocating storing syndrome in integer format though. So that you don't have to deal with the wasted space of an array of bytes that represent bits and the inefficiency of processing disconnected but related bytes as bits.
you can shrink bit stuff into gibberish or bloat it out to be more readable, usually if you are careful neither one is significantly faster.
for example you can further shrink that by converting the if statement to a boolean expression and xor with the result. Xor against zero (false) does nothing at all, and xor 1 (true) is what you wanted.
I am still advocating storing syndrome in integer format though. So that you don't have to deal with the wasted space of an array of bytes that represent bits and the inefficiency of processing disconnected but related bytes as bits.
It "looks" right. But I am not a computer. Run it and see if it gives the correct results?
Topic archived. No new replies allowed.