I understand now. Thanks. On Fri, Nov 27, 2009 at 10:39 PM, Joey K Tuttle <[email protected]> wrote:
> 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
