Question about Py 2.2.x division operator 
Author Message
 Question about Py 2.2.x division operator

I am using python 2.2c1 and have a query regarding the use of division
operators.
I haven't seen this covered previously, but if it has, my apologies for
redundancy.
I understand that pre-2.2 the '/' would only perform 'floor' division
and truncate the remainder -- e.g. 7 / 4 == 1 -- but that with 2.2 '//'
would be used for floor division and '/' would be used for true division
-- e.g. 7 // 4 == 1 while 7 / 4 == 1.75. When I try this I can get the
fraction by using real numbers (i.e. 7.0 / 4 == 1.75) *without*
importing the future module, so what are the advantages of importing the
division component of the 'future' module unless I was only going to be
using integers? Would it be a useful 'failsafe' to reduce errors?

Cheers
AmF

--



Fri, 17 Jun 2005 03:35:37 GMT  
 Question about Py 2.2.x division operator


Quote:
> I am using Python 2.2c1 and have a query regarding the use of division
> operators.
> I haven't seen this covered previously, but if it has, my apologies
for
> redundancy.
> I understand that pre-2.2 the '/' would only perform 'floor' division
> and truncate the remainder -- e.g. 7 / 4 == 1 -- but that with 2.2
'//'
> would be used for floor division and '/' would be used for true
division
> -- e.g. 7 // 4 == 1 while 7 / 4 == 1.75. When I try this I can get the
> fraction by using real numbers (i.e. 7.0 / 4 == 1.75) *without*
> importing the future module, so what are the advantages of importing
the
> division component of the 'future' module unless I was only going to
be
> using integers? Would it be a useful 'failsafe' to reduce errors?

Neither one. Division ('/') has always worked that way, that is, if
one of the operands is a float, then the result is a float. It will
continue to work that way in the future. The "problem" was that
if both operands were integers, then the result would be an
integer, which means that the result would be truncated to what
could be represented by an integer.

The changes in 2.2 are twofold:

1. The new // operator which *always* performs floor
division regardless of the type of its operands or result,

and

2. the future division module, which forces the '/' operator to
always return a float with the real result, regardless of the
types of its operands. For compatibility, you will need to import
this until the mythical Python 3.0 release.

Whether this means anything at all to your programs depends
on your applications. AFIC, there's no good solution other than
to be consistent about each and every use of the division ('/')
operator as to whether it's using floats or integers, and whether
you want an integer, truncated float or full precision float result.

John Roth

- Show quoted text -

Quote:

> Cheers
> AmF

> --




Fri, 17 Jun 2005 04:52:12 GMT  
 Question about Py 2.2.x division operator
[ahimsa]

Quote:
> I am using Python 2.2c1

Get 2.2.2.  2.2c1 was a release candidate for 2.2 final, and had a useful
life of just a few dayes.

Quote:
> and have a query regarding the use of division operators.
> I haven't seen this covered previously, but if it has, my apologies
> for redundancy.

All the detail you can eat can be found here:

    http://www.python.org/peps/pep-0238.html

Quote:
> I understand that pre-2.2 the '/' would only perform 'floor' division
> and truncate the remainder

Provided that both operands were of integer types, yes.  If either argument
is complex, you got (and get, and always will get) a complex result instead.
If neither argument is complex, but at least one is a float, you got (and
get, and always will get) a float result instead.

Quote:
> -- e.g. 7 / 4 == 1

Right.  That's changing (see the link above).

Quote:
> -- but that with 2.2 '//' would be used for floor division

Should be used.  Nothing about the meaning of '/' has changed yet, but the
meaning of integer / integer *will* change.

Quote:
> and '/' would be used for true division -- e.g. 7 // 4 == 1 while 7 / 4
> == 1.75.

Eventually, but not yet.  Not even in Python 2.3.

Quote:
> When I try this I can get the fraction by using real numbers
> (i.e. 7.0 / 4 == 1.75)

Yes, and you always will.  Only the meaning of integer / integer will
change.  7.0 is a float literal (not an integer literal).

Quote:
> *without* importing the future module, so what are the advantages of
> importing the division component of the 'future' module unless I was
> only going to be using integers?

I didn't understand the question, but I bet reading the PEP will answer it
anyway <wink>.


Fri, 17 Jun 2005 04:34:12 GMT  
 Question about Py 2.2.x division operator

Quote:

> I am using Python 2.2c1 and have a query regarding the use of division
> operators.
> I haven't seen this covered previously, but if it has, my apologies for
> redundancy.
> I understand that pre-2.2 the '/' would only perform 'floor' division
> and truncate the remainder -- e.g. 7 / 4 == 1 -- but that with 2.2 '//'
> would be used for floor division and '/' would be used for true division
> -- e.g. 7 // 4 == 1 while 7 / 4 == 1.75. When I try this I can get the
> fraction by using real numbers (i.e. 7.0 / 4 == 1.75) *without*
> importing the future module,

As it should.  For floats, the / operator has always used true
division.

This means the value of x/y depends on the types of x and y.  This is
also the case in C and Java, but it's less of a problem in those
languages.

Quote:
> so what are the advantages of importing the
> division component of the 'future' module unless I was only going to be
> using integers?

The problem is that you can't always be sure of what type you're
using.  For example, suppose that one of the operands of your / was a
number input by the user.  Your function might expect a float, but one
of these days you'll type a whole number, forget to put a decimal
point after it, and wonder why your program is giving strange answers.

In C, it wouldn't matter, because when you write something like

double mid(double x, double y) {
   return (x + y) / 2;

Quote:
}

...
mid(anInt, anotherInt);

the compiler will add code to convert mid's arguments to
floating-point values, and you'll get the true division you'll expect.
 Not so in Python: mid(3, 4) != mid(3., 4.).

To guarantee consistent results in Python, you can add explicit
floatifying:

def mid(x, y):
   return (x + y) / 2.

def mid(x, y):
   return float(x + y) / 2

But there's the possibility that you'd forget to, or that you'd get
annoyed by having to type "float" everywhere and wish this behavior
was the default.  That's where "from __future__ import division" comes
in.



Fri, 17 Jun 2005 08:49:16 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Changing the Division Operator -- PEP 238, rev 1.12

2. beginners:Synthesability of mod operator,and division query

3. Numeric and the new division operator

4. PEP238, syntax suggestion for floor division operator (not div)

5. Changing the Division Operator -- PEP 238, rev 1.12

6. Pep 238 Why new // operator (Non-integer Division)

7. trying to run boa: problem with stc.py / stc_.py / stc_c.py

8. Division question ...

9. Procedure Division Question

10. floating point division -- question

11. Thanks - re: Question re division

12. operator overloading and user definable operators.

 

 
Powered by phpBB® Forum Software