Jihad needs scientists
in [Design]
|
From: Ken Smith on 15 Mar 2007 09:59 In article <87hcsmizjg.fsf(a)nonospaz.fatphil.org>, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >kensmith(a)green.rahul.net (Ken Smith) writes: >> In article <873b47kb97.fsf(a)nonospaz.fatphil.org>, >> Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >> >kensmith(a)green.rahul.net (Ken Smith) writes: >> >> 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. >> > >> >It's not even a "recursion" problem. >> >> It can be considered a "recursion" problem. It is more exactly a self >> reference problem. > >Self reference and recursion are very different things. I disagree. Self references often lead to recursions and in the case we have been considering, the thinking of the people who say the problem can't be solved followed a recursive path. They followed the loop instead of stepping outside of it and asking why the loop existed. > >> It can be likened to the sentence: The first word in >> this sentence is "The". > >Nothing to do with recursion there. I was explaining it from my point of view so yes you are right. There is no recursion. >> The checksum refers to the very thing that is >> stating the checksum. People who are not used to thinking about >> self referencing, often have trouble understanding some of the issues it >> raises. > >People who are not used to thinking, such as BAH, seem to >even have problems understanding *what* you're doing, let alone >how it works and any issues surrounding it. Sad really. She also seemed confused about what she had actually did. Perhaps she just needed to thaw out the memory that had been in cold storage all these years or perhaps she never really though about it at the time. She may have just gone through the steps without really thinking about what they did. > >I decided not to chip in and tell her about the IOCCC entry from >a few years back which implemented exactly the scheme you're >talking about - I thought that would prompt even more confusion >from the senile one. Did they go with the two copies of the checksum or the "please ignore this". Two copies: Before The checksum is 0000 The checksum is :::: Please ignore: Before: The checksum is 0000 *Please ignore this line ZZZZ -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 15 Mar 2007 10:01 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. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 15 Mar 2007 10:14 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: >>>>>> [....] >>>>>> >>>>>>>>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. >> >>What I said was correct. > >No. It does not put a directory of the tape onto the tape. Yes it does. > >> 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?" > >> 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, you did not really create a directory of the tape. You created a directory of what you intended to put onto the tape. After you made this file you then attempted to write it and what it claimed was also there onto the tape. > >>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 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. Elsewhere you have protested that TAPE.DIR must be a directory of what was actually written onto the tape. 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. [.....] >>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. -- -- kensmith(a)rahul.net forging knowledge
From: krw on 15 Mar 2007 11:04 In article <eta7q5$hpg$3(a)blue.rahul.net>, kensmith(a)green.rahul.net says... > In article <MPG.2062131aed7a2dce98a111(a)news.individual.net>, > krw <krw(a)att.bizzzz> wrote: > >In article <et7ktl$bq1$4(a)blue.rahul.net>, kensmith(a)green.rahul.net > >says... > [....] > >> How mush is "badly written"? Most software is truly horrid. I still have > >> a hope that this may change. It may take the deaths of a hundred cute > >> puppies live on TV, due to a bug, to get the point. > >> > >So you agree that software sucks, C/C++ should be banned from the > >planet, and Billy Gates drawn and quartered. ...and then discuss > >software quality. > > Does screeming it from the roof tops qualify as merely agreeing? ;-) > I think that "C" could be allowed to remain on the planet. It can serve > as a good teaching tool about the dangers. Since 90% of all software is written in C/C++, I don't expect software quality to improve in my lifetime. In fact IMO it'll get worse as more C types are minted every year. > [....] > >> I wouldn't trust M$ for anything. > > > >It's OK for trolling for dumb donkeys and dimbulb. > > I wouldn't even trust it for that. > > [.....] > >Don't want no steenkin' Apples, now that they're x86. (Disclosure: I > >worked on the later G4 and G5 processors ;-) > > Yes the switch to X86 was a step backwards. I think a huge FPGA with a > soft processor may have been a better way to go. This way, you could run > any code. With a little trickiness, you could have some 8051 code, some > Z80 code, a bit of PIC code and a transputer all cohabiting the virtual > CPU space. we could have some real fun. > An FPGA would never be fast enough as a general purpose CPU. You can simulate other processors faster than an FPGA can emulate them. -- Keith
From: Phil Carmody on 15 Mar 2007 11:38
krw <krw(a)att.bizzzz> writes: > In article <3j0hv21dmsbm446in4auk2106k1m71rvqk(a)4ax.com>, > MassiveProng(a)thebarattheendoftheuniverse.org says... > > On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw(a)att.bizzzz> Gave us: > > > > >> > > >Don't want no steenkin' Apples, now that they're x86. (Disclosure: I > > >worked on the later G4 and G5 processors ;-) > > > > > > > > > That would be "worked with" Not "on", dipshit. > > MassivelyWrong once again, Dimbulb. I was a member of the Apple CPU > development team (Nintendo PPC750 processor variants as well) until > Apple switched to x86. Hmmm, why were Apple buying G4s from us at Freescale if they made their own? Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./. |