# (Very Newbie) Problems defining a variable

Discussion in 'Python' started by febaen@gmail.com, Dec 12, 2008.

1. ### Guest

#!/usr/bin/python
#Py3k, UTF-8

bank = int(input("How much money is in your account?\n>>"))
target = int(input("How much money would you like to earn each year?
\n>>"))

interest = 0
i = 0

while interest < target:
#determine the interest rate to use
if bank >= 9999:
rate = 0.006
elif bank >= 10000 and bank <= 24999:
rate = 0.0085
elif bank >= 25000 and bank <= 49999:
rate = 0.0124
elif bank >= 50000 and bank <= 99999:
rate = 0.0149
elif bank >= 100000:
rate = 0.0173
#Now that we know what interest rate to use, apply it...
lastbank = bank #To calculate interest...
bank += (bank * rate) #Update earnings...
interest = bank - lastbank #And figure out how much interest is made!
i += 1 #So we can see which year a calculation represents
print("Year %s, at %s rate: %s paid, %s in bank." % (i, rate,
interest, bank))

I wrote this expanding off an 'interest' exercise in a tutorial, which
was fairly simple (assume %1, calculate for ten years). It's intended
to take how much the user has in the bank and determine how long it
will be until it generates a certain amount in interest each year. The
problem is that rates are not solid, and increase at certain points. I
put the rates from the basic account option at my bank in as an
example.

I'm pretty certain that that is also the problem in the code. I'm
pretty sure it's a problem with the 'if' statements', and it looks
like it's one of those mistakes that's so simple you look back on it
and laugh at yourself. If you put in a bank number <= 9999, it fails,
saying "NameError: name 'rate' is not defined". If you put in one
higher, it runs correctly, but thinks that the rate is 0.006

I tried def'ing a function for it, which didn't work any better. I'm
having a hard time figuring out exactly why it is those if statements
are wrong.

, Dec 12, 2008

2. ### Bruno DesthuilliersGuest

a écrit :
> #!/usr/bin/python
> #Py3k, UTF-8
>
> bank = int(input("How much money is in your account?\n>>"))
> target = int(input("How much money would you like to earn each year?
> \n>>"))
>
> interest = 0
> i = 0
>
> while interest < target:
> #determine the interest rate to use
> if bank >= 9999:
> rate = 0.006
> elif bank >= 10000 and bank <= 24999:
> rate = 0.0085
> elif bank >= 25000 and bank <= 49999:
> rate = 0.0124
> elif bank >= 50000 and bank <= 99999:
> rate = 0.0149
> elif bank >= 100000:
> rate = 0.0173

(snip)

> I'm pretty certain that that is also the problem in the code. I'm
> pretty sure it's a problem with the 'if' statements', and it looks
> like it's one of those mistakes that's so simple you look back on it
> and laugh at yourself. If you put in a bank number <= 9999, it fails,
> saying "NameError: name 'rate' is not defined". If you put in one
> higher, it runs correctly, but thinks that the rate is 0.006

Indeed. That's what you asked for. If bank is >= 9999, then rate will be
set to 0.006, and the following tests will be skipped. Else - since you
just don't handle the case -, rate is not defined at all.

I guess you wanted your first test to be:

if bank <= 9999:
...

FWIW, when using if/elif that way, make sure you always end with a
"default" else clause (even if just to signal you didn't expect to be
there...)

HTH

Bruno Desthuilliers, Dec 12, 2008

3. ### febaGuest

On Dec 12, 5:56 am, Bruno Desthuilliers <bruno.
> wrote:
> a écrit :
>
>
>
> > #!/usr/bin/python
> > #Py3k, UTF-8

>
> > bank = int(input("How much money is in your account?\n>>"))
> > target = int(input("How much money would you like to earn each year?
> > \n>>"))

>
> > interest = 0
> > i = 0

>
> > while interest < target:
> > #determine the interest rate to use
> >    if bank >= 9999:
> >            rate = 0.006
> >    elif bank >= 10000 and bank <= 24999:
> >            rate = 0.0085
> >    elif bank >= 25000 and bank <= 49999:
> >            rate = 0.0124
> >    elif bank >= 50000 and bank <= 99999:
> >            rate = 0.0149
> >    elif bank >= 100000:
> >            rate = 0.0173

>
> (snip)
>
> > I'm pretty certain that that is also the problem in the code. I'm
> > pretty sure it's a problem with the 'if' statements', and it looks
> > like it's one of those mistakes that's so simple you look back on it
> > and laugh at yourself. If you put in a bank number <= 9999, it fails,
> > saying  "NameError: name 'rate' is not defined".  If you put in one
> > higher, it runs correctly, but thinks that the rate is 0.006

>
> Indeed. That's what you asked for. If bank is >= 9999, then rate will be
> set to 0.006, and the following tests will be skipped. Else - since you
> just don't handle the case -, rate is not defined at all.
>
> I guess you wanted your first test to be:
>
>     if bank <= 9999:
>        ...
>
> FWIW, when using if/elif that way, make sure you always end with a
> "default" else clause (even if just to signal you didn't expect to be
> there...)
>
> HTH

that's it, thanks! was confused with it being basically in a column of
all >= *.

I replaced it with

if bank <= 0:
print("You're in the red!")
quit()
elif bank >= 1 and bank <= 9999:
rate = 0.0060
elif bank >= 10000 and bank <= 24999:
rate = 0.0085
elif bank >= 25000 and bank <= 49999:
rate = 0.0124
elif bank >= 50000 and bank <= 99999:
rate = 0.0149
elif bank >= 100000:
rate = 0.0173
else:
print("What's this doing here?")

which also changes it to keep it from going on forever if you put in a
negative amount. Out of curiosity, would you still recommend applying
an 'else' clause in this case? I don't see how it could ever be
triggered, even if there's an error of some kind

feba, Dec 12, 2008
4. ### Steven D'ApranoGuest

On Fri, 12 Dec 2008 04:05:21 -0800, feba wrote:

> that's it, thanks! was confused with it being basically in a column of
> all >= *.
>
> I replaced it with
>
> if bank <= 0:
> print("You're in the red!")
> quit()
> elif bank >= 1 and bank <= 9999:
> rate = 0.0060

You can replace this with the simpler, easier to read and faster:

elif 1 <= bank <= 9999:
rate = 0.0060
elif 10000 <= bank <= 24999:
rate = 0.0085

....

> elif bank >= 100000:
> rate = 0.0173
> else:
> print("What's this doing here?")

Change the last two else clauses to this one:

else:
rate = 0.0173

--
Steven

Steven D'Aprano, Dec 12, 2008
5. ### Chris RebertGuest

On Fri, Dec 12, 2008 at 3:42 AM, <> wrote:
> #!/usr/bin/python
> #Py3k, UTF-8
>

<snip>
>
> #determine the interest rate to use
> if bank >= 9999:
> rate = 0.006
> elif bank >= 10000 and bank <= 24999:
> rate = 0.0085
> elif bank >= 25000 and bank <= 49999:
> rate = 0.0124
> elif bank >= 50000 and bank <= 99999:
> rate = 0.0149
> elif bank >= 100000:
> rate = 0.0173

For the love of Benji, reverse the ordering of the clauses so you
don't have to keep checking whether the number is also under the next
limit!
flipped around the wrong way was right)

if bank >= 100000:
rate = 0.0173
elif bank >= 50000:
rate = 0.0149
elif bank >= 25000:
rate = 0.0124
elif bank >= 10000:
rate = 0.0085
else:
rate = 0.006

Note how much simpler that is to read and understand. And switching
the default case to the 'else' is just idiomatic.

Cheers,
Chris

--
Follow the path of the Iguana...
http://rebertia.com

Chris Rebert, Dec 12, 2008
6. ### Guest

feba:
>         if bank <= 0:
>                 print("You're in the red!")
>                 quit()
>         elif bank >= 1 and bank <= 9999:
>                 rate = 0.0060
>         elif bank >= 10000 and bank <= 24999:
>                 rate = 0.0085
>         elif bank >= 25000 and bank <= 49999:
>                 rate = 0.0124
>         elif bank >= 50000 and bank <= 99999:
>                 rate = 0.0149
>         elif bank >= 100000:
>                 rate = 0.0173
>         else:
>                 print("What's this doing here?")

I think your indents are a little too much large (the soft standard is
4 spaces).

The last else can be removed.

Does bank == 0 mean being in red?

That list of if-elif seems bug-prone. In the future you will learn
ways to write that in a less bug-prone (but also probably more complex

Bye,
bearophile

, Dec 12, 2008
7. ### Bruno DesthuilliersGuest

feba a écrit :
> On Dec 12, 5:56 am, Bruno Desthuilliers <bruno.
> > wrote:

(snip)
>> I guess you wanted your first test to be:
>>
>> if bank <= 9999:
>> ...

(snip)
> that's it, thanks! was confused with it being basically in a column of
> all >= *.
>
> I replaced it with
>
> if bank <= 0:
> print("You're in the red!")
> quit()
> elif bank >= 1 and bank <= 9999:
> rate = 0.0060
> elif bank >= 10000 and bank <= 24999:
> rate = 0.0085
> elif bank >= 25000 and bank <= 49999:
> rate = 0.0124
> elif bank >= 50000 and bank <= 99999:
> rate = 0.0149
> elif bank >= 100000:
> rate = 0.0173
> else:
> print("What's this doing here?")
>
> which also changes it to keep it from going on forever if you put in a
> negative amount.

Good point.

> Out of curiosity, would you still recommend applying
> an 'else' clause in this case?

Yes, but I'd use it as a replacement for the last test:

# code here ...
elif bank >= 50000 and bank <= 99999:
rate = 0.0149
else:
rate = 0.0173

And finally, I'd simplify the whole damn thing:

if bank < 1:
print("You're in the red!")
quit()
elif bank < 10000:
rate = 0.0060
elif bank < 25000:
rate = 0.0085
elif bank < 50000:
rate = 0.0124
elif bank < 100000:
rate = 0.0149
else:
rate = 0.0173

> I don't see how it could ever be
> triggered, even if there's an error of some kind

It couldn't, indeed. Which FWIW is a clear indication that the previous
test ( elif bank >= 100000 is redundant !-)

HTH

Bruno Desthuilliers, Dec 12, 2008
8. ### febaGuest

Actually, I have gedit set to four spaces per tab. I have no reason
why it's showing up that large on copy/paste, but the file itself is
fine.

Thanks for the advice Chris, Stephen, I can definitely see how those
are both far better ways of doing it. I have it as:

#!/usr/bin/python
#Py3k, UTF-8

bank = int(input("How much money is in your account?\n>>"))
if bank <=0:
print("You need a postive amount to gain interest.")
quit()
target = int(input("How much money would you like to earn each year?
\n>>"))

interest = 0
i = 0

while interest < target:
#determine the interest rate to use
if bank >= 100000:
rate = 0.0173
elif bank >= 50000:
rate = 0.0149
elif bank >= 25000:
rate = 0.0124
elif bank >= 10000:
rate = 0.0085
else:
rate = 0.0060
#Now that we know what interest rate to use, apply it...
lastbank = bank #To calculate interest...
bank += (bank * rate) #Update earnings...
interest = bank - lastbank #And figure out how much interest is made!
i += 1 #So we can see which year a calculation represents
print("Year %s, at %s rate: %s paid, %s in bank." % (i, rate,
interest, bank))

now it checks to make sure the account is positive before moving on,
efficiency in getting the rate

feba, Dec 12, 2008
9. ### Marc 'BlackJack' RintschGuest

On Fri, 12 Dec 2008 04:58:36 -0800, feba wrote:

> Actually, I have gedit set to four spaces per tab. I have no reason why
> it's showing up that large on copy/paste, but the file itself is fine.

The file contains one tab character per indentation level and it depends
on the software you use to look at the text how many spaces will be
displayed. Better use four real spaces to indent one level so it looks
the same everywhere.

Ciao,
Marc 'BlackJack' Rintsch

Marc 'BlackJack' Rintsch, Dec 12, 2008
10. ### Tim RoweGuest

Since we all seem to be having a go, here's my take. By pulling the
rates and thresholds into a dictionary I feel I'm getting a step
closer to the real world, where these would presumably be pulled in
from a database and the number of interest bands might vary. But is
there a tidier way to get 'thresholds'? I was a bit surprised that
rates.keys() didn't give me a list directly, so although the 3.0
tutorial says "The keys() method of a dictionary object returns a list
of all the keys used in the dictionary, in arbitrary order (if you
want it sorted, just apply the sort() method to )" that's not /quite/
such a given, because "the list of keys" doesn't seem to be there for
the sorting any more.

Is there a tidy way of making rates and thresholds local to get_rate,
without recalculating each time? I suppose going object oriented is
the proper way.

#Py3k,UTF-8

rates = {0: 0.006, 10000: 0.0085, 25000: 0.0124, 50000: 0.0149, 100000: 0.0173}
thresholds = list(rates.keys())
thresholds.sort()
thresholds.reverse()

def get_rate(balance):
for threshold in thresholds:
if balance >= threshold:
return rates[threshold]
else:
return 0.0

balance = int(input("How much money is in your account?\n>>"))
target = int(input("How much money would you like to earn each year?\n>>"))

if balance <= 0:
print("You'll never make your fortune that way!\n")
else:
interest = 0
year = 0
while interest < target:
rate = get_rate(balance)
interest = balance * rate
balance += interest
year += 1
print("Year %s, at %s rate: %s paid, %s in bank." % (year,
rate, interest, balance))

--
Tim Rowe

Tim Rowe, Dec 12, 2008
11. ### MRABGuest

Tim Rowe wrote:
> Since we all seem to be having a go, here's my take. By pulling the
> rates and thresholds into a dictionary I feel I'm getting a step
> closer to the real world, where these would presumably be pulled in
> from a database and the number of interest bands might vary. But is
> there a tidier way to get 'thresholds'? I was a bit surprised that
> rates.keys() didn't give me a list directly, so although the 3.0
> tutorial says "The keys() method of a dictionary object returns a list
> of all the keys used in the dictionary, in arbitrary order (if you
> want it sorted, just apply the sort() method to )" that's not /quite/
> such a given, because "the list of keys" doesn't seem to be there for
> the sorting any more.
>
> Is there a tidy way of making rates and thresholds local to get_rate,
> without recalculating each time? I suppose going object oriented is
> the proper way.
>
> #Py3k,UTF-8
>
> rates = {0: 0.006, 10000: 0.0085, 25000: 0.0124, 50000: 0.0149, 100000: 0.0173}
> thresholds = list(rates.keys())
> thresholds.sort()
> thresholds.reverse()
>

Why are you putting them into a dict at all? Surely a list of tuples is
better?

# I could've just written the list in descending order here!
rates = [(0, 0.006), (10000, 0.0085), (25000, 0.0124), (50000, 0.0149),
(100000, 0.0173)]
thresholds.sort(reversed=True)

> def get_rate(balance):
> for threshold in thresholds:
> if balance >= threshold:
> return rates[threshold]
> else:
> return 0.0
>

def get_rate(balance):
for threshold, rate in thresholds:
if balance >= threshold:
return rate
return 0.0

> balance = int(input("How much money is in your account?\n>>"))
> target = int(input("How much money would you like to earn each year?\n>>"))
>
> if balance <= 0:
> print("You'll never make your fortune that way!\n")
> else:
> interest = 0
> year = 0
> while interest < target:
> rate = get_rate(balance)
> interest = balance * rate
> balance += interest
> year += 1
> print("Year %s, at %s rate: %s paid, %s in bank." % (year,
> rate, interest, balance))
>

MRAB, Dec 12, 2008
12. ### John MachinGuest

On Dec 13, 4:50 am, Dennis Lee Bieber <> wrote:
> On Fri, 12 Dec 2008 03:42:55 -0800 (PST), declaimed the
> following in comp.lang.python:
>
> > #!/usr/bin/python
> > #Py3k, UTF-8

>
> > bank = int(input("How much money is in your account?\n>>"))
> > target = int(input("How much money would you like to earn each year?
> > \n>>"))

>
>         Just for my curiosity -- did Python 3.x (besides turning print into
> a function) also change input() to behave as the old raw_input()?

Yup. There've been some other tectonic plate shift effects, e.g.:

xrange() -> range(); range() -> list(range())
dict.iteritems() -> dict.items(); dict.items() -> list(dict.items())
halfassci() -> repr(); repr() -> ascii()

John Machin, Dec 12, 2008
13. ### Tim RoweGuest

2008/12/12 Kirk Strauser <>:

> def get_rate(balance):
> for threshold, rate in ((100000, .0173),
> (50000, .0149),
> (25000, .0124),
> (10000, .0085),
> (0, .006)):
> if balance > threshold:
> return rate
> return .0

Yes, once it's changed from a dictionary to tuples it becomes easier,
doesn't it? D'oh!

--
Tim Rowe

Tim Rowe, Dec 12, 2008
14. ### John MachinGuest

On Dec 13, 5:18 am, Kirk Strauser <> wrote:
> At 2008-12-12T18:12:39Z, "Tim Rowe" <> writes:
>
>
>
> > Is there a tidy way of making rates and thresholds local to get_rate,
> > without recalculating each time? I suppose going object oriented is
> > the proper way.

>
> > #Py3k,UTF-8

>
> > rates = {0: 0.006, 10000: 0.0085, 25000: 0.0124, 50000: 0.0149, 100000: 0.0173}
> > thresholds = list(rates.keys())
> > thresholds.sort()
> > thresholds.reverse()

>
> > def get_rate(balance):
> >     for threshold in thresholds:
> >         if balance >= threshold:
> >             return rates[threshold]
> >     else:
> >         return 0.0

>
> How 'bout:
>
> def get_rate(balance):
>     for threshold, rate in ((100000, .0173),
>                             (50000, .0149),
>                             (25000, .0124),
>                             (10000, .0085),
>                             (0, .006)):
>         if balance > threshold:
>             return rate
>     return .0

(1) you meant "if balance > threshold:"
(2) sequential search can be very fast if the sequence is in
descending order of probability of occurence ... you might like to
consider reversing the order
(3) for a much longer table, binary search using a function from the
bisect module could be considered
(4) in practice, the "default" action would not be "return 0.0";
perhaps something along these lines:

if balance < -overdraft_limit:
raise Exception(...)
return HUGE

John Machin, Dec 12, 2008
15. ### Bruno DesthuilliersGuest

Tim Rowe a écrit :
> 2008/12/12 Kirk Strauser <>:
>
>> def get_rate(balance):
>> for threshold, rate in ((100000, .0173),
>> (50000, .0149),
>> (25000, .0124),
>> (10000, .0085),
>> (0, .006)):
>> if balance > threshold:
>> return rate
>> return .0

>
> Yes, once it's changed from a dictionary to tuples it becomes easier,
> doesn't it? D'oh!
>

<comment>
A sequence of pairs and a dict are _almost_ interchangeable (mmm... is
that the correct word ?) representations of a same data set[1] - the
main difference being ordering. If ordering matters, choose a sequence
of pairs as main representation - you can easily build a dict from it
if/when you need it.

[1]
>>> d = dict(a=1, b=2, c=3)
>>> dict(d.items()) == d

True
>>>

</comment>

Bruno Desthuilliers, Dec 12, 2008
16. ### Tim RoweGuest

2008/12/12 John Machin <>:

> (2) sequential search can be very fast if the sequence is in
> descending order of probability of occurence ... you might like to
> consider reversing the order

I find it hard to imagine a bank with so many interest rate thresholds
that the search of the table is likely to be a significant
contribution to the run time!

> (3) for a much longer table, binary search using a function from the
> bisect module could be considered
> (4) in practice, the "default" action would not be "return 0.0";
> perhaps something along these lines:
>
> if balance < -overdraft_limit:
> raise Exception(...)

That's more likely to be in the withdrawal routine (and is probably
best not handled as an exception, because it's pretty much normal
flow). If a bank provided a service such as the one implemented by
this program, there'd be no need for it to know about overdraft limits
because it's not making actual transactions. Why would they increase
coupling unneccesarily?

--
Tim Rowe

Tim Rowe, Dec 12, 2008
17. ### John MachinGuest

On Dec 13, 6:49 am, "Tim Rowe" <> wrote:
> 2008/12/12 John Machin <>:
>

> > (4) in practice, the "default" action would not be "return 0.0";
> > perhaps something along these lines:

>
> > if balance < -overdraft_limit:
> >   raise Exception(...)

>
> That's more likely to be in the withdrawal routine

You'd certainly hope that this test would appear in the withdrawal
routine.

> (and is probably
> best not handled as an exception, because it's pretty much normal
> flow). If a bank provided a service such as the one implemented by
> this program, there'd be no need for it to know about overdraft limits
> because it's not making actual transactions. Why would they increase
> coupling unneccesarily?

Yeah, you're right, much easier to return 0% interest on a negative
balance [customers happy; no wear and tear on the call centre] and
hope that anomalies are checked somewhere else *and* that somebody #1
is tasked with actioning the anomaly reports and that somebody #2 is
keeping an eye on somebody #1.

John Machin, Dec 12, 2008
18. ### Lie RyanGuest

On Fri, 12 Dec 2008 04:58:36 -0800, feba wrote:

> Actually, I have gedit set to four spaces per tab. I have no reason why
> it's showing up that large on copy/paste, but the file itself is fine.

You've set gedit to _show tabs_ as four spaces, but not to substitute
tabs with four spaces.

Go to gedit's preference where you change how many spaces is used to
display tabs, right below it is "Insert spaces instead of tabs".

Lie Ryan, Dec 12, 2008
19. ### Lie RyanGuest

On Fri, 12 Dec 2008 09:50:43 -0800, Dennis Lee Bieber wrote:

> On Fri, 12 Dec 2008 03:42:55 -0800 (PST), declaimed the
> following in comp.lang.python:
>
>> #!/usr/bin/python
>> #Py3k, UTF-8
>>
>> bank = int(input("How much money is in your account?\n>>")) target =
>> int(input("How much money would you like to earn each year? \n>>"))
>>

> Just for my curiosity -- did Python 3.x (besides turning print

into
> a function) also change input() to behave as the old raw_input()?
>
> The above would be very discouraged in Python 2.x... in favor

of ...
> int(raw_input(...))
>

Actually, that's the first thing I wanted to bark on, before seeing the
little note above it: "#Py3k, UTF-8". I wonder though, there is a
potential problem if someone (users) is running this py3k code in a
python2.x. The code is a perfectly legal and correct python 2.x code, but
uses input() instead of raw_input(), we all know the evil of 2.x's input
().

Lie Ryan, Dec 12, 2008
20. ### Guest

Kirk Strauser:

> def get_rate(balance):
> for threshold, rate in ((100000, .0173),
> (50000, .0149),
> (25000, .0124),
> (10000, .0085),
> (0, .006)):
> if balance > threshold:
> return rate
> return .0

Nice code. This operation, of choosing an item in a sorted list of
intervals that has no holes, is common enough. But something like an
interval dict is overkill here.
I suggest to put a zero before all those points, to improve
readability and avoid some possible errors: it's easy to not see a

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

Bruno Desthuilliers:

> A sequence of pairs and a dict are _almost_ interchangeable (mmm... is
> that the correct word ?) representations of a same data set[1] - the
> main difference being ordering. If ordering matters, choose a sequence
> of pairs as main representation - you can easily build a dict from it
> if/when you need it.

Generally(*) it's better to use the simpler data structure that does
the job. Here a list/tuple of tuples is good.
Very often programs get translated to other languages, so keeping
things as simple as possible helps that too.

---------

(*) I have used 'generally' because there's a compromise to be taken
here.

In C and other related languages you often use structs or records, so
if you have pairs you give a name to the fields, for example "x" and
"y" for the two coordinates of a 2D Point. In Python in such situation
you can create a Point class, but often you instead use a (x, y) or
[x, y]. In some situations you need to access the fields, so you use
[0] and [1]. This is (was) a case where Python looks lower-lever than
the C language. In Python3/Python2.6+ you can use a NamedTuple too.

Is it better to give and take a list of points to/from as a list of
[x,y] lists or as a list of Point2D? Probably a Java programmer thinks
that using Point2D is safer and is a way to document what the function
takes/returns too. Extending the list of pairs to 3D points is a
little simpler if they are represented as tuples/lists.

That's an example where you may not choose the simpler data structure
(that in Python is a list of pairs) and use a list of NamedTuple to
make code "safer" even if the data structure is a little more complex.

Bye,
bearophile

, Dec 12, 2008