Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <kejcfi$s70$1@dont-email.me>
References: <keipl5$kif$1@dont-email.me> <mailman.1289.1359801291.2939.python-list@python.org> <keisev$7v1$1@dont-email.me> <mailman.1291.1359804020.2939.python-list@python.org> <keitk2$hln$1@dont-email.me> <mailman.1292.1359805138.2939.python-list@python.org> <keiujd$o71$1@dont-email.me> <mailman.1293.1359806334.2939.python-list@python.org> <kejcfi$s70$1@dont-email.me>
Date: Sun, 3 Feb 2013 03:00:30 +1100
Subject: Re: Floating point calculation problem
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1295.1359820833.2939.python-list@python.org>
Lines: 44
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:38082

On Sun, Feb 3, 2013 at 2:48 AM, Schizoid Man <schiz_man@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