Jihad needs scientists

[Ken Smith]

In article <etdu1s$8qk_001@s986.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <1173976773.203668.217240@l75g2000hse.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On 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.

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.

This was based on your claim about what you did. Now you have changed
your story. It doesn't really matter because even with your new story,
the checksum could have been correct.

[....]

Now, I have tried to explain this to him but he doesn't seem to
understand how tapes physically looked.

No, the only confusion I've had is which of your stories is the one to
believe at any given instant. You have claimed things in direct
contradiction.

He also seems to
assume that tapes were directory media but the are not; they
are unit record media.

I have never ever eever said anything that at all implies this.

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.

Was there an IRG?

If there was, it could have been changed. Not that it matters because if
we believe your current story, the TAPE.DIR was not created from the
actual tape. Since the TAPE.DIR was created before the tape was written,
there is no need to do an edit write.

BTW: There need not have been an IRG on the tape. A huge number of tapes
have been written without IRGs. Whole companies stayed in business on
reading tapes in one format and converting to another. A big part of
their business was turning unblocked tapes into blocked ones.



--
--
kensmith@rahul.net forging knowledge

 

[MassiveProng]

On Fri, 16 Mar 07 12:52:26 GMT, jmfbahciv@aol.com Gave us:

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.

You guys turned what was a pretty fun thread into a real piece of
shit. Not surprising though, BAH, since shit begets shit.

 

[MassiveProng]

On Fri, 16 Mar 2007 09:40:32 -0400, krw <krw@att.bizzzz> Gave us:

In article <87hcslhfqz.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
"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.

Neither you nor your sister, Dimmie, are worth "countering".

I hope he found his form-filling fulfilling.

You're so far off (with everything you've said so far) that you
haven't even hit the right side of the continent.

He sure whopped you right upside da head tho.

You... designed processors... SURE!

Bwuahahahahahahahaha!

 

In article <eteaio$ecf$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <etdt34$8ss_003@s986.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In 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?

No. All mechanical engineers are complete idiots. It is where the
electronics engineers that are flunking out go to complete some degree.
Nobody in their right mind would ever let them design something important
like a factory. That job is much better left to someone with a degree in
quantum physics.

Sigh! So much for trying to have an adult conversation.

/BAH

 

In article <b29c6$45faa09e$49ecf4e$12726@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
<snip>

Note to BAH. Neither krw nor I can make a silk purse
out of MP's stuff. I'm going to stop responding to
him now as there's no advance possible.

Yea, I gave up a couple weeks' ago. His posts can't even
be used to speak through him.

/BAH

 

[Phil Carmody]

kensmith@green.rahul.net (Ken Smith) writes:

In article <87d539hfj5.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
kensmith@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.

But those type declares are spinkled throughout the code. This is not
good "C" coding practice. It is far better to gather all the type
information inot one place. You can do something like this:


#define OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0 signed
#define OOOOOOOOOOOOOOOOOOOOOOOOOOOOO0O unsigned
#define OOOOOOOOOOOOOOOOOOOOOOOOOOOOO00 char
#define OOOOOOOOOOOOOOOOOOOOOOOOOOOO0OO single
#define OOOOOOOOOOOOOOOOOOOOOOOOOOOO0O0 long
#define OOOOOOOOOOOOOOOOOOOOOOOOOOOO00O /* lemmings go here */
#define OOOOOOOOOOOOOOOOOOOOOOOOOOOO000 ;


Then you can simply write:

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0
OOOOOOOOOOOOOOOOOOOOOOOOOOOO00O
OOOOOOOOOOOOOOOOOOOOOOOOOOOO0O0
OOOOOOOOOOOOOOOOOOOOOOOOOOO0OOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOO000

When you need to declare a variable. I think you will agree that this is
much better coding practice.

I will agree!

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./.

 

[MassiveProng]

On Sat, 17 Mar 07 10:02:21 GMT, jmfbahciv@aol.com Gave us:

In article <b29c6$45faa09e$49ecf4e$12726@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
snip

Note to BAH. Neither krw nor I can make a silk purse
out of MP's stuff. I'm going to stop responding to
him now as there's no advance possible.

Yea, I gave up a couple weeks' ago. His posts can't even
be used to speak through him.

Pretty funny since I hit you with the silk purse joke several weeks
ago.

Nonsense is just a retard that never posts anything of ANY
substance, and always has some lame remark to spew.
Your buddy unlearned is the same.

Oh, wait! They ARE the same... One and the same retard, that is.

 

[krw]

In article <dpmmv256n8uv2aj0ou8u47f9o7fuillsdn@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...

On Fri, 16 Mar 2007 09:40:32 -0400, krw <krw@att.bizzzz> Gave us:

In article <87hcslhfqz.fsf@nonospaz.fatphil.org>,
thefatphil_demunged@yahoo.co.uk says...
"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.

Neither you nor your sister, Dimmie, are worth "countering".

I hope he found his form-filling fulfilling.

You're so far off (with everything you've said so far) that you
haven't even hit the right side of the continent.


He sure whopped you right upside da head tho.

Poor clueless Dimulb and his pet pantywaist Phil.

You... designed processors... SURE!

I was a member of one of the PowerPC processor development teams
(Apple/Nintendo processors, mainly) for seven years, sure. Jealous?

Bwuahahahahahahahaha!

You really should get that growth looked at, Dimbulb. It makes you
look silly.

--
Keith

 

[The Ghost In The Machine]

In sci.physics, krw
<krw@att.bizzzz>
wrote
on Tue, 13 Mar 2007 13:38:46 -0400
<MPG.206087082a3344ee98a0ff@news.individual.net>:

In article <t5khc4-tr.ln1@sirius.tg00suus7038.net>,
ewill@sirius.tg00suus7038.net says...
In sci.physics, MassiveProng
MassiveProng@thebarattheendoftheuniverse.org
wrote
on Mon, 12 Mar 2007 16:52:21 -0700
3mpbv2h1ts0jed1imfmdt5h52ukk3bcskj@4ax.com>:
On Mon, 12 Mar 2007 14:34:47 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) Gave us:

In article <45F4CF7A.BD6428AD@hotmail.com>,
Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:
[....]
So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Thats obvious. Its so there is a market for MOSFET drivers. I still want
a PIC made with Supertex's HV CMOS.



Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.

NOW, we are at 3.3 volts and even 1.2V. The reason is slew rate,
and the fact that we can transition much faster at those swings than
we ever could at 5V.

There would be no GHz+ Pentiums if we were still at 5 Volt logic
levels.

Getteth thyself a clue.

Well, I for one was under the opinion that the reason E
= 1.2V is because P = E^2/R and also proportional to the
switching frequency of the transistors (since each switch
requires a small pulse of current; the more pulses, the
higher the power required to switch), and also proportional
to the total transistor area, which AFAIK has been largely
constant even as we pack more transistors per die.

Dynamic power is proportional to CFV^2 (R doesn't figure into the
equation given that the circuit switches). You're missing static
power though. Static power (leakage) gets significant with smaller
geometries.

It might at that. I've been out of the biz for awhile; my speciality
now is Java / web programming.

Assuming one can run a chip at both 1.2V and 5V at the
same clock rate, the 5V running will run far hotter --
about 17.4 x more power, in fact.

At the same clock, yes (5^2/1.2^2).

Then again, there's a fair number of factors here, not the
least of which is process control. A chip, like an
airplane, is a bunch of compromises, one of them being
clock speed versus power dissipation.

Logic delay vs. power dissipation, really.

True.

Clock speed gets into
microarchitectural issues as well. For example, a P4 will run at a
higher clock speed than a P3 in the same technology. The P3 will
likely outperform it at the same power though.

The x86 series
is an excellent example of a total bodge-up because
it compromised so many things (for example, it's still
source-code compatible with the 8080A and probably with
the Z80 as well!).

Source code compatibility means nothing here.

I'll admit I wonder how much it meant even back then.

But it still works.

Now, assuming anyone wants an HV CMOS 40V logic swing, I
for one would think that the best method of achieving such
is through a 1.2V-to-40V swing converter, which presumably
would be a carefully-adjusted standard CMOS transistor-pair
inverter which flips at about 0.6 volts to ground. The rest
of the circuitry can run at 1.2 V without trouble.

Not sure why you'd want 40V, but you're not going to get it on the
same hunk of silicon.

True; I was thinking more along the lines of another chip nearby.
The only reason I'd want ~40V is because of phone specifications
still requiring it -- which stipulate 48V, IINM. Otherwise, it's
mostly a question of which chips want what when, given certain
constraints such as input power, chip speed, etc.

If necessary the level shifter can feed another, more standard inverter.

There might be better solutions; it's been a long time since I've been
anywhere near semiconductor designs, and I only really worked with
slow-speed digital stuff at most.

--
#191, ewill3@earthlink.net
Linux sucks efficiently, but Windows just blows around
a lot of hot air and vapor.

--
Posted via a free Usenet account from http://www.teranews.com

 

In article <eteabl$ecf$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <ete2pi$8qk_001@s986.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In 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.

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.

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.

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.

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. For the life of me I cannot remember
the command; it's been bugging me for three days. I guess I'll have
resort to RingTFM.

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.

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.

It is really a file of what you intended to write onto the tape. Only
after you make the file did you actually write the tape.

Acutally, I had the tape written three times. Two would have
been sufficient but that would have had the item within TAPE.DIR
that listed TAPE.DIR to have a checksum of 000000. I figured
that customers would write a SPR about that so I "solved" the
mess prevention possibility by doing the save procedures of
the tape three times.

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.

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.

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.

By making this nubmer correct, you invalidated all the rest
of the tape.


That is complete and total nonsense.

You edited the tape directly. You can no longer have any confidence
that the tape is still intact as it had been saved. Your procedure
would also take too long to complete. This also creates a high
probability that the tape is not a good master.

/BAH

 

[Martin Brown]

On Mar 16, 2:55 pm, kensm...@green.rahul.net (Ken Smith) wrote:

In article <1173976773.203668.217...@l75g2000hse.googlegroups.com>,

Martin Brown <|||newspam...@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.

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.

Regards,
Martin Brown

 

[nonsense@unsettled.com]

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?

 

In article <1174221298.287074.230690@l75g2000hse.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:

On Mar 16, 2:55 pm, kensm...@green.rahul.net (Ken Smith) wrote:
In article <1173976773.203668.217...@l75g2000hse.googlegroups.com>,

Martin Brown <|||newspam...@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

 

[MassiveProng]

On Sun, 18 Mar 2007 06:43:07 -0600, "nonsense@unsettled.com"
<nonsense@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!

 

[MassiveProng]

On Sun, 18 Mar 07 13:05:40 GMT, jmfbahciv@aol.com Gave us:

In article <1174221298.287074.230690@l75g2000hse.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 16, 2:55 pm, kensm...@green.rahul.net (Ken Smith) wrote:
In article <1173976773.203668.217...@l75g2000hse.googlegroups.com>,

Martin Brown <|||newspam...@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!

 

[MassiveProng]

On Sun, 18 Mar 2007 16:11:42 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) Gave us:

That is not a recursive problem at all. You seem unclear on what
recursive means.

She sure is good at doing it though. Recursive nonsense.

 

[Ken Smith]

In article <etj6mg$8qk_001@s874.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <eteabl$ecf$1@blue.rahul.net>,
kensmith@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@rahul.net forging knowledge

 

[Ken Smith]

In article <1174221298.287074.230690@l75g2000hse.googlegroups.com>,
Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:

On Mar 16, 2:55 pm, kensm...@green.rahul.net (Ken Smith) wrote:
In article <1173976773.203668.217...@l75g2000hse.googlegroups.com>,

Martin Brown <|||newspam...@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).

You are agreeing with my point. I think you now are starting to see what
has really happened with BAH's agrument. She has made an incorrect
statement and was left with the choice of admitting the error or ignoring
the path to the solution. She simply won't step outside the problem.


[...]

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.

Well we do know that she is a republican.

[....]

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 ?

BAH connects to the world through a soda straw.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <etjdf4$8qk_002@s874.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <1174221298.287074.230690@l75g2000hse.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 16, 2:55 pm, kensm...@green.rahul.net (Ken Smith) wrote:
In article <1173976773.203668.217...@l75g2000hse.googlegroups.com>,

Martin Brown <|||newspam...@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.

The people handling the tapes is not who we thought we were arguing with.
We had assumed a programmer wrote the script to cause the tape to get
written correctly. The person would mount the tape and from there, it is
all software. If your procedure had these people doing more than that,
you left lots of holes for trouble to get in.


--
--
kensmith@rahul.net forging knowledge

 

[nonsense@unsettled.com]

Ken Smith wrote:

In article <etjdf4$8qk_002@s874.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <1174221298.287074.230690@l75g2000hse.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:

On Mar 16, 2:55 pm, kensm...@green.rahul.net (Ken Smith) wrote:

In article <1173976773.203668.217...@l75g2000hse.googlegroups.com>,

Martin Brown <|||newspam...@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.


The people handling the tapes is not who we thought we were arguing with.
We had assumed a programmer wrote the script to cause the tape to get
written correctly. The person would mount the tape and from there, it is
all software. If your procedure had these people doing more than that,
you left lots of holes for trouble to get in.

Not knowing all the players and all the gambits is always
a problem. It is far easier for the folks who were part
and party at the time. On this basis alone you're in a
classic never win situation. You can say how you would
do things, but you cannot say how they should have,
because obviously they made their own decisions based
on scenarios which, at this late date, you cannot
accurately reproduce.