Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
you spew, dingledorf?krw wrote:
In article <87ps7agky9.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
krw <krw@att.bizzzz> writes:
In article <874pomikjk.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
krw <krw@att.bizzzz> writes:
In article <3j0hv21dmsbm446in4auk2106k1m71rvqk@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw@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?
Apple made none, idiot.
Why were apply buying G4s from us at Freescale if they designed
their own?
Try reading, idiot.
If you have more than 1/4 of a brain you might be able to predict
that I will probably narrow down the work you did "on" the G4 to
be "filled in forms and bought them from Freescale".
No, if you had *THAT* much brain, you would have figured out that I
would have pegged you for an idiot, like Dimmie.
No go, all ego.
What, exactly, do you call these little petty horseshit one liners
I notice you don't doubt my conclusion. I notice that krw doesn'tPhil Carmody wrote:
krw <krw@att.bizzzz> writes:
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?
Apple made none, idiot.
Why were apply buying G4s from us at Freescale if they designed
their own?
If you have more than 1/4 of a brain you might be able to predict
that I will probably narrow down the work you did "on" the G4 to be
"filled in forms and bought them from Freescale".
People with real lives don't have time for that sort of nonsense,
but we can easily understand why you do.
I see no problems porting the code - the porting just needs to changeIn article <878xdyikn8.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
kensmith@green.rahul.net (Ken Smith) writes:
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".
The please ignore this method. See for yourself ;-) It's omoikane from
http://www.ioccc.org/2004/
I can see problems with porting this code. It uses a 32 bit constant but
doesn't force the size of the variable it is used with. This is not a
good idea in any program. It is doubly bad in one like this where the
result needs to be 100% trustworthy.
I'm talking about the work done before you can hire the productionjmfbahciv@aol.com wrote:
In article <f539$45f813cb$4fe71d4$28601@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
jmfbahciv@aol.com wrote:
In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@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.
with a chunk of your favourite nonsense rhyme
or saying of the day until the statement "this files checksum = 1234"
is true. Checksum is invariant under permutations of the characters in
the file so you don't have to work very hard to do it by brute force.
Even if as seems likely the TAPE.DIR contains both length and checksum
then self consistent solutions can be found by SMOP.
It isn't a goal to have the checksum of TAPE.DIR correct. 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 file TAPE.DIR not match the checksum of TAPE.DIR reported
in TAPE.DIR.
Query: Is the ability to think about this concept (Mr. unsettled
called it recursion) a rare ability?
Technicians and engineers are trained to problem solving
regardless of method.
I realize this.
They consider it "inventive" to do
things the way they go about it; the way answers they have
provided in this subthread.
So how does the human race go from this "inventive" solution
methods into production? Is there a name for the work
which eliminates this requirement to tweak each item that comes
off the production line?
Sure. It is called the factory worker who is paid to rush
through production while ignoring flaws.
Unions don't allow quality work to occur.That's why we now have lemon laws.
Do those with mechanical engineering degrees do the work thatIn article <etbb6t$8qk_003@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]
So how does the human race go from this "inventive" solution
methods into production? Is there a name for the work
which eliminates this requirement to tweak each item that comes
off the production line?
That process is called "engineering" or in some cases "manufacturing
engineering". Once the solution is found, procedures, script files and
software is written. In large scale manufacturing, whole new machines are
designed to do produce the product.
It was not possible to edit the tape as Ken would like to haveOn Mar 14, 11:50 am, jmfbah...@aol.com wrote:
In article <1173870480.508596.143...@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam...@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@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.
I have heard of recursion w.r.t. to the computing biz. I haveQuery: 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.
You are talking about techniques. I was not dealing countingUnhinged 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.
My method did do this.In article <etb9rf$8ss_002@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et8v9c$6oi$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hie$8ss_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et6c0m$t53$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@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.
Nope.It was made from what you intended
to write onto the tape.
Of course this happened. In fact, there was always a bit by bitYou 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,
But it was. That's what you aren't understanding.this file you wrote could not be said to be a correct directory of
the tape.
The only thing your method did was to make the checksum ofThe 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.
I know exactly when I created TAPE.DIR. You do not.You seem at least to have finally settled on a claim about when you
created the TAPE.DIR.
The problem has not been solved; it cannot be solved withoutIn article <etba66$8ss_003@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et90pt$6oi$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8oqh$8qk_006@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@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.
In article <etban7$8qk_001@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et90d1$6oi$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hr5$8ss_002@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
Ken Smith wrote:
In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]
snip
I could try to teach you the answers to these questions but I don'tI 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 did create the file from a directory of the tape.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,
Not at all. The TAPE.DIR file contained a checksummed directoryyou did not really create a directory of the tape. You
created a directory of what you intended to put onto the tape.
After I made the file, I resaved the tape with that file at theAfter you
made this file you then attempted to write it and what it claimed was also
there onto the tape.
But you don't satisfy the primary condition that the filebut 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.
Yes.[....]
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.
Mr. unsettled read my specification and seems to have understood theUnsettled 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.
Everything you have suggested required hand editing and still did[.....]
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.
Do the exercise and you will see what I've been talking about.In article <etbb22$8qk_002@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et8vtn$6oi$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8nid$8qk_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@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.
Your brains?On Thu, 15 Mar 2007 21:46:46 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:
krw wrote:
In article <87ps7agky9.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
krw <krw@att.bizzzz> writes:
In article <874pomikjk.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
krw <krw@att.bizzzz> writes:
In article <3j0hv21dmsbm446in4auk2106k1m71rvqk@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw@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?
Apple made none, idiot.
Why were apply buying G4s from us at Freescale if they designed
their own?
Try reading, idiot.
If you have more than 1/4 of a brain you might be able to predict
that I will probably narrow down the work you did "on" the G4 to
be "filled in forms and bought them from Freescale".
No, if you had *THAT* much brain, you would have figured out that I
would have pegged you for an idiot, like Dimmie.
No go, all ego.
What, exactly, do you call these little petty horseshit one liners
you spew, dingledorf?
You are truly pathetic, let alone an absolute dipshit.
Pathetic? No, Dimmie that's you.
Neither you nor your sister, Dimmie, are worth "countering"."nonsense@unsettled.com" <nonsense@unsettled.com> writes:
Phil Carmody wrote:
krw <krw@att.bizzzz> writes:
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?
Apple made none, idiot.
Why were apply buying G4s from us at Freescale if they designed
their own?
If you have more than 1/4 of a brain you might be able to predict
that I will probably narrow down the work you did "on" the G4 to be
"filled in forms and bought them from Freescale".
People with real lives don't have time for that sort of nonsense,
but we can easily understand why you do.
I notice you don't doubt my conclusion. I notice that krw doesn't
counter my conclusion either.
You're so far off (with everything you've said so far) that youI hope he found his form-filling fulfilling.
In article <026kv2dmekf8lgget27vs5hkhi2hf2nsre@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Thu, 15 Mar 2007 21:46:46 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:
krw wrote:
In article <87ps7agky9.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
krw <krw@att.bizzzz> writes:
In article <874pomikjk.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
krw <krw@att.bizzzz> writes:
In article <3j0hv21dmsbm446in4auk2106k1m71rvqk@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw@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?
Apple made none, idiot.
Why were apply buying G4s from us at Freescale if they designed
their own?
Try reading, idiot.
If you have more than 1/4 of a brain you might be able to predict
that I will probably narrow down the work you did "on" the G4 to
be "filled in forms and bought them from Freescale".
No, if you had *THAT* much brain, you would have figured out that I
would have pegged you for an idiot, like Dimmie.
No go, all ego.
What, exactly, do you call these little petty horseshit one liners
you spew, dingledorf?
Your brains?
You are truly pathetic, let alone an absolute dipshit.
Pathetic? No, Dimmie that's you.
Once again you've just changed your story. You claim that the TAPE.DIRIn article <etbicr$3ko$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <etb9rf$8ss_002@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et8v9c$6oi$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hie$8ss_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et6c0m$t53$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@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.
So you checked after the fact that the tape was correct. At least we haveIt 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.
No, I think you aren't understanding. You claim that it is a directory ofthis 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.
No, what I suggested made the checksum stated for TAPE.DIR the correctThe 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.
Which exercise? I have pointed out that the checksum could be correct inIn article <etbie5$3ko$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <etbb22$8qk_002@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et8vtn$6oi$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8nid$8qk_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@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.
No. All mechanical engineers are complete idiots. It is where theIn article <etbirc$3ko$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <etbb6t$8qk_003@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]
So how does the human race go from this "inventive" solution
methods into production? Is there a name for the work
which eliminates this requirement to tweak each item that comes
off the production line?
That process is called "engineering" or in some cases "manufacturing
engineering". Once the solution is found, procedures, script files and
software is written. In large scale manufacturing, whole new machines are
designed to do produce the product.
Do those with mechanical engineering degrees do the work that
figures out how those machines are designed and their placement
on the factory floor?
I'm going to disagree with you slightly on this. Read the followingUnhinged is wrong though - the problem is only self referential.
I'm sure BAH will object that you didn't write it onto tape with the(*) 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"
Even the CRC8 solution used a table.It is the sort of elegant toy puzzle that Martin Gardner would delight
in.
CRC16 would take a lot more effort.
But those type declares are spinkled throughout the code. This is notkensmith@green.rahul.net (Ken Smith) writes:
In article <878xdyikn8.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
kensmith@green.rahul.net (Ken Smith) writes:
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".
The please ignore this method. See for yourself ;-) It's omoikane from
http://www.ioccc.org/2004/
I can see problems with porting this code. It uses a 32 bit constant but
doesn't force the size of the variable it is used with. This is not a
good idea in any program. It is doubly bad in one like this where the
result needs to be 100% trustworthy.
I see no problems porting the code - the porting just needs to change
the types used to be the types expected.
It has been solved. You don't understand what you were really doing. YouIn article <etbjit$3ko$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <etba66$8ss_003@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et90pt$6oi$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8oqh$8qk_006@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@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.
You are just being silly. You are the one who is having troubleIn article <etbkc7$3ko$6@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <etban7$8qk_001@s881.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et90d1$6oi$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hr5$8ss_002@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
Ken Smith wrote:
In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@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.
No, you did not. You created the TAPE.DIR file by making something thatIts 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.
Before you wrote the tape you shipped, you had the file call TAPE.DIR thatyou 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.
"resaved" means you wrote. You now admit that you had the TAPE.DIR beforeAfter 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.
Neither in fact did you. You wrote the directory that was made from someBut you don't satisfy the primary condition that the file
be a file that was made by doing a directory of the physical tape.
No, I don't think he understands it at all. He just happens to agree withMr. unsettled read my specification and seems to have understood the
problem completely.
You really must be trying to not understand.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