There are some pretty cool examples here!
What is really nice about this little "detour" is that we are all learning
some interesting interpretations of the Rebol words, and their use.
However, we need to keep in mind that we can't loose focus on the goal,
which is to write a model of the real problem...in the least number of
bytes. I condensed even further this one:
w: 100 print [loop w [w: w - first random [0 0 1]]]
Which, although a VERY COOL example of Rebol, is not a good example of the
problem.
This exact same problem in other languages would be just:
Matlab: sum(rand(100,1)>1/3)
C: for(int i=0,j=0;i<100;i++)j+=rand(3)>1;cout<<j;
In Perl: $i=0;$j=0;for(;$i<100;$i++){$j+=rand(3)>1;}print $j
Rebol: w: 100 print [loop w [w: w - first random [0 0 1]]]
Does not look good for Rebol.
Not that I judge a language by its compatibility at all, but it is just
plain fun to compare, we are mostly boys after all.
So...
The problem stated clearly is:
Monty shows you three curtains.
Behind one curtain is a prize, the others nothing.
REBOL: Set up THREE variables in Rebol, 1 "different" than the other two.
Pick a door at random.
REBOL: Pick a variable at random.
Once picked, one of the doors will be revealed to you, which is guaranteed
to be empty.
REBOL: Search through the variables until an empty one is found, remove it
from the list. Or mark it in some manner.
Offer chance to switch.
REBOL: Always switch, and if percentage chance of receiving prize
("different") of the remaining two variables, print a statement, or even the
simple number which is the percentage chance of receiving the prize.
We have to include the spaces and the "rebol[]_" in our count. Just this
header is 8, since Rebol requires spaces. So use 1 letter variable names.
If you write something "tricky" then simply break it down in your email.
This will both prove that it is a good model, and teach the rest of us more
about the nature of writing good programs, and make yourself a god, all at
the same time!
If you think you have really modeled the problem correctly, and in the LEAST
number of bytes, then append the statement to the Subject line "IN n bytes."
Where n is the actual number you were able to achieve.
Reichart...
[EMAIL PROTECTED]
"Be useful."
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 6:40 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
Hi Joel,
> It seems to me that the problem in the original post was persuasion
> and not just computation. That being the case, the text of the
> program itself (or its derivation) should be a compelling argument
> for the right answer.
>
> IOW, if I had trouble understanding/accepting an answer, I would
> not be very persuaded simply by the output of a highly compact
> program that seemed to contain assumptions about the very answer
> I was having trouble with.
I completely agree that a highly compressed program isn't often a great way
to win an argument. But (just to defend myself for a moment) my attempt
embodied all the "rules": I picked a door; Monty picked an empty one of the
other two; I swap to his unopened one. No built-in assumptions there.
i also agree with an earlier post of yours (about Perl and parlor games).
The
best test of a programming language isn't how compact a program it can
write,
but (I would claim) how easy it is to write maintainable programs in it. But
even that tests mainly the design skills and long-term vision of the
programmer.
A good test of all of our (and Perl and Matlab) solutions is how easily can
they be modified as various "real world" changes are required. Almost by
definition, we can't know what our programs will face over there lifetimes,
but here are a few of the sort of things that might beset a Monty simulator:
-- Not three doors, but 10
-- Not 10 but 25 million doors (challenging many language implementations to
handle this as in-store arrays)
-- Monty opens more than one door
--there is more than one door with a car behind it
-- I get to pick more than one originally, but can only open ONE of mine, OR
one of his once Monty has opened the ones on his side
-- I get to pick more than one door, and Monty opens N of mine and M of his.
-- There are several prizes (a Saab and a Mercedes) including some booby
prizes (A tribe and a yugo maybe). Monty will open up to N doors at random;
I
can't win the prize behind an opened door; but I can tell him to stop at
any
moment, and then make my choice.
-- The program running as a CGI is so overwhelming popular that it is
swamping the server: rewrite it to use half the cpu cycles.
-- The government will buy 3,000,000 copies but only after the simulation is
run not 500 times but 500,000,000 times. (Rebol can handle this number, but
for most languages
Wins + 1 = Wins
for a sufficiently large value of Wins. If you exceed that, you need extra
special code).
I can see how my solution will naturally extend for some of these; can be
bodged into shape for others; and would be scrapped and rewritten for the
rest. And that's programming!
Sunanda.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
