On Sun, Feb 3, 2013 at 2:48 AM, Schizoid Man <schiz_...@21stcentury.com> wrote:
> def Numer(s, k):
> return math.log(s / k)
>
> s = float(input("Enter s: "))
> k = float(input("Enter k: "))
> print("Result: ", Numer(s, k))
>
> For the v2.7 version, the only difference is the input lines:
>
> s = input("Enter s: ")
> k = input("Enter k: ")
>
> So for values of s=60 and k=50, the first code returns 0.1823215567939546
> (on the PC), whereas the second returns 0.0 (on the Mac). This this
> expression is evaluated in the numerator, it never returns a divide by zero
> error, and the result of 0 is treated as legitimate.
So on your Python 2 install, you're working with integers, dividing
one by another, and getting back a value of 1 - and log(1) is 0. The
problem is your division operator, which can be fixed as Steven
suggests, with the future directive.
> However, if I cast the v2.7 inputs as float() then it does indeed return the
> right result. But what threw me was that no cast didn't result in a runtime
> error in 2.7, but did in 3.3.
>
> Also, if the cast is necessary, then now exactly does the dynamic typing
> work?
It's not quite a cast. Python's type system is broadly this: Every
object (value) has a type, every name (variable, sort of) doesn't. So
I can do this:
spam = "hello, world" # spam is a string
spam = 5 # spam is now an int
spam = (1,2,3) # spam is now a tuple
spam = object() # you get the idea
I strongly recommend you either go with Python 3 or raw_input, but NOT
with float(input()) in Py2. Go with float(raw_input()) and you're
doing exactly one translation, and the correct one.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
