Actually, it is a particular "primitive polynomial". Such polynomial CRC 
generators are implemented in hardware as a shift register with feedback points 
corresponding to the non-zero terms of the polynomial. The result of shifting 
bits into the register is generation of a pseudo-random sequence of the maximum 
length possible for the number of bits in the register.

Things like tape or disk drive error correction schemes make use of a 
particular primitive polynomial. My first experience with doing these (in APL) 
was for generating, the first ever written, 6250 bpi tape documents c. 1969.

- joey

On 2009 Nov 27, at 19:32 , Henry Rich wrote:

> CRC is controlled by a fixed 'polynomial', which is divided into a 
> bigger polynomial that is specified by the input data.  The remainder is 
> what you call the CRC of the data.
> 
> 128!:3 allows you to specify the polynomial as x.  If you don't specify 
> one, you get _306674912 = 0xEDB88320 which is the IEEE 802.3 polynomial:
> 
> x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 +
>   x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
> 
> If you want a different polynomial, you can supply one.  The 
> implementation processes the input a byte at a time, which requires the 
> precomputation of a table.  If you assign x&(128!:3) to a name, the 
> precomputation time will be spent only when the name is assigned.
> 
> Henry Rich
> 
> Don Guinn wrote:
>> If you look at the low-order 32 bits, they are the same. For CRC32 that is
>> all that counts. What surprised me was that there are several versions of
>> CRC calculations. I wonder which one J computes.
>> 
>> On Fri, Nov 27, 2009 at 7:37 PM, 0j1 <[email protected]> wrote:
>> 
>>> It looks like the high 32 bits of the 64-bit version are all-1s so on
>>> J64 the result would always be negative.
>>> 
>>>  ($~16) #: _3606737805 688229491x
>>> 15 15 15 15 15 15 15 15 2 9 0 5 8 12 7 3
>>> 0  0  0  0  0  0  0  0 2 9 0 5 8 12 7 3
>>> 
>>> 
>>> bill lam wrote:
>>>> On Fri, 27 Nov 2009, Don Guinn wrote:
>>>>> The last 32 bits are the same. It's just that the number is too big for
>>> 32
>>>>> bit representation.
>>>>> 
>>>>>   (2x^32)+_3606737805x
>>>>> 688229491
>>>> If crc in J32 is 688229491 how can it tell if that for J64 will be
>>>> _3606737805 or still be 688229491?
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>> 
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>> 
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to