Jihad needs scientists
in [Design]
|
From: jmfbahciv on 16 Mar 2007 07:11 In article <1173976773.203668.217240(a)l75g2000hse.googlegroups.com>, "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote: >On Mar 14, 11:50 am, jmfbah...(a)aol.com wrote: >> In article <1173870480.508596.143...(a)n76g2000hsh.googlegroups.com>, >> "Martin Brown" <|||newspam...(a)nezumi.demon.co.uk> wrote: >> >> >On Mar 13, 10:34 am, jmfbah...(a)aol.com wrote: > >> >> This is the point. It will never be "correct" because the file >> >> contains a checksummed listing of itself. >> >> >> <snip> >> >> >> Do the exercise. Then you will see what I'm talking about. >> >> >You really are determined to parade your ignorance. File checksums are >> >trivial to make internally consistent. >> >> >At the simplest conceptual level you could define all files to have >> >checksum=0 and add some fluff to the end of each one to make it so. In >> >this case you only need to adjust theTAPE.DIRand since you know the >> >effect of changing the bytes in the checksum representation on the >> >checksum it is relatively easy to program a self consistent solution. > >> >then self consistent solutions can be found by SMOP. >> >> It isn't a goal to have the checksum ofTAPE.DIRcorrect. It was >> a mandatory goal to have a directory of the tape on the tape. The >> tradeoff to accomplish this goal was to have the checksum of >> the fileTAPE.DIRnot match the checksum ofTAPE.DIRreported >> inTAPE.DIR. > >You could so easily have done both if you had just an ounce of >understanding. It was not possible to edit the tape as Ken would like to have everyone believe. He has assumed that each file we put on the tape was tape file; they were not. The saveset was the tape file. The EOF was written after a saveset and not after each file we were shipping. Now, I have tried to explain this to him but he doesn't seem to understand how tapes physically looked. He also seems to assume that tapes were directory media but the are not; they are unit record media. He keeps assuming that the TAPE.DIR was one, and only one, record. It was not. It was also not separated from the other files put on the tape by the magtape equivalent of an EOF. >> >> Query: Is the ability to think about this concept (Mr. unsettled >> called itrecursion) a rare ability? > >Hells bells! Clearly you cannot!!! You claim to have been in the >business and yet haven't heard of recursion. I have heard of recursion w.r.t. to the computing biz. I have not heard of this word used in the psych biz. > >Unhinged is wrong though - the problem is only self referential. There >is at worst a simple tail recursion that can be easily unwound. But >since you cannot cope with this very basic concept here is a concrete >example. > >(*) 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" > >It is the sort of elegant toy puzzle that Martin Gardner would delight >in. > >CRC16 would take a lot more effort. You are talking about techniques. I was not dealing counting techniques. I was dealing with cutting a tape master that had a directory of the tape on the tape, with no human meddling with the contents of the tape. The procedure had to be built with iron walls so that no pesky bit god could tweak any bits at the last minute. Code freeze in my work meant code freeze. If it didn't, we'ld have never shipped a product. /BAH
From: jmfbahciv on 16 Mar 2007 08:32 In article <etbicr$3ko$1(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <etb9rf$8ss_002(a)s881.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et8v9c$6oi$1(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et8hie$8ss_001(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <et6c0m$t53$7(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>In article <et5un4$8ss_002(a)s887.apx1.sbo.ma.dialup.rcn.com>, >>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>In article <et3pbr$rad$7(a)blue.rahul.net>, >>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>>>In article <et39hp$8ss_003(a)s948.apx1.sbo.ma.dialup.rcn.com>, >>>>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>>>In article <et1957$ki3$2(a)blue.rahul.net>, >>>>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>>>>>In article <et0oi0$8qk_003(a)s776.apx1.sbo.ma.dialup.rcn.com>, >>>>>>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>>>>>In article <esuqfn$ds3$5(a)blue.rahul.net>, >>>>>>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>>>>>[....] >>>>>>>>>>>No, you are making the same mistake over and over. As I stated >>before, >>>>if >>>>>>>>>>>you know what you are going to put into TAPE.DIR, you can make its >>>>>>>>>>>checksum correct. No editing of a magnetic tape was needed by the >>>>>>method. >>>>>>>>>> >>>>>>>>>>Then that TAPE.DIR was not made by taking a directory of the >>>>>>>>>>tape. That was not the purpose of the file. If I had to do >>>>>>>>>>it the way you suggested, I wouldn't put the file on the tape >>>>>>>>>>since it would be a waste of tape space. >>>>>>>>> >>>>>>>>>So now you are suddenly changing your story and saying that editing of >>>>the >>>>>>>>>tape was done. >>>>>>>> >>>>>>>>There was no tape editing done. >>>>>>> >>>>>>>In that case. The tape had to be written with the TAPE.DIR in place and >>>>>>>correct on the first pass. >>>>>> >>>>>>This is the point. It will never be "correct" because the file >>>>>>contains a checksummed listing of itself. >>>>>> >>>>>><snip> >>>>>> >>>>>>Do the exercise. Then you will see what I'm talking about. >>>>> >>>>>Bin thar, dun that, got t-shirt, wore out t-shirt. >>>>> >>>>>I've done it. The idea wasn't new when I did. You just haven't >>>>>understood a very simple concept. >>>> >>>>I understood you just fine. You didn't put a directory of the >>>>tape onto the tape. >>> >>>That *proves* you didn't understand. I have explained how to make the the >>>directory have correct checksum no matter how you actually want to do it. >>>You seem to constantly fail to understand that you can creat a file that >>>has its own correct checksum. It has been done many times on many tapes >>>and on many disks. >> >>The file you put on the tape did not contain a directory of the >>tape. It was an edited file that you think may match the tape. > >Now at least you seem to perhaps have started to get a slight glimmer of >understanding. > >I was not suggesting a file that was manually edited. You have claimed to >be a developer so this part should have been obvious, but now lets >discuss this file you put on tape. It is also not a directory of the >tape. It was not made from the tape. My method did do this. > It was made from what you intended >to write onto the tape. Nope. >You wrote this file onto the tape before you >wrote the files it claimed were there. Unless you then checked the tape >to make sure that all the files you claimed to have written were actually >there, Of course this happened. In fact, there was always a bit by bit compare to ensure that the tape nor the drive had a fault while writing the tape. > this file you wrote could not be said to be a correct directory of >the tape. But it was. That's what you aren't understanding. > The method I suggested way back at the start involved exactly >this sort of check to make sure that the file I was suggesting was also a >true and correct directory. The only thing your method did was to make the checksum of the line that listed TAPE.DIR match the file TAPE.DIR if a user ever did a checksummed DIR TAPE.DIR/CHECK on the disk after he restored it. By making this nubmer correct, you invalidated all the rest of the tape. The tradeoff in my corner was no brainer. It didn't bother anybody to have the line that listed TAPE.DIR report a checksum that didn't match the real checksum number of the TAPE.DIR that had been saved to the tape. > >You seem at least to have finally settled on a claim about when you >created the TAPE.DIR. I know exactly when I created TAPE.DIR. You do not. /BAH
From: jmfbahciv on 16 Mar 2007 08:42 In article <etbjit$3ko$5(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <etba66$8ss_003(a)s881.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et90pt$6oi$7(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et8oqh$8qk_006(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>[....] >>>>Mr. unsettled did write a summary of the behaviour and why it >>>>can't be solved. He did it in 25 words or less. The magic >>>>incantation is recursion. >>> >>>The fact that you say "the magic incantation is recursion", is further >>>proof that you can't deal with it and therefor think that the problem >>>can't be solved. >> >>So far it can't be solved. If I do think of a solution, I'll be >>the darling of the comm people and revered by the physics people. >>It's a fun to think about. > > >It has been solved. It was solved long long ago. You just seem unwilling >to understand the solution. The problem has not been solved; it cannot be solved without a time machine. YOu do not understand the specification. /BAH
From: jmfbahciv on 16 Mar 2007 08:52 In article <etbkc7$3ko$6(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <etban7$8qk_001(a)s881.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et90d1$6oi$4(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et8hr5$8ss_002(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <et7ljd$bq1$5(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>In article <b33aa$45f6d225$4fe7292$20427(a)DIALUPUSA.NET>, >>>>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >>>>>>Ken Smith wrote: >>>>>> >>>>>>> In article <et5v7k$8qk_001(a)s887.apx1.sbo.ma.dialup.rcn.com>, >>>>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>> [....] >>>>>>> <snip> >>> I have explained how to make TAPE.DIR have the >>>right checksum for all posible cases of how you did things. >> >>Your methods require a human intervention which is called >>editing. The minute you close the file, that file is no >>longer a directory of the tape; it is a file that you think >>is a directory of the tape. > >No it does not require any such thing. You still haven't understood. >Think about any step you think a human must do and ask yourself the >question "does this step need to be done by a human?". You can also ask >yourself the questions "Who wrote the directory command?", "What do we >mean by directory" and "What really is a file?" I could try to teach you the answers to these questions but I don't think you are able to learn the material. > >> >>> This is just >>>responding to unsettled further incorrect statement about how tape drive >>>operate. >>> >>>When you disagreed with my suggestion that TAPE.DIR is list of what you >>>intended to write onto tape, I could see that there was a way that you >>>could actually have done what you at that point were claiming. You have >>>now changed the claim. You no longer say that it is the directory of what >>>is on the tape >> >>What!?? You need reading comprehension eye glasses. > >Its is exactly what I said. If you did not create the TAPE.DIR from the >tape its self, I did create the file from a directory of the tape. > you did not really create a directory of the tape. You >created a directory of what you intended to put onto the tape. Not at all. The TAPE.DIR file contained a checksummed directory of the tape that was made. > After you >made this file you then attempted to write it and what it claimed was also >there onto the tape. After I made the file, I resaved the tape with that file at the beginning of the save set; it was another requirement that the file be the first file. > > >> >>>but is as I had suggested the directory of what you >>>intended to write onto tape. >> >>The script that creates the tape is already a list of what >>I intended to put on the tape. What is needed is a directory >>of the tape on the tape. To be useful, it has to be the first >>file of the saveset of the tape. Your methods don't do this. > >Yes, my methods do. You simply haven't understood perhaps both what you >were really doing and what I have suggested. I have suggested a method by >which the TAPE.DIR can be correct and can be the first file on the tape. But you don't satisfy the primary condition that the file be a file that was made by doing a directory of the physical tape. > > >[....] >>>>But your edit write would not include the directory of the tape >>>>after you wrote it. >>> >>>Oooops!!!! There you go again. Which is it. Is it (A)the directory of >>>what you wrote or (B) the directory of what you intend to write. >>> >>>This is getting silly because your story changes back and forth on this. >> >>You are interpreting my posts as going back and forth because that >>is the nature of the problem. unsettled called this recursion. > >No, you keep changing your story. In this post you have said that >TAPE.DIR is created before the tape is written. Yes. > Elsewhere you have >protested that TAPE.DIR must be a directory of what was actually written >onto the tape. Yes. That is what the recursion problem is. > >Unsettled has called something else, not this, recursion. This is because >he also did not understand what you were really faced with. He did not >know about the abilities of tape drives and he assumed what you had said >in one of your post was correct. Mr. unsettled read my specification and seems to have understood the problem completely. You keep throwing away the goals of the spec just to keep one number listed within a file "correct". Not only do you throw the baby out with the bath water, you blow up the whole plumbing system just to get six ASCII characters correct. > > >[.....] >>>BTW: It isn't my method in that I did not invent what was done. It was >>>already old when I learned it. It was used on many tapes before I got >>>near one. >> >>It wasn't used on our distribution tapes. Nobody would put a hand >>edited file on the tape and expect it to be a directory of the tape. > >Perhaps you have started to catch on. Perhaps not. Think about why and >how all the other steps did not need human actions to perform. These >steps were done by a script file. Nothing I have suggested needs a human >to do. Everything you have suggested required hand editing and still did not satisfy the condition that a directory of the tape be the first file on the tape. /BAH
From: jmfbahciv on 16 Mar 2007 08:54
In article <etbie5$3ko$2(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <etbb22$8qk_002(a)s881.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et8vtn$6oi$3(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et8nid$8qk_001(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <1173870480.508596.143930(a)n76g2000hsh.googlegroups.com>, >>>> "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote: >>>>>On Mar 13, 10:34 am, jmfbah...(a)aol.com wrote: >>>>>> In article <et3pbr$ra...(a)blue.rahul.net>, >>>>>> kensm...(a)green.rahul.net (Ken Smith) wrote: >>>>> >>>>>> >In that case. Thetapehad to be written with theTAPE.DIR in place and >>>>>> >correct on the first pass. >>>>>> >>>>>> This is the point. It will never be "correct" because the file >>>>>> contains a checksummed listing of itself. >>>>>> >>>>>> <snip> >>>>>> >>>>>> Do the exercise. Then you will see what I'm talking about. >>>>> >>>>>You really are determined to parade your ignorance. File checksums are >>>>>trivial to make internally consistent. >>>>> >>>>>At the simplest conceptual level you could define all files to have >>>>>checksum=0 and add some fluff to the end of each one to make it so. In >>>>>this case you only need to adjust the TAPE.DIR and since you know the >>>>>effect of changing the bytes in the checksum representation on the >>>>>checksum it is relatively easy to program a self consistent solution. >>>>> >>>>>CRC offers a much higher chance of detecting tape bitrot. But it is a >>>>>lot harder to tweak a file to contain its own CRC (but still not >>>>>impossible). Matching an MD5 is beyond present computational power. >>>>> >>>>>But for a simple checksum it can be done trivially by writing the >>>>>master TAPE.DIR file claiming any arbitrary checksum you like and then >>>>>adjusting the final file >>>> >>>>Now the file is no longer a directory of the tape. By modifying >>>>the file on the tape, you have changed the tape. There is no >>>>longer a directory of the tape on the tape. >>> >>>That is just silly word games, but at least you now obviously must see >>>that you have been wrong. >> >>Wrong. [awed emoticon here] > >Ok so you haven't yet figured out that you were wrong. > Do the exercise and you will see what I've been talking about. /BAH |