Anonymous user
Talk:CRC-32: Difference between revisions
→Size of example string
(→REXX: added KEXX to the list of REXXes that don't support signal value. -- ~~~~) |
|||
| (20 intermediate revisions by 5 users not shown) | |||
Line 53:
:: I suggest something based on [[wp:Low-density parity-check code|Gallager code]]s would be appropriately beefy, as those are used in very high performance applications like transmissions from satellites. If that doesn't satisfy you, Spekkio, I don't know what will. :-) Different task though. –[[User:Dkf|Donal Fellows]] 17:27, 11 December 2011 (UTC)
::: Thanks, that is very interesting :D --[[User:Spekkio|Spekkio]] 10:02, 12 December 2011 (UTC)
:::: Hamming numbers are the number of inverted bits in a row in the message, plus one in the checksum code, that can go wrong before it can fail to detect the error. So if you had a hamming distance of 6, as in the CRC-15 used by CANbus, then you would have up to five bits in a row that could be wrong, along with one wrong in the checksum itsself. So CANCRC15 has a hammin distance of 6. This means its very good at getting rid of electrical interference on a line: i.e. a burst error of 5 bits or less will be detected. Look up papers by Cooperman for a math description, and lots of deifferent polynomials for CRCs. [[User:Robin48gx|Robin48gx]] ([[User talk:Robin48gx|talk]]) 13:28, 23 September 2014 (UTC)
== CRC library ported to several languages ==
Line 131 ⟶ 132:
--[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 05:53, 18 August 2013 (UTC)
:: Please note that the '''signal value(...''' isn't a valid construct from some older REXXes, so PC/REXX, Personal REXX, and KEXX can't be used for
-----
Line 143 ⟶ 144:
: no check is made to verify that the value of '''D''' matches the value of the 1st argument (999999999).
:: the result is compared with the value that should be there --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 19:27, 18 August 2013 (UTC)
A '''parse version x; say x''' was added (in my version) after the 1st statement.
<br>A '''say 'digits=' digits()''' would be a nice addition.
<br><br>But in any case (all were executed under a Windows/XP DOS window (cmd.exe):<br><br>
Line 198 ⟶ 199:
-----
Perhaps this discussion would be better served where there're more (varied) REXX experts (and REXX authors) hanging around --- [such as the REXX newsgroup, '''comp.lang.rexx''']. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:00, 18 August 2013 (UTC)
:: the ticket raised by someone else should fit your request. Why can't you accept that Regina is wrong here (according to the standard? According to your tests it's the only Rexx that fails to obey the spec! BTW: I entered a doc ticket for ooRexx now because there is a wrong sentence in the C2D description. --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 19:27, 18 August 2013 (UTC)
Line 205 ⟶ 206:
::: If you're addressing those statements/questions to me: I don't think that Regina is wrong nor do I think that Regina is right. I don't feel comfortable explaining my philosophy on why or why not I accept (the correctness) of certain REXX implementations --- especially on Rosetta Code, not many REXX authors (coders/writers of REXX interpreters) visit here, as far as I can discern. In the case of Regina REXX, it has its own location for reporting (possible) bugs. I know a lot of REXX authors read (subscribe to) the '''comp.lang.rexx''' newsgroup. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 20:10, 18 August 2013 (UTC)
:::: Only ONE Rexx (Regina) did not reject that c2d invocation. Can you please update this line
<lang rexx>
numeric digits 10 /*only needed for ooRexx. */
</lang>
to something like
<lang rexx>
numeric digits 10 /*not needed for Regina. */
</lang>
"In the case of Regina REXX, it has its own location for reporting (possible) bugs."
It has been reported there (on sourceforge)! For other Rexxes there is nothing to report (except that Roo, I think it was, does not behave as the others. --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 20:21, 18 August 2013 (UTC)
:: I changed the statement, but I didn't include the comment as Regina REXX may fix/change its behaviour, so the comment may be mute, incorrect, or misleading in the future. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 20:40, 18 August 2013 (UTC)
Thanks for the change. Matter closed with these final words from Regina:
<pre>
[bugs:#413] c2d should fail if result > numeric digits
Status: closed-duplicate
Created: Fri Jul 12, 2013 11:44 AM UTC by Julian Levens
Last Updated: Mon Aug 19, 2013 12:53 AM UTC
Owner: Mark Hessling
Duplicate of [#208]. Due to potential serious breakage in existing Rexx programs,
the current default behaviour of Regina will remain;
ie x2d('3b9aca00') will not raise an error.
However with Regina's OPTIONS STRICT_ANSI this error IS trapped.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/regina-rexx/bugs/413/
</pre>
Again learned something. --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 05:18, 19 August 2013 (UTC)
== Size of example string ==
strlen("The quick brown fox jumps over the lazy dog") is 43.
Due to modern processors having specific hardware engines used to calculate CRC's that are 32 bit wide
at a time, such as the cortex M3 arm series, it would be better to have a test string that
is wholly divisible by 4. The current test string has 43 characters. adding a full stop to this
would give a strlen() of 44.
Also CRC-16 engines take 16 bit chunks at a time, and would not be compatible with the example string chosen.
strlen("The quick brown fox jumps over the lazy dog.") is 44.
cprog out: crc32 of test string <The quick brown fox jumps over the lazy dog.>44 is 1368401385 519025E9
This agrees with feeding 11 32 bit words into the arm cortex CRC engine with it
set to CRC32 and seeded with ~0.
[[User:Robin48gx|Robin48gx]] ([[User talk:Robin48gx|talk]]) 10:47, 23 September 2014 (UTC)
:*The CRC-32 references given are defined on arbitrary sized strings, not limited to multiples of four.
:*Therefore, an implementation that only supported a multiple of four would not be a correct implementation of this task.
:*Performance issues are typically not the point of Rosetta Code examples. If an implementation is optimized for four byte multiples it's just an optimization irrelevant to the task itself.
:*The example input should therefore purposely ''not'' be a multiple of four.
::—[[User:dchapes|dchapes]] ([[User talk:dchapes|talk]] | [[Special:Contributions/dchapes|contribs]]) 13:50, 23 September 2014 (UTC)
::: Yes I take your points, but 32 and 64 bit words are the norm now, as is increasing integration of
::: common tasks (such as CRCs, multiple ADC readings, zero crossing for motor control). Making this string
::: a little longer makes it compatible with blinding fast hardware circuitry. I think its just keeping up with the times.
::: CRC-32 is often used to validate a block of data, not just transmission lines.:wq --[[User:Robin48gx|Robin48gx]] ([[User talk:Robin48gx|talk]])
::::Mind you, they are still shipping shed loads of 16 and 8 bit processors as they are smaller, cheaper and more power efficient ;-)<br>--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 14:49, 3 October 2014 (UTC)
::::Robin48gx, what you say is completely irrelevant for all the reasons I gave. —[[User:dchapes|dchapes]] ([[User talk:dchapes|talk]] | [[Special:Contributions/dchapes|contribs]]) 18:01, 3 October 2014 (UTC)
| |||