[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle IN 0 BYTES
From: ryanc::iesco-dms::com at: 17-Dec-2001 13:30
Incedently,
This is 3 bytes shorter:
w: 100 print loop w [w: w - last random [0 0 1]]
Of course more could be shave off, at the loss of readablility, but would better
match the examples from other languages given.
--Ryan
Reichart wrote:
> 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...
> [Reichart--Prolific--com]
> "Be useful."
>
> -----Original Message-----
> From: [SunandaDH--aol--com] [mailto:[SunandaDH--aol--com]]
> Sent: Monday, December 17, 2001 6:40 AM
> To: [rebol-list--rebol--com]
> 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
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
> --
> To unsubscribe from this list, please send an email to
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
The contradiction so puzzling to the ordinary way
of thinking comes from the fact that we have to use
language to communicate our inner experience
which in its very nature transcends lingistics.
-D.T. Suzuki
