By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,814 Members | 1,050 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,814 IT Pros & Developers. It's quick & easy.

Ok. This IS homework ...

P: n/a
but I've been struggling with this for far too long and I'm about to
start beating my head against the wall.

My assignment seemed simple: create a program that will cacluate the
running total of user inputs until it hits 100. At 100 it should stop.
That's not the problem, in fact, that part works. It's the adding
that isn't working. How can my program add 2 + 7 and come up with 14?

I'm posting my code (so that you may all laugh). If ANYONE has any
ideas on what I'm doing wrong, I'd appreciate.

---------------------------------------------------

running = True
goal = 100

# subtotal = 0
# running_total = subtotal + guess

while running:
guess = int(raw_input('Enter an integer that I can use to add : '))
subtotal = guess

while running:
guess = int(raw_input('I\'ll need another number : '))
running_total = guess + subtotal
print running_total

if running_total == goal:
print 'Congratulations! You\'re done.'

elif running_total goal:
print 'That\'s a good number, but too high. Try again.'

print 'Done'

--------------------------

I tried adding an additional "while" statement to capture the second
number, but it didn't seem to solve my problem. Help!

Oct 14 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"spawn" <ev*************@gmail.comwrites:
That's not the problem, in fact, that part works. It's the adding
that isn't working. How can my program add 2 + 7 and come up with 14?
while running:
guess = int(raw_input('I\'ll need another number : '))
running_total = guess + subtotal
print running_total
You are never modifying the running total. I think you want to
initialize the running total to the first guess outside the loop, then
add guess to it when you read a new number. You can add to a variable
like this:
running_total += guess

this is approx. the same thing as

running_total = running_total + guess

I don't think subtotal and running_total need to be separate variables.
Oct 14 '06 #2

P: n/a
"spawn" <ev*************@gmail.comwrote:
but I've been struggling with this for far too long and I'm about
to start beating my head against the wall.
--------------------------

I tried adding an additional "while" statement to capture the
second number, but it didn't seem to solve my problem. Help!
Reread whatever material you have about while loops, or just consult
the python documentation, and then think about why your program(as
posted anyway) is never printing done.

Hope this isn't too much help,
max

Oct 14 '06 #3

P: n/a
spawn wrote:
while running:
guess = int(raw_input('Enter an integer that I can use to add : '))
subtotal = guess
while running:
guess = int(raw_input('I\'ll need another number : '))
running_total = guess + subtotal
You keep adding the original input (subtotal) to the most recent guess,
and printing "running_total". You never re-assign subtotal or make use
of running_total in your deepest loop.

Also, you never break out of your deepest loop, why are you using two
nested infinite-loops anyway?

Regards,
Brett Hoerner

Oct 14 '06 #4

P: n/a
Also, you never break out of your deepest loop, why are you using two
nested infinite-loops anyway?

Regards,
Brett Hoerner
Ummmmmm ..because I'm new to programming? Actually, they do end. If I
move my "guess" variable outside the outermost loop, then it becomes
infinte. I know, I tried it.

You guys are fast! I'll reread my documentation and try a few more
thing (I kept telling myself that running_total and subotal don't need
to be different variables!) and see what I get.

As for that last post (I don't remember your name), ummmmmm ... WOW!
This is BEGINNING Python. That looks far too advanced for me.

Oct 14 '06 #5

P: n/a

spawn wrote:
Also, you never break out of your deepest loop, why are you using two
nested infinite-loops anyway?

Regards,
Brett Hoerner

Ummmmmm ..because I'm new to programming? Actually, they do end. If I
move my "guess" variable outside the outermost loop, then it becomes
infinte. I know, I tried it.

You guys are fast! I'll reread my documentation and try a few more
thing (I kept telling myself that running_total and subotal don't need
to be different variables!) and see what I get.

As for that last post (I don't remember your name), ummmmmm ... WOW!
This is BEGINNING Python. That looks far too advanced for me.
Try to think logically about how this has to be done. You need a
variable that holds the running total. You need variable that holds
user input. You need to add user input to running total and compare it
to max value. First it's often a good idea to start with pseudo-code:

loop:
get input
add input to running total
if running total = goal, exit loop

what you do instead:

loop 1:
get input
subtotal = input
loop 2:
get input
set running total to sum of first input and second input
if running total = goal: print 'congratulations...'

Not sure what you want to do if total gets over max value.. you want to
subtract user's next input? Or just terminate?

I think your mistake is that you tried to write code and use commands
you read about in the manual before clearly understanding what you want
the code to do. Instead of solving two problems one by one you try to
solve two problems at the same time, which is tenfold as difficult. The
first problem is understanding how the logic of program will work, and
the second, how to use commands properly to carry out that logic. Which
is fine, I make this mistake often enough..

Hope this helps.. I didn't want to write out a solution 'cause you'll
learn better if you do it on your own.

-Rainy

Oct 15 '06 #6

P: n/a
spawn wrote:
Actually, they do end. If I
move my "guess" variable outside the outermost loop, then it becomes
infinte. I know, I tried it.
Huh? When does "running" ever evaluate to false (therefore breaking
either of the loops)?

Oct 15 '06 #7

P: n/a

spawn wrote:
but I've been struggling with this for far too long and I'm about to
start beating my head against the wall.

My assignment seemed simple: create a program that will cacluate the
running total of user inputs until it hits 100. At 100 it should stop.
That's not the problem, in fact, that part works. It's the adding
that isn't working. How can my program add 2 + 7 and come up with 14?

I'm posting my code (so that you may all laugh). If ANYONE has any
ideas on what I'm doing wrong, I'd appreciate.

---------------------------------------------------

running = True
goal = 100

# subtotal = 0
# running_total = subtotal + guess

while running:
guess = int(raw_input('Enter an integer that I can use to add : '))
subtotal = guess

while running:
guess = int(raw_input('I\'ll need another number : '))
running_total = guess + subtotal
print running_total

if running_total == goal:
print 'Congratulations! You\'re done.'

elif running_total goal:
print 'That\'s a good number, but too high. Try again.'

print 'Done'
A couple things:
1) I don't understand this looping structure. When the inner one ends,
the outer one will as well, and will never repeat.
2) As to why 2 + 7 gets you 14, subtotal is a shallow copy of guess, so
I speculate that the second assignment to guess doesn't change the
address, but inserts a new value into the old address. The upshot being
that you have guess and subtotal pointing to the same second value. If
I were you I would rewrite that bit as:

guess1 = int(raw_input('Enter an integer that I can use to add : '))
while running:
guess2 = int(raw_input('I\'ll need another number : '))
total = guess1 + guess2

(Your original assignments were confusing, using the same variables in
different contexts, and throwing in extra variables for no obvious
reason. This way it is clear what's being done, and it's easy to see
whether what's being done is what you want.)

Reading your description, that's not what you want. You want to
accumulate, so you'll want subtotal to be increasing each time a decent
guess is input. You want to quit when you reach 100, but you never set
running to False.
--------------------------

I tried adding an additional "while" statement to capture the second
number, but it didn't seem to solve my problem. Help!
Oct 15 '06 #8

P: n/a
spawn wrote:
but I've been struggling with this for far too long and I'm about to
start beating my head against the wall.

My assignment seemed simple: create a program that will cacluate the
running total of user inputs until it hits 100. At 100 it should stop.
That's not the problem, in fact, that part works. It's the adding
that isn't working. How can my program add 2 + 7 and come up with 14?

I'm posting my code (so that you may all laugh). If ANYONE has any
ideas on what I'm doing wrong, I'd appreciate.

---------------------------------------------------

running = True
goal = 100

# subtotal = 0
# running_total = subtotal + guess

while running:
guess = int(raw_input('Enter an integer that I can use to add : '))
subtotal = guess

while running:
guess = int(raw_input('I\'ll need another number : '))
running_total = guess + subtotal
print running_total

if running_total == goal:
print 'Congratulations! You\'re done.'

elif running_total goal:
print 'That\'s a good number, but too high. Try again.'

print 'Done'

--------------------------

I tried adding an additional "while" statement to capture the second
number, but it didn't seem to solve my problem. Help!

Dear anonymous student,

Once upon a time programmers did things like this:

BEGIN
|
-------------->|<-------------------------------------
| | |
| catch input |
| | |
| input type valid? - prompt for correct input --|
| + |
| input too large? + --- prompt for new input --
| -
| add to running total
| |
| status report
| |
-- - running total >= max?
+
report done
|
END

It was called a flow chart. Flow charts could be translated directly
into machine code written in assembly languages which had labels, tests
and jumps as the only flow-control constructs. When structured
programming introduced for and while loops they internalized labeling
and jumping. That was a great convenience. Flow-charting became rather
obsolete because the one-to-one correspondence between flow chart and
code was largely lost.
I still find flow charting useful for conceptualizing a system of
logical states too complex for my intuition. Everybody's intuition has a
limit. Your homework solution shows that the assignment exceeds yours.
So my suggestion is that you use the flow chart, like this:
def homework ():

# Local functions. (I won't do those for you.)

def explain_rules ():
def check_type (r):
def explain_type ():
def check_size (r):
def explain_max_size ():
def report_status (rt):
def report_done ():
# Main function

GOAL = 100 # BEGIN
MAX_INPUT = 20 # |
running_total = 0 # |
# |
explain_rules () # |
# |
while 1: #
-------------->|<-------------------------------------
# |
| |
response = raw_input ('Enter a number ') # |
catch input |
# |
| |
if check_type (response) == False: # | input
type valid? - prompt for correct input --|
explain_type () # |
+ |
continue # |
| |
# |
| |
if check_size (response) == False: # | input
too large? + --- prompt for new input --
explain_max_size () # | -
continue # | |
# | |
running_total += int (response) # | add to
running total
report_status (running_total) # |
status report
# | |
if running_total >= GOAL: # -- - running
total >= max?
break # +
# |
report_done () #
report done
# |
#? return (whatever) # END
Frederic

(... inviting you to sign your posts and to let me know the grade your
teacher gives you for completing the local functions.)

Oct 16 '06 #9

P: n/a
Frederic Rentsch <an***********@vtxmail.chwrote:
It was called a flow chart. Flow charts could be translated directly
into machine code written in assembly languages which had labels, tests
and jumps as the only flow-control constructs. When structured
programming introduced for and while loops they internalized labeling
and jumping. That was a great convenience. Flow-charting became rather
obsolete because the one-to-one correspondence between flow chart and
code was largely lost.
The trouble with flow charts is that they aren't appropriate maps for
the modern computing language territory.

I was born and bred on flow charts and I admit they were useful back
in the days when I wrote 1000s of lines of assembler code a week.

Now-a-days a much better map for the the territory is pseudo-code.
Python is pretty much executable pseudo-code anway!

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Oct 16 '06 #10

P: n/a
Nick Craig-Wood wrote:
Frederic Rentsch <an***********@vtxmail.chwrote:
> It was called a flow chart. Flow charts could be translated directly
into machine code written in assembly languages which had labels, tests
and jumps as the only flow-control constructs. When structured
programming introduced for and while loops they internalized labeling
and jumping. That was a great convenience. Flow-charting became rather
obsolete because the one-to-one correspondence between flow chart and
code was largely lost.

The trouble with flow charts is that they aren't appropriate maps for
the modern computing language territory.
Yes. That's why they aren't used anymore.
I was born and bred on flow charts and I admit they were useful back
in the days when I wrote 1000s of lines of assembler code a week.

Now-a-days a much better map for the the territory is pseudo-code.
Python is pretty much executable pseudo-code anway
Yes. But it's the "executable pseudo code" our friend has problems with.
So your very pertinent observation doesn't help him. My suggestion to
use a flow chart was on the impression that he didn't have a clear
conception of the solution's logic and that the flow chart was a simple
means to acquire that clear conception. I like flow charts because they
exhaustively map states and transitions exactly the way they
connect---solution imaging as it were. If they can help intelligence map
a territory it is no issue if they don't map it themselves very well.

Oct 16 '06 #11

P: n/a
Frederic Rentsch wrote:
Once upon a time programmers did things like this:

BEGIN
|
-------------->|<-------------------------------------
| | |
| catch input |
| | |
| input type valid? - prompt for correct input --|
| + |
| input too large? + --- prompt for new input --
| -
| add to running total | |
| status report | |
-- - running total >= max?
+
report done |
END

It was called a flow chart. Flow charts could be translated directly
into machine code written in assembly languages which had labels, tests
and jumps as the only flow-control constructs. When structured
programming introduced for and while loops they internalized labeling
and jumping. That was a great convenience. Flow-charting became rather
obsolete because the one-to-one correspondence between flow chart and
code was largely lost.
As long as you only draw your loops to the right (or left, just be
consistent) and make sure you don't cross any lines, you're doing
structured programming. (I think...)

E.g.

|
v
blah1<--------+
| ^
v |
if xx-->foo |
| | |
v v |
bar baz |
| | |
+<-------+ |
| |
v |
maybe-------->+
|
v

Oct 19 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.