"David White" wrote in message
news:7Pc8b.2866$d6.139907@nasal.pacific.net.au...
> Jerry Coffin wrote in message
> news:MPG.19cadb1a41331ca19896b9@news.west.earthlink.net...
> > In article ,
> > no@email.provided says...
> >
> > [ ... ]
> >
<>
> Jerry's answer: That depends on many factors. If the train burns a fossil
> fuel then you need to take into account the steady loss of mass by the
train
> as the fuel is consumed. Then there are the effects of the thermal
expansion
> of the different metals in the engine, transmission and wheels. Countering
> the thermal expansion of the wheels, however, is the steady wear of the
> wheels on the tracks, which reduces their circumference slightly, and also
> their mass. The shifting weight of passengers within the train will also
> subject wheel bearings to forces that will...
>
Surely you must factor in the Michaelson-Morley contraction formulation
somewhere.
--
Gary
On 12 Sep 2003 06:06:35 -0700, quique-google@cronopios.net (Quique)
wrote:
>Hi,
>I'm studying the C programming language on my own, at home, using the
>same book (C Programming: A Modern Approach, by K. N. King).
I'm studying on my own also. Thanks very much for your examples. This
particular exercise has convinced me that I need to put down on paper
in my own words what each expression is doing. Otherwise, I have the
tendency to move through the material too fast and not actually grasp
the full significance of the example code and exercises.
Thanks again,
Bill
On Thu, 11 Sep 2003 20:49:47 -0800, James Connell wrote:
> SomeDumbGuy wrote:
>
>>
>>
>> Methinks that we all like to think we always have the right answer.
>> A truly enlightened person would be willing to consider that there is
>> more to the world than the small part we do know.
>>
>
> Ah Great - next someone is going to start spoting poetry :-[
http://www.de.ioccc.org/1990/westley.c
:-)
M4
Martijn Lievaart wrote:
> http://www.de.ioccc.org/1990/westley.c
My god, that's one of the funniest things I've ever seen :-D
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'gbzmlpu@cbobk.pbz' | rot13
In article <7Pc8b.2866$d6.139907@nasal.pacific.net.au>,
no@email.provided says...
[ ... ]
> Junior school exam question:
> Q. If a train takes two minutes to travel three miles, how long will it take
> to travel 150 miles?
> A. 100 minutes.
> Jerry's answer: That depends on many factors. If the train burns a fossil
> fuel then you need to take into account the steady loss of mass by the train
> as the fuel is consumed. Then there are the effects of the thermal expansion
> of the different metals in the engine, transmission and wheels. Countering
> the thermal expansion of the wheels, however, is the steady wear of the
> wheels on the tracks, which reduces their circumference slightly, and also
> their mass. The shifting weight of passengers within the train will also
> subject wheel bearings to forces that will...
>
> [much later]
>
> And then there are the relativistic effects. If the clock at the origin and
> the clock three miles away were synchronized by a light flash from the...
>
> ...and by applying the Lorentz transformation we see that the vibrations due
> to the train's whistle...
Yup -- you can even go so far as to call me Lawrence if it'll make you
feel better about having been wrong.
P.S. Anybody who doesn't get the allusion _really_ needs to read
_Cryptonomicon_ (by Neal Stephenson); even if I'm the one recommending
it, you'll enjoy it anyway!
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Thu, 11 Sep 2003 23:40:29 +0000, Jerry Coffin wrote:
Guys, try to meet each other in the middle.
- If there is a simple algorithm without some limitations on size, it is
more often than not better than one that does. The assignment said
nothing about the size, so you have to think about it. The only reasonable
answer is 'ask the one who wrote these incomplete specs'. If the algorithm
is size independent, that's OK too, but you'll probably encounter the same
problem somewhere else.
- The point about seperating UI from logic is very valid. For a 5 line
program like this I could not care less, but at 10 lines this becomes
important.
So a good solution would be to use the size-independent algorithm on a
string (or an iterator of course). Solves all points made.
I think you both made valid points, but you both have indefensible
positions IMO. The truth is somewhere in the middle. Try to find it.
HTH,
M4
"Jerry Coffin" wrote in message
news:MPG.19cc3d6a95f257179896bd@news.west.earthlink.net...
> Yup -- you can even go so far as to call me Lawrence
Okay, Lawrence, but there's one thing that puzzles me: How is it that a code
breaker of rare brilliance is unable to decipher a straightforward,
plain-text exam question? :-)
> if it'll make you
> feel better about having been wrong.
>
> P.S. Anybody who doesn't get the allusion _really_ needs to read
> _Cryptonomicon_ (by Neal Stephenson); even if I'm the one recommending
> it, you'll enjoy it anyway!
DW
In article ,
no.email@provided says...
> "Jerry Coffin" wrote in message
> news:MPG.19cc3d6a95f257179896bd@news.west.earthlink.net...
> > Yup -- you can even go so far as to call me Lawrence
>
> Okay, Lawrence, but there's one thing that puzzles me: How is it that a code
> breaker of rare brilliance is unable to decipher a straightforward,
> plain-text exam question? :-)
Perhaps you should reread (the early parts of) the book -- if you
recall, he fails a test (miserably) that's virtually identical to the
one he posted, the difference being that it was the speed of a boat
instead of a train.
--
Later,
Jerry.
The universe is a figment of its own imagination.
In article , m@rtij.nl.removefromhere.invalid
says...
> On Thu, 11 Sep 2003 23:40:29 +0000, Jerry Coffin wrote:
>
> Guys, try to meet each other in the middle.
I've tried to.
> - If there is a simple algorithm without some limitations on size, it is
> more often than not better than one that does. The assignment said
> nothing about the size, so you have to think about it. The only reasonable
> answer is 'ask the one who wrote these incomplete specs'. If the algorithm
> is size independent, that's OK too, but you'll probably encounter the same
> problem somewhere else.
And I've never said there was anything really terrible about the
algorithm per se. I've only said that it's more complex (and I'll
openly admit that it's only marginally so, but more complex nonetheless)
and for the job at hand does not seem to provide any real benefit.
My real problem all along has been with the "hint" that was offered. If
you follow that hint, you're more or less stuck writing this code about
as badly as possible.
If, for example, you decided to take the algorithm David (et al) used,
and put it into a function with a clean interface (e.g. taking a string
or a pair of iterators and returning a bool) it would still add
complexity without benefit, but I'm happy to admit that at that point
the loss from using it is marginal at worst.
> - The point about seperating UI from logic is very valid. For a 5 line
> program like this I could not care less, but at 10 lines this becomes
> important.
True. If you're writing toy code and only ever plan to write toy code,
maintainability is mostly a moot point. For better or worse, I normally
assume that even when working on toy problems that people posting here
are interested in learning to program at least reasonably well so they
can work toward solving real problems. With that in mind, recommending
techniques that have been proven (repeatedly) to fail even when solving
small problems seems short-sighted at best.
> So a good solution would be to use the size-independent algorithm on a
> string (or an iterator of course). Solves all points made.
As I said above, I find this only marginally objectionable at worst, but
I don't think it provides any real benefit, and I don't think anybody's
shown a shred of evidence that my position is indefensible.
Consider that airline tickets are NOT the only system like this by any
means -- there are also things like UPCs, ISSNs, ISBNs, and even
Ethernet MAC addresses. In every one of these cases (and quite a few
more besides) a long long has a greater range than is demanded by the
job at hand (though with both ISBNs and ISSNs, the check "digit" may be
an "X" intead of a digit, so putting it into a long long may not be an
option).
Now, that's not to say that a long long is adequate to every job there
is, by any means -- and anybody who cares to look can find that long
before this argument came along, I made quite a few posts in sci.crypt
about systems that need really large numbers (and that show I'm fully
aware of quite a few methods of working with such large numbers as
well). Those systems are entirely irrelevant to the job at hand though.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Mega Search
Sign Up 
