|
Boost : |
From: Daryle Walker (darylew_at_[hidden])
Date: 2001-02-27 11:57:10
on 2/23/01 5:29 PM, Joel Young at jdy_at_[hidden] wrote:
> x^6+x^5+x^3+x^2 / x+1 should give a remainder of zero unless I screwed
> up.
>
> So the codeword for transmission to get zero remainder should then be
> the original message.
You did get a zero remainder. Ignore my earlier claim that it wasn't the
lowest bit; your initial understanding was right. The problem was I screwed
up making my masking constant. I didn't catch it before because I always
used a bit size divisible by the number of bits per byte (8). The new
version (3) of the CRC classes fixes this.
Is your given divisor (x + 1) something you made up, or is it part of an
official CRC? Maybe I should use it as a test case, but we would have to
confirm what the its CRC-value for "123456789" (my baseline data) is.
(To be more specific about my masking error: I initially created it by right
shifting the all-ones bit pattern. I thought that the compiler would make
the new bits [in the highest] positions zero for unsigned types. But it
kept the new bits high, just like for signed types. So I ended up with an
unchanged mask. This let the 1 you saw in the 16-place leak through. I
fixed the problem by left shifting an all-ones bit pattern, getting zeros in
the new [lowest position] bits, then complementing that result.)
> From: Daryle Walker <darylew_at_[hidden]>
> Date: Fri, 23 Feb 2001 15:09:12 -0500
> To: <boost_at_[hidden]>
> Subj: [boost] CRC Computation Problem (was: Re: Review Request: CRC)
>
>> on 2/22/01 11:20 AM, Joel Young at jdy_at_[hidden] wrote:
>>
>>> Question on the usage of the crc:
>>>
>>> I run the following code:
>>>
>>> {
>>> boost::crc_slow<1> crc_1(1,0,0,false,false);
>>>
>>> std::bitset<7> t = 108; //("1101100");
>>> std::cerr << t << std::endl;
>>> for (int i=t.size()-1; i>=0; --i)
>>> crc_1( t.test(i) );
>>> std::bitset<7> s = *crc_1; //("1101100");
>>> t |= *crc_1;
>>> std::cerr << t << std::endl;
>>> std::cerr << s << std::endl;
>>> }
>>>
>>> And get this result:
>>>
>>> 1101100
>>> 1111100
>>> 0010000
>>>
>>> Indicating that the remainder returned by crc_1 is way to big.
>>>
>>> Shouldn't the remainder be only one bit? Or am I misunderstanding the
>>> process?
>>
>> It is one bit, but it's not the lowest bit. Since you specified only an
>> one-bit CRC, the answer should be one or zero. I'll take a look. By the
>> way, what is the CRC supposed to be?
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk