On 09/16/2012 09:34 PM, jmrhide-p...@yahoo.com wrote:
<why is that sub being declared in BEGIN?>
I copied what was on the manpage for CGI::carp
<for (my $loopiter <= $loopmax)>
I lost my way on that one, but I don't see how a shuffle works here either. I'm
trying to ensure that the program will not pick the same term twice in a row.
$lastnum comes from a cookie and refers to the previous question. What about
you can store all the previous numbers in the cookie and get only the
unused ones easily with a hash. if you track your state better, you can
reduce the code to a much simpler design. i haven't followed your web
requirements but i know convoluted code when i see it. it seems like you
are working way harder than you need because of the design you created.
so a major win would be to rethink that design. there are other ways to
maintain state in cgi apps including several current web app systems and
modules. using cookies for that is tricky if you don't know how to even
split up what is maintained state vs new data.
for (my $loopiter = 1..$loopmax) { #1
that is totally wrong. .. won't generate a list there. you need to learn
foreach syntax. i can't even say what that line would do as it is using
the flip-flop op in a strange way (.. in a scalar context).
if $loopiter >= $loopmax { die "Loop number $loopnum has iterated
$loopiter
times" }
$termnum[0] = int( rand($defnum) );
last unless ( $termnum[0] == $lastnum );
}
Assuming 25 to 50 terms in a category (the range for $defnum), there's a small
but finite chance that this randomly chosen $termnum will be exactly the same as
the previous one ($lastnum).
so track ALL the numbers already used and you won't ever need a loop.
just put the list into the cookie. get that list back, strip those
numbers from the master list (a hash with delete can do that in 1 line)
and then pick a random element from the remainder. this could be done in
a short sub and reused for all of these things. see, subs are also for
reuse. then you eliminate all those while loops and the possibility of
infinite loops and all the other related problems. the code would be
reduced by a nice factor too.
The chance is even smaller that it will happen that
way twice in a row. So this loop should not have many iterations and it's hard
for me to see how it could go wrong.
it will go wrong IF it can go wrong. murphy knows all about this. my
idea (and there are other solutions) eliminates this possibility and
removes the need for loops.
Some of the later loops have more
complicated conditions: for example, the new $termnum must not match any of
several previously chosen others.
also solved by my design above.
I see more room for that sort of loop to go
awry. So I'm just trying to build in some insurance against logical errors
specific to these looping structures that recur throughout the process of
constructing new questions
and if you redo the code to use a sub to handle all of the questions
with different data sets, you would simplify this to almost no code. one
sub would be passed the question data, the cookie data (with all the
previous choices, etc.). it would pick a new random question or whatever
in one line with NO looping.
also please learn to bottom post and put your comments after mine. see
how i interspersed my responses?
uri
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
