(Very Newbie) Problems defining a variable

[febaen]

#!/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.

 

[Bruno Desthuilliers]

(e-mail address removed) 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

 

[feba]

(e-mail address removed) a écrit :







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

 

[Steven D'Aprano]

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

 

[Chris Rebert]

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

#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!
(I'm assuming Bruno's guess about your first test having the operator
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

 

[bearophileHUGS]

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
to read and understand) way.

Bye,
bearophile

 

[Bruno Desthuilliers]

feba a écrit :

On Dec 12, 5:56 am, Bruno Desthuilliers <bruno.
(e-mail address removed)> wrote: (snip) (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

 

[feba]

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,
in addition to using your recommendations on readability and
efficiency in getting the rate

 

[Marc 'BlackJack' Rintsch]

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

 

[Tim Rowe]

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))

 

[MRAB]

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

 

[John Machin]

        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()

 

[Tim Rowe]

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!

 

[John Machin]

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.

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

 

[Bruno Desthuilliers]

Tim Rowe a écrit :

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]</comment>

 

[Tim Rowe]

(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?

 

[John Machin]

2008/12/12 John Machin <[email protected]>:



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.

 

[Lie Ryan]

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]

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
().

 

[bearophileHUGS]

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
small leading point.

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

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