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
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
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
--
http://mail.python.org/mailman/listinfo/python-list
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
made a function like this:
On Sun, Feb 3, 2013 at 2:48 AM, Schizoid Man 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: ")
>
"Schizoid Man" wrote in message
news:kejcfi$s70$1...@dont-email.me...
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 erro
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 =
Schizoid Man wrote:
> I know this is probably redundant but Python 2.7.3 is running on a Mac and
> 3.3.0 on a PC, so it's not exactly an apples-v-apples comparison.
It's not impossible that there is a slight difference in some of the
floating point functions. E.g. when you call math.log(s), one v
Schizoid Man wrote:
> I have a program that performs some calculations that runs perfectly on
> Python 2.7.3. However, when I try to execute it on Python 3.3.0 I get the
> following error:
> numer = math.log(s)
> TypeError: a float is required
>
> The quantity s is input with the following li
On Sat, Feb 2, 2013 at 10:51 PM, Schizoid Man wrote:
>> If your input has no decimal point in it, eval (or input) will return
>> an integer, not a float. Other than that, I can't see any obvious
>> reason for there to be a difference. Can you put together a simple
>> script that demonstrates the p
If your input has no decimal point in it, eval (or input) will return
an integer, not a float. Other than that, I can't see any obvious
reason for there to be a difference. Can you put together a simple
script that demonstrates the problem and post it, along with the exact
input that you're giving
Highly unlikely. I'd say impossible, unless you type a different value for
x
of course. By the time the input() function returns, the result is already
a float. Wrapping it in float() again cannot possibly change the value. If
you have found a value that does change, please tell us what it is.
T
Schizoid Man wrote:
> "Chris Angelico" wrote in message
> news:mailman.1289.1359801291.2939.python-l...@python.org...
>> On Sat, Feb 2, 2013 at 9:27 PM, Schizoid Man
>> wrote:
>>> The quantity s is input with the following line: s = input("Enter s:
>>> ")
>>>
>>> To get rid of the compile erro
On Sat, Feb 2, 2013 at 10:34 PM, Schizoid Man wrote:
>> raw_input() takes a line from the keyboard (handwave) and returns it
>> as a string.
>>
>> input() in 2.X takes a line from the keyboard and evaluates it as a
>> Python expression.
>>
>> float() takes a string, float, int, etc, and returns th
raw_input() takes a line from the keyboard (handwave) and returns it
as a string.
input() in 2.X takes a line from the keyboard and evaluates it as a
Python expression.
float() takes a string, float, int, etc, and returns the
nearest-equivalent floating point value.
What's the input you're givi
On Sat, Feb 2, 2013 at 10:14 PM, Schizoid Man wrote:
> Scratch that, I'm not sure which result is right now, so need to look at the
> full calculations in details. What would be the difference between
> raw_input() and float(input())?
>
> Thanks again.
Depends on what you type in.
raw_input() ta
"Chris Angelico" wrote in message
news:mailman.1289.1359801291.2939.python-l...@python.org...
On Sat, Feb 2, 2013 at 9:27 PM, Schizoid Man
wrote:
The quantity s is input with the following line: s = input("Enter s: ")
To get rid of the compile error, I can cast this as a float: s =
float(in
On Sat, Feb 2, 2013 at 2:27 AM, Schizoid Man wrote:
> I have a program that performs some calculations that runs perfectly on
> Python 2.7.3. However, when I try to execute it on Python 3.3.0 I get the
> following error:
>numer = math.log(s)
> TypeError: a float is required
>
> The quantity s
On Sat, Feb 2, 2013 at 9:27 PM, Schizoid Man wrote:
> The quantity s is input with the following line: s = input("Enter s: ")
>
> To get rid of the compile error, I can cast this as a float: s =
> float(input("Enter s: "))
>
> However, then the result returned by the method is wrong. Why does
I have a program that performs some calculations that runs perfectly on
Python 2.7.3. However, when I try to execute it on Python 3.3.0 I get the
following error:
numer = math.log(s)
TypeError: a float is required
The quantity s is input with the following line: s = input("Enter s: ")
To
20 matches
Mail list logo
