Jihad needs scientists
in [Design]
|
From: nonsense on 14 Mar 2007 12:44 MassiveProng wrote: > On Wed, 14 Mar 2007 05:27:07 -0600, "nonsense(a)unsettled.com" > <nonsense(a)unsettled.com> Gave us: > > >>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: >>>>>>[....] >>>>>> >>>>>> >>>>>> >>>>>>>>Did you write a TAPE.DIR onto the tape after the tape had already been >>>>>>>>written? >>>>>>> >>>>>>>No. One of my requirements was that the file be the first in >>>>>>>the saveset. >>>>>> >>>>>> >>>>>>In other words, you created it based on what you intended to write to the >>>>>>tape not what you actually wrote. This contradicts what you said earlier. >>>>>> >>>>>>It doesn't matter because the suggested method still works. The checksum >>>>>>could still have been correct. >>>>> >>>>>The operative word is "could." It can never be "what was read from >>>>>the tape." Your entire argument on this matter has been silly. It >>>>>is an elementary problem in recursion. >>>> >>>>Yes, it can be what was read from the tape. I explained elsewhere exactly >>>>how you can make the first file on the tape be based on the contents of >>>>the tape after it has been written. Tape drives can write to the start of >>>>a tape without trashing the rest of the contents of the tape. >>> >>> >>>It will trash the rest of the tape. We shipped the files within >>>savesets. >>> >>> >>> >>>>The >>>>operation is refered to as an "edit" write. It only requires that the >>>>tape already contain a block of the same size. It has been done for >>>>years. >>> >>> >>>But your edit write would not include the directory of the tape >>>after you wrote it. >>> >>> >>>>There is no problem in recursion. There is no problem in making the >>>>checksum correct. You seem to have missed the post where I filled you in >>>>on how exactly the checksum of a file can be stored in the text of file >>>>and be valid. Here is a hint: >>>> >>>>checksum("0000ZZZZ") == checksum("1111YYYY") >>>> >>>>You should be able to take it from there. When you figure it out try to >>>>get BAH to understand. >>> >>> >>>/BAH understands your method just fine. First of all the editing >>>method would have trashed the first saveset. Second of all, >>>the file would not have been a directory of the tape after you >>>wrote the file to the tape. >> >>I almost hate to say this, but I think that understanding >>the problem is beyond him. > > > > All you EVER make are whimpy little peanut gallery comments, and even > those are pretty sad. Do you ever make a post where you tell anyone > the right answer if they are so wrong? NO. I did. You appear to be incapable of understanding it. > You are pathetic.
From: nonsense on 14 Mar 2007 12:46 MassiveProng wrote: > On Wed, 14 Mar 07 11:54:56 GMT, jmfbahciv(a)aol.com Gave us: > > >>In article <5a788$45f7cdfe$4fe707e$27037(a)DIALUPUSA.NET>, >> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >> >>>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: >>>>>>>[....] >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>Did you write a TAPE.DIR onto the tape after the tape had already been >>>>>>>>>written? >>>>>>>> >>>>>>>>No. One of my requirements was that the file be the first in >>>>>>>>the saveset. >>>>>>> >>>>>>> >>>>>>>In other words, you created it based on what you intended to write to the >>>>>>>tape not what you actually wrote. This contradicts what you said >> >>earlier. >> >>>>>>>It doesn't matter because the suggested method still works. The checksum >>>>>>>could still have been correct. >>>>>> >>>>>>The operative word is "could." It can never be "what was read from >>>>>>the tape." Your entire argument on this matter has been silly. It >>>>>>is an elementary problem in recursion. >>>>> >>>>>Yes, it can be what was read from the tape. I explained elsewhere exactly >>>>>how you can make the first file on the tape be based on the contents of >>>>>the tape after it has been written. Tape drives can write to the start of >>>>>a tape without trashing the rest of the contents of the tape. >>>> >>>> >>>>It will trash the rest of the tape. We shipped the files within >>>>savesets. >>>> >>>> >>>> >>>>>The >>>>>operation is refered to as an "edit" write. It only requires that the >>>>>tape already contain a block of the same size. It has been done for >>>>>years. >>>> >>>> >>>>But your edit write would not include the directory of the tape >>>>after you wrote it. >>>> >>>> >>>>>There is no problem in recursion. There is no problem in making the >>>>>checksum correct. You seem to have missed the post where I filled you in >>>>>on how exactly the checksum of a file can be stored in the text of file >>>>>and be valid. Here is a hint: >>>>> >>>>>checksum("0000ZZZZ") == checksum("1111YYYY") >>>>> >>>>>You should be able to take it from there. When you figure it out try to >>>>>get BAH to understand. >>>> >>>> >>>>/BAH understands your method just fine. First of all the editing >>>>method would have trashed the first saveset. Second of all, >>>>the file would not have been a directory of the tape after you >>>>wrote the file to the tape. >>> >>>I almost hate to say this, but I think that understanding >>>the problem is beyond him. >> >>Definitely. I'm studying the phenomena. I have encountered this >>before but it was rare in my area. I don't think one can do >>comm and OS development without being able to breathe recursion >>and live to tell about it :-). >> >>I'm beginning to wonder if this lack is a common trait. >>Consider the original thread subject matter. Weren't a lot >>of the problems due to not being able to think recursively? >> > > > You are BOTH recursively pathetic, lost, wrong, and bullheaded. > > Also too old not to be hard wired wrong which means you will never > learn. Interpretation: ProngHead says he who blusters loudly is the winner! Go stand by the kOOks where you belong.
From: nonsense on 14 Mar 2007 12:47 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. > > Different specification.
From: nonsense on 14 Mar 2007 12:50 Ken Smith wrote: > In article <et8nqg$8qk_002(a)s787.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: > [...] > >>>I almost hate to say this, but I think that understanding >>>the problem is beyond him. >> >>Definitely. I'm studying the phenomena. I have encountered this >>before but it was rare in my area. I don't think one can do >>comm and OS development without being able to breathe recursion >>and live to tell about it :-). > > > You are really stupid you know. I have pointed out how to solve the > recursion problem. You just refuse to believe that it can be solved so > you obviously aren't letting yourself understand what I am talking about. > > The folks who came up with the method were obviously years ahead of you on > such subjects. > > > As an aside, do you actually believe you have the high ground?
From: nonsense on 14 Mar 2007 12:50
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. > It cannot be solved within the specification. |