From: nonsense on 18 Mar 2007 08:43 Martin Brown wrote: > The trouble for fuBAH is that generating a file containing a self > consistent checksum or CRC requires the use of a programming algorithm > (which instantly conflicts with her rabid Islamophobia). So either way > her head explodes. You never quite got over Monty Python, eh?
From: jmfbahciv on 18 Mar 2007 09:05 In article <1174221298.287074.230690(a)l75g2000hse.googlegroups.com>, "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote: >On Mar 16, 2:55 pm, kensm...(a)green.rahul.net (Ken Smith) wrote: >> In article <1173976773.203668.217...(a)l75g2000hse.googlegroups.com>, >> >> Martin Brown <|||newspam...(a)nezumi.demon.co.uk> wrote: >> >> >Unhinged is wrong though - the problem is onlyselfreferential. >> >> I'm going to disagree with you slightly on this. Read the following >> statement carefully: >> >> This statement is incorrect. >> >> Now imagine BAH saying "the statement is incorrectso therefor it >> must be correct so it must be incorrect ......." and so on in a higher and >> higher voice and then exploding like always happens in bad scifi. This I >> think you would agree makes the situation a problem with recursion. > >Yes. But it is an avoidable recursion. It only recurses if you are >dumb enough to let it. > >The whole point here is that anyone with a half decent computer >science education should know exactly how to construct the TAPE.DIR >file so that the checksum/CRC is right first time (or at worst know >where to look it up). > >"This statement is TRUE" > >Is true and then there is no recursion. Problem solved. > >The trouble for fuBAH is that generating a file containing a self >consistent checksum or CRC requires the use of a programming algorithm >(which instantly conflicts with her rabid Islamophobia). So either way >her head explodes. The people who are doing the work making those tapes are not programmers. Although they appear to have been more sophisticated than most participants of this thread; nevertheless, they could not be expected to edit magtapes as part of the packaging procedures. > >> failure by BAH is in fact a problem with recursion in as much as she can't >> step outside the system. >> >> >(*) The decimal checksum of this ASCII sentence is exactly 05407 >> >> >fuBAH, Unhinged and MassivelyWrong might like to check this assertion- >> >the text of the sentence starts with "(" and ends with "7" >> >> I'm sure BAH will object that you didn't write it onto tape with the >> checksum at the start. Unfortunatly, she can't get to WWW stuff. > >Isn't some IOCCC stuff online for FTP ? > >The self consistent file internal CRC generator program entry >omiokane.c was particularly amusing. The problem had nothing to do with heiuristic that was used. As long as the same heiuristic was used throughout the procedure, the manner of how the bits were folded and counted did not matter. It should never have mattered in this procedure. /BAH
From: MassiveProng on 18 Mar 2007 09:46 On Sun, 18 Mar 2007 06:43:07 -0600, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> Gave us: >Martin Brown wrote: > >> The trouble for fuBAH is that generating a file containing a self >> consistent checksum or CRC requires the use of a programming algorithm >> (which instantly conflicts with her rabid Islamophobia). So either way >> her head explodes. > >You never quite got over Monty Python, eh? > NONE SHALL PASS! Bwuahahahahaha!
From: MassiveProng on 18 Mar 2007 09:47 On Sun, 18 Mar 07 13:05:40 GMT, jmfbahciv(a)aol.com Gave us: >In article <1174221298.287074.230690(a)l75g2000hse.googlegroups.com>, > "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote: >>On Mar 16, 2:55 pm, kensm...(a)green.rahul.net (Ken Smith) wrote: >>> In article <1173976773.203668.217...(a)l75g2000hse.googlegroups.com>, >>> >>> Martin Brown <|||newspam...(a)nezumi.demon.co.uk> wrote: >>> >>> >Unhinged is wrong though - the problem is onlyselfreferential. >>> >>> I'm going to disagree with you slightly on this. Read the following >>> statement carefully: >>> >>> This statement is incorrect. >>> >>> Now imagine BAH saying "the statement is incorrectso therefor it >>> must be correct so it must be incorrect ......." and so on in a higher and >>> higher voice and then exploding like always happens in bad scifi. This I >>> think you would agree makes the situation a problem with recursion. >> >>Yes. But it is an avoidable recursion. It only recurses if you are >>dumb enough to let it. >> >>The whole point here is that anyone with a half decent computer >>science education should know exactly how to construct the TAPE.DIR >>file so that the checksum/CRC is right first time (or at worst know >>where to look it up). >> >>"This statement is TRUE" >> >>Is true and then there is no recursion. Problem solved. >> >>The trouble for fuBAH is that generating a file containing a self >>consistent checksum or CRC requires the use of a programming algorithm >>(which instantly conflicts with her rabid Islamophobia). So either way >>her head explodes. > >The people who are doing the work making those tapes are not >programmers. Although they appear to have been more sophisticated >than most participants of this thread; nevertheless, they could >not be expected to edit magtapes as part of the packaging >procedures. >> >>> failure by BAH is in fact a problem with recursion in as much as she can't >>> step outside the system. >>> >>> >(*) The decimal checksum of this ASCII sentence is exactly 05407 >>> >>> >fuBAH, Unhinged and MassivelyWrong might like to check this assertion- >>> >the text of the sentence starts with "(" and ends with "7" >>> >>> I'm sure BAH will object that you didn't write it onto tape with the >>> checksum at the start. Unfortunatly, she can't get to WWW stuff. >> >>Isn't some IOCCC stuff online for FTP ? >> >>The self consistent file internal CRC generator program entry >>omiokane.c was particularly amusing. > >The problem had nothing to do with heiuristic that was used. >As long as the same heiuristic was used throughout the >procedure, the manner of how the bits were folded and counted >did not matter. It should never have mattered in this >procedure. > NONE SHALL PASS!
From: Ken Smith on 18 Mar 2007 12:11
In article <etj6mg$8qk_001(a)s874.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <eteabl$ecf$1(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [....] >>Once again you've just changed your story. You claim that the TAPE.DIR >>was and was not made from the tape. > >That is true. That was the recursive problem I had to solve. That is not a recursive problem at all. You seem unclear on what recursive means. >> Back and forth go your claims. >>Until you settle on one story, there is very little point in continuing >>the discussion because at this point, I have ealready shown that in either >>case the checksum could have been correct. > >You still do not understand the problem nor the spec requirements. No, it is you who doesn't understand the problem. You think that something that is not recursice is recursive. You have made claims about the problem and the spec that are simply false. >>So you checked after the fact that the tape was correct. At least we have >>that part of the story straight now. > >That was always a requirement. I would really hope so. Your method of making the tape left lots of openings for errors to get in. Your TAPE.DIR was created from second generation data. [....] >>No, I think you aren't understanding. You claim that it is a directory of >>what was actually written onto the tape. This is not what it really is. > >But it was. No, it wasn't. It was in fact the directory of something else. It was neither the first generation information about what the tape should contain nor the directory of the actual tape you did write. [....] > >Acutally, I had the tape written three times. You had two extra passes on the drive. This is not a good thing to do. It takes up a lot of time. You could have verified with read reverses. Depending on the sort of drive you actually had, that would have put the tape under the least stress and saved you a whole bunch of time. [....] >>This makes it exactly the sort of thing I suggested you were doing and you >>you objected to so strongly way back earlier in this thread. > >You still do not understand the situation. Yes, I do. You seem to have now settled on a story about what you did. If you stay with this one, it would be better. At least this story doesn't require you to do things that can't really be done. BTW: You could still have had a correct checksum [....] >>No, what I suggested made the checksum stated for TAPE.DIR the correct >>checksum of TAPE.DIR and have this correct checksum in TAPE.DIR on the >>tape. Nothing forbids the checking of the checksums on the tape without >>doing a restore. > >Your procedure required human hands. That was a non-goal. No, it did not. I tried to explain to you haw the process is done. If I am telling you how to write a sqrt() routine, I may say "You shift the number to the left one place." Nobody in their right mind would take that to mean that the program you end up with requires a human to shift the number. -- -- kensmith(a)rahul.net forging knowledge |