Velocity Reviews > Re: Floating point calculation problem

# Re: Floating point calculation problem

Schizoid Man
Guest
Posts: n/a

 02-02-2013
> Ah, there may well be something in that. Definitely post the code and
> outputs; chances are someone'll spot the difference.

Ok, I *think* I found the source of the difference:

This is the base code that runs fine in v 3.3.0 (the output is correct):

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.

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?

Thanks.

Schizoid Man
Guest
Posts: n/a

 02-02-2013
"Schizoid Man" <(E-Mail Removed)> wrote in message
news:kejcfi\$s70\$(E-Mail Removed)...

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

D'oh! That's the error right there. My inputs are 60 and 50, not 60.0 and

Chris Angelico
Guest
Posts: n/a

 02-02-2013
On Sun, Feb 3, 2013 at 2:48 AM, Schizoid Man <(E-Mail Removed)> 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

Michael Torrie
Guest
Posts: n/a

 02-02-2013
On 02/02/2013 08:48 AM, Schizoid Man wrote:
> Also, if the cast is necessary, then now exactly does the dynamic typing
> work?

Dynamic typing isn't referring to numeric type coercion. It refers to
the fact that a name can be bound to an object of any type. So if you

return num1 + num2

num1 and num2 could be any type. Even a custom type if you wanted.
This function would work properly on any type that had implemented the
__add__ method. And whether or not num2 has to be the same type as num1
depends on whether the num1 type has implemented an __add__ method that
can deal with the type of num2.

Another case where dynamic typing comes into play is in a case know as
duck typing:

def squeeze_duck (duck):
// return the quack
return duck.squeeze()

duck can be of any type as well, but as long as it implements the
squeeze method, this function will work with an object of that type.

In a language like C#, duck-typing can only be emulated by using
interface classes.

Steven D'Aprano
Guest
Posts: n/a

 02-03-2013
Michael Torrie wrote:

> def squeeze_duck (duck):
> // return the quack
> return duck.squeeze()

I'm curious, what language were you thinking of when you wrote the comment
using // instead of # ?

--
Steven

Dave Angel
Guest
Posts: n/a

 02-03-2013
On 02/02/2013 08:25 PM, Steven D'Aprano wrote:
> Michael Torrie wrote:
>
>> def squeeze_duck (duck):
>> // return the quack
>> return duck.squeeze()

>
> I'm curious, what language were you thinking of when you wrote the comment
> using // instead of # ?
>
>

I'm guessing that would probably be C++. Or more recent versions of C.

--
DaveA

Michael Torrie
Guest
Posts: n/a

 02-03-2013
On 02/02/2013 06:25 PM, Steven D'Aprano wrote:
> Michael Torrie wrote:
>
>> def squeeze_duck (duck):
>> // return the quack
>> return duck.squeeze()

>
> I'm curious, what language were you thinking of when you wrote the comment
> using // instead of # ?

Oh darn. Blew my cover. I'm beta testing Ranting Rick's wonderful
fork, Rrython.

Actually, my brain is full of Arduino code right now... which is fun,
but C++, yuck.