Dividing integers...Convert to float first?

[redefined.horizons]

I'm still pretty new to Python. I'm writing a function that accepts
thre integers as arguments. I need to divide the first integer by te
second integer, and get a float as a result. I don't want the caller of
the function to have to pass floats instead of integers. How do I
convert the arguments passed to the function into floats before I do
the division? Is this necessary, or is their a better way?

Thanks,

Scott Huey

 

[Thomas Ploch]

I'm still pretty new to Python. I'm writing a function that accepts
thre integers as arguments. I need to divide the first integer by te
second integer, and get a float as a result. I don't want the caller of
the function to have to pass floats instead of integers. How do I
convert the arguments passed to the function into floats before I do
the division? Is this necessary, or is their a better way?

Thanks,

Scott Huey

Yes, it is necessary. If you divide two integers, the result will be an
integer.
0

You need the function float() -> float because a division between
integers and floats will have floats as their results
0.5

 

[Jonathan Smith]

Yes, it is necessary. If you divide two integers, the result will be an
integer.

0

You need the function float() -> float because a division between
integers and floats will have floats as their results

0.5

-smithj

 

[Grant Edwards]

0.5

$ python
Python 2.4.3 (#1, Dec 10 2006, 22:09:09)
[GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Damn.

I guess it's back to work then.

 

[Thomas Ploch]

0.5

-smithj

aahh, I have been tought so many things about python that are actually
so old, that I am starting to feel embarrassed.

That brings me to the point, that learning a language X at university
always brings you to a point where you know (almost) everything, but in
reality know nothing because course material is too old...

Thomas

 

[Thomas Ploch]

0.5

$ python
Python 2.4.3 (#1, Dec 10 2006, 22:09:09)
[GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Damn.

I guess it's back to work then.

You are working as an oracle?



Thomas

 

[Simon Brunning]

File "<stdin>", line 1
SyntaxError: future feature LotteryNumbers is not defined

Damn.

I guess it's back to work then.

Remember the PEP 8 module name standards.
[1, 16, 19, 20, 21, 39]

 

[Paul McGuire]

File "<stdin>", line 1
SyntaxError: future feature LotteryNumbers is not defined

Damn.

I guess it's back to work then.

Remember the PEP 8 module name standards.
[1, 16, 19, 20, 21, 39]

The computer printed it out, it must be correct! We can all become
millionaires!

(Now if we only knew which drawing in the future, and from which lottery...)

-- Paul

 

[Beliavsky]

aahh, I have been tought so many things about python that are actually
so old, that I am starting to feel embarrassed.

That brings me to the point, that learning a language X at university
always brings you to a point where you know (almost) everything, but in
reality know nothing because course material is too old...

If you learned C or Fortran 10 years ago, the constructs you learned
still have the same meaning, even though new features have been added
in C99 or Fortran 95. Mr. van Rossum appears to value backwards
compatibility less than the C or Fortran standards committees do,
although I am sure he is introducing incompatibilities only after
serious consideration. If the C or Fortran committees tried to change
the meaning of int/int, they would be shot.

If you want to be confident that your code will run, unchanged, 10
years from now on the hardware and OS that will then be common, Python
2.x is not the language to use, unfortunately. From what I have read,
Python 3 will break things more fundamental than int/int.

 

[Dan Bishop]

so old, that I am starting to feel embarrassed.

Don't feel embarrassed. "from __future__ import division" was added to
Python only five years ago, so the tutorial writers haven't had enough
time to mention it yet.

Just remember that it's a good idea to use "from __future__ import
division" (or better, "from __future__ import division as _division")
in every module, and if you really want integer division, use the //
operator instead of /. This will ensure that your code will continue
to work correctly in Python 3.0, and that you won't be bitten by subtle
bugs like

def mean(num_list):
return sum(num_list) / len(num_list)

 

[Thomas Ploch]

If the C or Fortran committees tried to change
the meaning of int/int, they would be shot.

Or hanged...

If you want to be confident that your code will run, unchanged, 10
years from now on the hardware and OS that will then be common, Python
2.x is not the language to use, unfortunately. From what I have read,
Python 3 will break things more fundamental than int/int.

Yes, but until then we have to use python 2.x. And I think that python
2.x will be around quite a while after python 3000 has been released if
it breaks so much.

Thomas

 

[rzed]

File "<stdin>", line 1
SyntaxError: future feature LotteryNumbers is not defined

Damn.

I guess it's back to work then.

Remember the PEP 8 module name standards.
[1, 16, 19, 20, 21, 39]

My Python version is so old that I only get three numbers. I guess
I'll have to upgrade.