Diskussion:Zyklische Redundanzprüfung/Archiv

message: Da sich offensichtlich noch keiner getraut hat, habe ich mal den Mehrheitsbeschluss von dieser Diskussionsseite umgesetzt und die deutsche Abkürzung durch die englische ersetzt.
--83.135.133.111 12:42, 19. Dez 2005 (CET)
thread_title:  Englische Abkürzung 

message: Hallo, ich finde hier fehlt ein Beispiel, und vielleicht könnt
ja jemand, der es verstanden hat das Beispiel 
vervollständigen.
Beispiel zur Berechnung der CRC-32:
Also nehmen wir an, ich habe die Zeichenkette 
"VOGEL" , dann ist die ganz praktische Frage, 
welche CRC hat das Datenwort "Vogel"
das gibt als Ascii Werte folgendes :
     Dez.   Binär
V -> 086 -> 01010110       
O -> 079 -> 01001111             
G -> 071 -> 01000111                
E -> 069 -> 01000101                      
L -> 076 -> 01001101                       
daraus ergibt sich
          0 1 2 3 4                                5 
          e e e e e                                e 
          t t t t t                                t 
          y y y y y                                y 
          B B B B B                                B 
    
Bit 7 >   0 0 0 0 0                                 
Bit 6 >   1 1 1 1 1     Prüfsummenrechnung >        
Bit 5 >   0 0 0 0 0                                
Bit 4 >   1 0 0 0 0                                 
Bit 3 >   0 1 0 0 1                                 
Bit 2 >   1 1 1 1 1                                  
Bit 1 >   1 1 1 0 0                                 
Bit 0 >   0 1 1 1 1                                  
Frage wie kann ich nun mit hilfe des 
Prüfpolynoms 
 CRC-32: 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
das Ergebnisbyte (5tes Byte Berechnen ?????)
vielleicht kann da ja jemand weitermachen, so das man es versteht.
Welche Prüfsumme hat das Datenwort "Vogel" ? und wie kommt man da hin ?
wie berechnet man dies ?
:Das Ergebnis ist ein 32-Bit-Wert. CRCs werden bitweise berechnet, also kann man die Bytes von links nach rechts oder von rechts nach links in bits zerlegen. Im ersten Fall ist das Ergebnis von "VOGEL" 0xa75cb680, wie folgendes Programm (in Perl) zeigt:
    #!/usr/bin/perl
    $DATA[0]=ord('V');
    $DATA[1]=ord('O');
    $DATA[2]=ord('G');
    $DATA[3]=ord('E');
    $DATA[4]=ord('L');
    sub crc_calc
    {	for $i (0..7)
    	{	$bit=$w & (2**(7-$i));
    		$bit=1 if $bit;
    		$hbit=($CRC & 2**31) ? 1 : 0;
    		$CRC<<=1;
    		$CRC &= 0xFFFFFFFF;
    		if ($bit != $hbit) {
    			$CRC ^=$POLY;
    		}
    	}
    }
    $POLY=0x04c11db7; # CRC-32 Polynom
    $CRC=0; # always use 0 for polynom division, 0xFFFFFFFF for CRC-32
    for $w (@DATA) {
    	crc_calc;
    	printf "%x %x\n",$w,$CRC; # Invert for CRC-32 (not shown)
    }
Beachte aber, dass der Standard-CRC32 als Startwert 0xFFFFFFFF verwendet und das Ergebnis invertiert. VOGEL ergibt dann 0x1fb3f2e3.Hubi 13:30, 30. Sep 2005 (CEST)
thread_title:  Beispiel 

message: Prüfsummen entstehen nicht nur technisch gesehen durch Addition.
Grundsätzlich entstehen Summen bei einer Addition.
So wie halt Produkte bei Multiplikation entstehen und Differenzen bei Division usw. 
;-) ;-) ;-)
Kleiner stilistischer Fehler
:1. Unterschreib deine Beiträge bitte. Das geht mit --~~~~
:2. Verzichte bitte auf Ironie und bloße Anspielungen und beschreibe stattdessen deutlich, was dein Anliegen ist.
:3. Der Urvater der Prüfsumme ist das Paritätsbit. Dieses wird durch Addition in \mathbb{Z}_2 berechnet, es handelt sich also wirklich um eine Summe. Der Begriff Prüfsumme hat sich so sehr eingebürgert, dass es bei der komplexeren zyklischen Redundanzprüfung beibehalten wurde.--MKI 15:14, 2. Jun 2005 (CEST)
thread_title:  Prüfsumme 

message: Hallo, ich denke das Verfahren ist missverständlich formuliert. Der Satz "Die Bitfolge der Coderepräsentation der Daten wird durch ein vorher festzulegendes Polynom (das ZRP-Polynom) mod 2 dividiert" hat für mich nämlich keinen Sinn. Was dividiere ich nun womit? Die Datenbitfolge modulo das CRC Polynom, oder was? Für mein mathematisches Verständnis ist hier ein Teiler zuviel. Entweder ich teile durch das CRC Polynom oder durch 2. Andererseits kann man das auch als Bitfolge % CRC Polynom % 2 verstehen.  
Leider kann ich auch nicht sagen, wie das korrekt vor sich geht, daher bitte ich jemanden der das Verfahren kennt, das eindeutiger auszudrücken. Achso und auch für "CRC" statt "ZRP" -- Metal 16:50, 20. Jun 2005 (CEST)
thread_title:  Verfahren 

message: Ich habe das Beispiel ein wenig ergänzt. Ich hoffe ich habe bei der Rechnung keinen Fehler gemacht, wäre nett, wenn da noch mal jemand drüber gucken könnte. --Billen 00:31, 12. Aug 2005 (CEST)
thread_title:  Beispiel 

message: Ist "Theoretische Informatik" denn hier die richtige Einordnung? Wäre für ein so oft eingesetztes Verfahren nicht eher "Angewandte Informatik" oder "Praktische Informatik" besser? 23:46, 31. Okt 2005 (CET)
replies: text: Theoretische sicher nicht. Stern 11:58, 11. Jan 2006 (CET)
thread_title:  Kategorie Theoretische Informatik 

message: Ich weiß nicht, ob ich hier auf dem Schlauch stehe, oder wo sonst der Hund begraben liegt. Wenn ich den C-Code aus dem Beispiel übersetze und ausführe, komme ich zu einer anderen Prüfsumme, als andere Beispiele mit Lookup Table errechnen (10001100 ist ja das gespiegelte Bitmuster von ASCII '1'). Ausprobiert habe ich sowohl das genannte Bitmuster, als auch sein Spiegelbild.
Christoph -- Chrisgb 13:56, 1. Feb 2006 (CET)
thread_title:  Beispiel für CRC32 verifiziert? 

message: Es wird hier viel über "korrekt" und "nicht korrekt" diskutiert. Mathematisch ist das Ergebnis einer Division, auch einer Polynomdivision, eindeutig festlegt. Nicht Gegenstand der Mathematik ist, wie man ein Polynom durch eine Bitfolge darstellt. Hier sind zwei Verfahren üblich: einmal wird das Bit, das in der Ganzzahl-Darstellung den Wert 2^n hat, als Koeffizient des Polynoms an der Stelle X^n verwendet. Beim anderen Verfahren wird das in der Ganzzahl-Darstellung niederwertigste Bit für den höchsten Koeffizienten verwendet. Korrekt sind sie beide, nur muss man beim einen Verfahren die Bits von links nach rechts, und beim anderen von rechts nach links lesen. Das muss man natürlich sowohl für die Datenbits, als auch für das Generatorpolynom machen.
Warum macht man das? Bei der Hardware-Implementierung mittels Schieberegister werden die Bits in der Reihenfolge angeliefert, in der sie übertragen werden. Bei serieller Übertragung (z.B.) Ethernet, ist es üblich, das niederwertigste Bit eines Bytes zuerst zu übertragen. Daher entspricht hier das niederwertigste Bit dem höchsten Koeffizienten.
Bei der Implementierung in Software gibt es aus diesem Grund Verfahren, die erst mal alle Bits in einem Byte spiegeln, dann die Berechnung durchführen, und am Ende das Ergebnis wieder spiegeln. Bei Ross Williams heisst dieses Verfahren "Reflection". 
Das funktioniert zwar, scheint mir aber "von hinten durch die Brust ins Auge zu sein". Ich habe deshalb vor einiger Zeit ein paar C++ - Klassen entwickelt, die einen CRC-Algorithmus unabhängig von der Bit-Darstellung implementieren. Für die Darstellung gibt es eigene Klassen, die dann im Algorithmus als Templates verwendet werden. Das Ganze ist öffentlich (GPL) und unter http://www.aweiler.com/crc/index.html zu finden.
---aw- 11:55, 6. Mai 2006 (CEST)
thread_title:  "Korrekter" CRC 

message: Was bedeuten die dort? 
 199 UDMA_CRC_Error_Count    0x000a   200   253   000    Old_age   Always       -       698
(ich hab am meisten ... juhu :/) – Simon Diskussion/Galerie 10:21, 9. Okt. 2006 (CEST)
thread_title:  CRC-Fehler im [[Self-Monitoring, Analysis and Reporting Technology|SMART]]-Log 

message: * http://www.joegeluso.com/software/articles/ccitt.htm
--Cybot 08:05, 24. Okt. 2007 (CEST)
thread_title:  Linkvorschlag 

message: Hallo zusammen,
ich habe drei Bilder mit der Realisierung als Schieberegister gezeichnet. Vielleicht möchte einer der Autoren noch Rückmeldung geben, bevor ich es einfüge.
Das erste Bild ist die Standardschaltung. Daten serielle Zuführen und anschließen noch 4x mit Nullen nachtakten um die Polynomdivision abzuschließen. Der Rest steht nun in den D-FF gespeichert.
Die nächsten zwei Bilder sind das selbe mit kleiner Erweiterung. Daten seriell Zuführen, ohne nachzutakten, denn der Rest der Polynomdivision steht bereits in den Registern. Die untere Variante enthält noch einen Multiplexer. Während die Daten durchgeschoben werden steht MUX auf 1 und zum seriell ausgeben des CRC-Werte geht MUX auf 0. Ein CRC kann quasi im Durchgang erzeugt werden.
--Biezl ✉ 20:10, 21. Jul. 2008 (CEST)
replies: text: Hi Biezl, hat es einen tieferen Grund, warum die FF-Anschlüsse (D, Q und R) spiegelverkehrt dargestellt sind?--wdwd 14:48, 22. Jul. 2008 (CEST)
replies: text: Hi wdwd, Die D-FFs sind an der Horizontalachse gespiegelt, da sie entgegen der üblichen vlnr-Richtung arbeiten. Ich habe für das mittlere eine Alternative hoch geladen. Eventuell ist das weniger verwirrend. --Biezl ✉ 18:04, 22. Jul. 2008 (CEST)
replies: text:  Hi Biezl, Spieglung betrifft den Text, also die Symbole D, Q und R welche gespiegelt dargestellt sind. Im mittleren, neu hochgeladenen ist der Text nicht mehr gespiegelt. Kann der Text in den Symbolen trotz "umgedrehter" Arbeitsrichtung normal (nicht spiegelverkehrt) belassen bleiben? (Hmm, oder ist das ein eigenartiger SVG-Fehler? - hab bei mir den SVG2PNG-Konverter über wiki aktiv. SVG native kann mein Browser nicht.) --wdwd 20:40, 22. Jul. 2008 (CEST)

text:  Nachtrag, hier ein Link wie es als PNG ausschaut.--wdwd 20:45, 22. Jul. 2008 (CEST)
replies: text: Die spiegelverkehrten Buchstaben sind schon Absicht von mir, die wurden mit gespiegelt (kein SVG-Problem, WP:PMS). Nicht gespiegelte Buchstaben finde ich schauen noch verwirrender aus. Man könnte meinen es wär ein rückwärts arbeitendes D-FF, da die Buchstaben eine gewisse Arbeitsrichtung vermitteln. Ist die zweite Version annehmbarer? --Biezl ✉ 21:40, 22. Jul. 2008 (CEST)
replies: text:  Zweite Version ist meiner Meinung ok.--wdwd 22:18, 22. Jul. 2008 (CEST)
thread_title:  Bilder mit Schieberegister 

message: Hallo,
ich würde folgendes gern noch präzisieren.
Vor Beginn der Übertragung bzw. Kopie eines Blocks der Daten wird ein CRC-Wert berechnet. Nach Abschluss der Transaktion wird der CRC-Wert erneut berechnet.
Von welchem Teilnehmer der Übertragung (Sender, Empfänger) wird der CRC-Wert berechnet? Vor Beginn vom Sender, nach Übertragung vom Empfänger?
Grüße k00ni 18:21, 21. Okt. 2008 (CEST)
replies: text: Habe den Einleitungsteil etwas gestrafft und den Passus mit der Transaktion herausgenommen. Letztlich kommt es nicht darauf an, ob der Sender die Berechnung vor oder während der Übertragung durchführt, und auch nicht, ob der Empfänger die Berechnung während oder nach der Übertragung durchführt. Wichtig ist, dass beide denselben Algorithmus ausführen. Wenn das "sauber" gemacht wird, braucht man auch keine Sonderbehandlung für den CRC-Wert. D.h. es ist nicht notwendig, den CRC-Wert mit einem Original zu vergleichen, sondern der Empfänger berechnet den CRC über den gesamten Datenblock, inkl. des vom Sender angefügten CRC-Werts. Da es sich bei diesem Wert um den Rest der Division handelt, muss bei der um den CRC-Wert angereicherten Nachricht der Rest Null herauskommen (Berechnung modulo 2). Soweit die Theorie. In der Praxis führen Implementierungsdetails dazu, dass nicht Null, sondern ein konstanter Wert (das sogen. "Residuum") herauskommt. Diese Details habe ich aber in der Einführung weggelassen. Bei Interesse weitere Erläuterungen hier.
-- -aw- 12:26, 24. Jul. 2009 (CEST)
thread_title:  Detailierter bei Einleitungssätzen 

message: Hi Community,
möglicherweise steh ich auf dem Schlauch un überseh was, aber wenn ich nach CRC und XModem google stoße ich immer auf das Polynom x^16 + x^12 + x^5 + 1, nie auf x^16 + x^15 + x^10 + x^3. Zudem kommt es mir komisch vor, dass dieses Polynom kein x^0=1 enthält. Kann mir das einer erklären und ggf. im Artikel ergänzen?
: Das Generatorpolynom für XModem ist x^{16} + x^{12} + x^5 + 1. Das ist das unter dem Namen CRC-CCITT wohlbekante Polynom. Bei x^{16} + x^{15} + x^{10} + x^3 handelt es sich um eine falsche Interpretation von 0x8408. Diesen Wert muss man von rechts nach links lesen, dann ergibt sich auch wieder das CCITT-Polynom. Das liegt daran, dass CRCs ursprünglich für die Sicherung von seriellen Datenübertragungen verwendet wurden. Bei diesen wird traditionellerweise das niederwertigste Bit zuerst übertragen. Bei der Berechnung des CRCs trägt aber das zuerst übertragene Bit den höchsten Polynom-Koeffizienten.
: Dein Verdacht mit x^0 = 1 ist richtig. Ein Blick in ein Buch über algebraische Codierungstheorie zeigt, dass das Generatorpolynom ein Teiler von x^n + 1 sein muss (wobei n die Blocklänge des Codes ist). Diese Teilbarkeit kann aber nicht gegeben sein, wenn es ein Vielfaches von x (oder x^3) ist.
-- -aw- 12:45, 24. Jul. 2009 (CEST)
thread_title:  XModem CRC 

message: Hallo, im Abschnitt Erkannte Fehler steht 'Da T(x) / G(x) = 0...', es wird also impliziert der Rahmen (mit Anhang) geteilt durch Generatorpolynome müsse bei korrekter Übertragung von T(x) Null sein. Dies erscheint mir falsch. Der Quotient wird schon wieder ein Polynom > 0 sein, es darf lediglich kein Rest-Polynom bleiben. Muss es also nicht heißen, T(x) modulo G(x) = 0? Auch die darauffolgende Rechnung bzgl. E(x) ist dann zu überarbeiten. -- 213.61.222.21 (09:17, 29. Apr. 2010 (CEST)
thread_title:  Quotient muss nicht Null sein 

message: Hallo, die Zeile mit "SD/MMC-Card (CRC-7)" im Abschnitt "Polynome und Typen" ist offensichtich ein Versehen. Ich glaube, das angegebene Generatorpolynom ist nicht der (63,57)-Hamming-Code, sondern der (127,120)-Hamming-Code (vgl.  Zyklischer Hamming-Code). Über fachmännische Korrektur (falls möglich) würde ich mich freuen. MfG, --Rad238 13:24, 16. Nov. 2009 (CET)
replies: text: korrigiert.--wdwd 13:30, 11. Apr. 2010 (CEST)
thread_title:  Polynome und Typen 

message: hallo, was mir hier ein wenig fehlt, ist die Mathematik hinter der CRC-Berechnung. was haltet ihr davon? ich frage natürlich aus einem grund: ich kenn mich selber nicht aus, muss ich zu meiner Schande eingestehen. Ich weiss zwar, dass das Generatorpolynom irreduzibel sein muss, dass XOR anstelle einer Division deswegen eingesetzt werden kann, weil es sich um eine Operation in GF(2) handelt - aber warum das Ganze, das bleibt mir verborgen.
Noch eine Frage: ist die 1-Bit Prüfsumme eigentlich äquivalent zu CRC-1? (nicht signierter Beitrag von 81.10.251.217 (Diskussion | Beiträge) 19:52, 25. Apr. 2006 (CEST)
thread_title:  Mathematik dahinter 

message: S.M.A.R.T. protokolliert lediglich auftretende Fehler (unter anderem
CRC-Fehler), die CRC-Prüfung selbst ist jedoch Teil des
ATA-Protokolls, und wird nicht - wie im Artikel angeführt - von
S.M.A.R.T. durchgeführt. (nicht signierter Beitrag von 84.173.226.77 (Diskussion | Beiträge) 04:58, 17. Jan. 2007 (CET)
thread_title:  S.M.A.R.T.-Beispiel ziemlich daneben 

message: Ich würde zu Beginn eine leichter verständliche Angabe machen, um ... linepiece (nicht signierter Beitrag von 91.113.7.18 (Diskussion) 21:26, 12. Jul 2010 (CEST)
thread_title:  Allgemein 

message: Das Generatorpolynom G(x) = x^{16} + x^{15} + x^2 + 1 (IBM-CRC-16) lässt sich als G(x) = (x^{15} + x + 1)(x + 1) faktorisieren.
Wenn ich G(x) = (x^{15} + x + 1)(x + 1) in Maxima eingebe und expandiere kommt x^{16} + x^{15} + x^{2} + 2x + 1 raus und das ist ja nicht mehr das Generatorpolynom oder? (nicht signierter Beitrag von 188.99.137.194 (Diskussion) 09:32, 28. Nov. 2011 (CET)
replies: text: Sie müssen im GF(2) rechnen, nicht in \N. Dies ist kein Hausaufgabenhilfe Forum. --Moritzgedig 16:19, 7. Feb. 2012 (CET)
thread_title:  Erkannte Fehler, Beispiel, Begründung ist falsch 

message: CRC codes sind eine Untermenge der zyklischen codes, nämlich jede die in P(x)*(x+1) zu zerlegen sind, wobei P(x) nicht zerlegbar sein darf. Dieser Artikel ist falsch da er nicht unterscheidet, er behandelt Zyklischer_Codes und geht nicht auf die Besonderheiten von CRC ein. --Moritzgedig 16:41, 7. Feb. 2012 (CET)
thread_title:  Zyklischer Code ungleich CRC 

message: Wir betrachten den 3-Bit-breiten CRC-Code mit dem Generatorpolyom g(x) = x. Die Codewörter sind 000, 010, 100 und 110.
Wäre der Code zyklisch, dann müsste auch 001 ein Codewort sein, was nicht der Fall ist. (nicht signierter Beitrag von 109.193.168.154 (Diskussion) 13:35, 20. Feb. 2012 (CET)
replies: text: Hä? G(z)=z ist kein Generatorpolynom. --Moritzgedig 21:26, 22. Feb. 2012 (CET)

text: Das Generatorpolynom g(x)=x hat den Grad 1 und ist so in der Lage 0-Bit fehler zu erkennen. Nicht wirklich das, was gewünscht ist, oder? Abgesehen davon: Warum behauptest du 001 sei kein Codewort? --P.C. ✉ 18:31, 28. Feb. 2012 (CET)

text: Wenn Du schon bei solchen Überlegungen bist: Überleg Dir, welchen Ring du da gerade aufspannst, und welche Elemente eventuell identisch sind. Also anders gefragt: In welcher deiner Ringklassen liegt 001. --P.C. ✉ 08:53, 29. Feb. 2012 (CET)
thread_title:  Nicht jeder CRC-Code ist zyklisch! 

message: Bei der Faktorisierung von CRC-8 (ITU-T) fehlt meines Erachtens der Term x^4. Vgl. z.B. http://www.ee.unb.ca/cgi-bin/tervo/factor.pl?binary=100000111. Habe den Artikel gerade entsprechend angepasst und bitte um Verifizierung. Danke :) --Plainalt (Diskussion) 23:33, 9. Mai 2012 (CEST)
thread_title:  Faktorisierung von CRC-8 (ITU-T) 

message: Im Text steht:
"Ein CRC-Algorithmus kann also jeden Fehler erkennen, der innerhalb der angegebenen maximalen Länge weniger als MHD - 1 Bit-Positionen betrifft."
Meiner Meinung müsste das enteweder:
" .. Länge weniger als MHD Bit-Positionen.." heissen, oder:
" .. Länge höchstens MHD - 1 Bit Positionen..". (nicht signierter Beitrag von 88.66.7.35 (Diskussion) 10:43, 11. Jul 2012 (CEST)
thread_title:  MHD, Hamming Distanz 

message: Wenn man den Text mit dem englischen Text vergleicht, dann fällt auf, daß im Englischen wirklich bitweise dividiert wird.
Auch wenn da bei Zwischenwerten führende #0'en stehen.
Das würde es etwas klarer machen, wenn man dies erst strikt so durchführt und anschliessend ausführt, dass man führende #0'en einfach weiterreichen kann und erst wieder wirklich dann dividieren muß, wenn man wieder eine führende #1 erreicht hat. (nicht signierter Beitrag von 193.0.246.4 (Diskussion) 15:16, 5. Feb. 2015 (CET)
thread_title:  Beispiel optimiert zu früh 

message: [...] Da G(x) nicht durch x teilbar sein kann [...] Woraus folgt das formal? Vermutlich will man irreduzibel, ungleich 0 und ungleich x, oder? Falls das schon wo stehen sollte (ich hab's nicht gefunden), sollte es hier nochmals erwähnt werden. Xlae (Diskussion) 09:15, 10. Mär. 2015 (CET)
thread_title:  Abschnitt '''Zwei isolierte Einbitfehler''' 

message: Diese Erklärung lässt nicht erkennen was die CRC gegenüber einer normalen Prüfsumme "besonders" macht. Es ist kein Unterschied zu erkennen. Dieser Artikel ist somit redundant. (nicht signierter Beitrag von 91.141.2.124 (Diskussion) 11:38, 19. Jun. 2016 (CEST)
thread_title:  CRC versus "normaler" Prüfsumme 

message: Der Pseudocode ist leider sehr unverstaendlich:
Was ist n? hier fehlt eine Definition. CRC32 hat ein Generatorpolynom vom Grad 32 also 33 Koeffizienten.
Was ist das "naechste" Bit aus dem Datenstrom? Vermutlich das naechste Bit beginnend beim MSB und dann pro Iteration ein weiter in Richtung LSB?
Hier fehlt eine Definition!
Wenn das Schieberegister beim CRC32 'nur' 32-Bit lang ist, wie dann das bitsweise xor mit einem 33 Bit langen Erzeugerpolynom gebildet?
Das ist voellig unklar. (nicht signierter Beitrag von 80.152.50.109 (Diskussion) 16:51, 24. Jan. 2017 (CET)
thread_title:  Definitionen unklar 

message: Ist es möglich, dass die CRC-Prüfung als Kopierschutz für DVD's eimegsetzt wurde? Wenn der DVD-Rekorder auf eine CRC-Prüfung verzichetet, der Computer aber nicht, dann können DVD's vom PC nicht gelesen werden. Anders formuliert: Werden absichtlich CRC-Fehler auf die DVD gebrannt, kann die DVD abgespielt, aber nicht kopiert werden.
--Rasmusklump (Diskussion) 23:45, 18. Nov. 2017 (CET)
thread_title:  CRC - Prüfung als Kopierschutz 

message: Der Pseudocode in der Umsetzung sagt sinngemäß "Wenn das MSB (höchstwertiges Bit) ungleich dem zweithöchstwertigen Bit, dann tue leftshift und XOR, ansonsten nur leftshift".
Ich habe etwas die Stirn über die Bedingung gerunzelt, denn ich kenne die Bedingung als "Wenn das MSB gesetzt ist". Mag das mal jemand prüfen? Oder kommt es gar aufs gleiche raus?
--178.10.214.14 16:15, 6. Jun. 2018 (CEST)
thread_title:  Nachfrage: Umsetzung 

message: Dieser 11:49, 29. Jul. 2020‎ von "VermCad" eingeführte Beispielcode enthält m. E. eine falsche Zeile:
...
CRC := CRC xor (B shl 8);
...
Der Ausdruck "B shl 8" heißt ja wohl, dass der Inhalt des Bytes B achtmal nach links verschoben wird. Beim jedem Linksshift tritt das höchstwertige Bit nach links aus und ist verloren. An die niederwertigste Stelle des Bytes wird ein Null-Bit eingeschoben. Das alles achtmal, sodass das Byte B auf jeden Fall anschließend Null ist. Wird dann das Wort CRC mit dem entstandenen Null-Byte XOR-verknüpft, ändert sich an dessen Wert genau nichts. Wozu also dieses Statement?
Vermutlich müsste die Variable B vom Typ Word sein, damit dann die XOR-Verknüpfung zwischen dem höherwertigen Byte vom Wort CRC und dem von B stattfindet. Ich hoffe, dass der Compiler aber nichts gegen die Zuweisung B := Buffer[I] hat (Zuweisung eines Bytes an eine Word-Variable). Der Typ von Buffer ist hier nicht deklariert, nur in der Überschrift als "Array of Byte" erwähnt. 
Alternativ könnte man folgende Formulierung (hier als Pseudocode) schreiben:
...
CRC := HighByteOf(CRC) xor B;
...
--Golter (Diskussion) 13:07, 13. Mär. 2021 (CET)
replies: text: Alle Arithmetik, auch Bitschnipselei, findet vom Prinzip her 32bittig statt (früher 16bittig, aber auch historisch nie 8bittig). Entsprechend der Zielgröße wird dann rückkonvertiert oder, in vom Compiler beweisbaren Fällen, tatsächlich hin zu einem kürzeren Ergebnistyp optimiert. Jedenfalls liefert (B shl 8) dasselbe wie (B * 256). – Hi…ma 22:21, 4. Sep. 2021 (CEST)
thread_title:  CRC-CCITT Implementierung in der Programmiersprache Pascal/Delphi