Pep 238 Why new // operator (Non-integer Division)
Author Message
Pep 238 Why new // operator (Non-integer Division)

[Gordon Williams]

Quote:
> Why do we need a new // operator to do the divide operation.  If
> we want to do an integer divide with two reals why wont people just
> use int(a/b).  For

1. int() truncates.  Current i/j returns the floor.

2. There is no bound on the sizes of i and j; it's very easy to
get python long ints that don't fit in a Python float.

Wed, 03 Sep 2003 08:14:54 GMT
Pep 238 Why new // operator (Non-integer Division)
Also, integer division is fairly common and a direct implementation is
significantly faster than floor(a/b).

Hey, I know: maybe "a//b" should be "a log b".  That way // is
the inverse operator of **.  :-)  Dang, if only I had time to
write PEPs. :-)

Quote:
----- Original Message -----

Sent: Friday, March 16, 2001 6:14 PM
Subject: RE: Pep 238 Why new // operator (Non-integer Division)

> [Gordon Williams]
> > Why do we need a new // operator to do the divide operation.  If
> > we want to do an integer divide with two reals why wont people just
> > use int(a/b).  For

> 1. int() truncates.  Current i/j returns the floor.

> 2. There is no bound on the sizes of i and j; it's very easy to
>    get Python long ints that don't fit in a Python float.

> --
> http://mail.python.org/mailman/listinfo/python-list

Wed, 03 Sep 2003 07:08:38 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:

> [Gordon Williams]
> > Why do we need a new // operator to do the divide operation.  If
> > we want to do an integer divide with two reals why wont people just
> > use int(a/b).  For

> 1. int() truncates.  Current i/j returns the floor.

> 2. There is no bound on the sizes of i and j; it's very easy to
>    get Python long ints that don't fit in a Python float.

BTW, I guess I'm not the first one to notice that this new operator
looks an awful lot like a C/C++ comment.  So maybe some other symbol
should be used.

Hey, isn't "\$" still open? <wink>

just-tryin'-to-make-a-buck-ly y'rs,

=g2
--
_____________________________________________________________________

Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation            http://www.iowegian.com

Wed, 03 Sep 2003 12:51:42 GMT
Pep 238 Why new // operator (Non-integer Division)
[Grant Griffin]

Quote:
> BTW, I guess I'm not the first one to notice that this new operator
> looks an awful lot like a C/C++ comment.

No, you're the first!  329 people did note that // looks an awful lot like
fortran's string concatenation operator.  I expect these were the same 329
who complained to the C++ committee about abusing *their* prior art.

Quote:
> So maybe some other symbol should be used.

Why bother?  Python's # looks an awful lot like C++'s preprocessor directive
flag too.  Guido would probably prefer infix "div" (a la Pascal), but a new
keyword is a very hard sell.

Quote:
> Hey, isn't "\$" still open? <wink>

Barry has first dibs on that one, to make

print \$ fileobject, 2, "+ 5% tax =", 2*1.05

print

\$2.00 + \$0.10 = \$2.10

Curiously, he will ignore the fileobject in this case, unless it's spelled

print \$ >> fileobject, 2, "+ 5% tax =", 2*1.05

I forget what

print >> \$fileobject, 2, "+ 5% tax =", 2*1.05

is going to mean.  I *think* it reads the next line from fileobject, strips
the newline, then uses that as the name of the file to print to (after
opening for append).

Quote:
> just-tryin'-to-make-a-buck-ly y'rs,

sell-documentation-for-barry's-proposals!-ly y'rs  - tim

Wed, 03 Sep 2003 14:38:17 GMT
Pep 238 Why new // operator (Non-integer Division)

[snip]

Quote:
> > So maybe some other symbol should be used.

> Why bother?  Python's # looks an awful lot like C++'s preprocessor
directive
> flag too.  Guido would probably prefer infix "div" (a la Pascal), but a
new
> keyword is a very hard sell.

So what's so terrible about non-infix notation, a builtin div(a,b) [and
mod(a,b)
too since we're at it...?].  Sure, infix can be handy -- but then this might
be
the occasion to steal a leaf from Haskell's book... let any 2-operand
function
be used as an infix operator (possibly with some stropping if that is needed
to disambiguate syntax).

Alex

Wed, 03 Sep 2003 16:13:26 GMT
Pep 238 Why new // operator (Non-integer Division)
Why do we need a new // operator to do the divide operation.  If we want to
do an integer divide with two reals why wont people just use int(a/b).  For
example:

Quote:
>>> 5/2
2
>>> int(5.0/2.0)
2

The only difference with what is described below is a//b will result in a
object of type a while int(a/b) will be of type int.  Does this really need
the use of another operator??

Lets keep it simple.  (And that goes for the other Peps as well)

All these changes make my head spin.  There is more to life than learning
all the fine details in a computer language.  The fewer number of ways to do
something the better.

Regards,

Gordon Williams

// Operator

A `//' operator which will be introduced, which will call the
nb_intdivide or __intdiv__ slots.  This operator will be
implemented in all the Python numeric types, and will have the
semantics of

a // b == floor(a/b)

Except that the type of a//b will be the type a and b will be
coerced into.  Specifically, if a and b are of the same type, a//b
will be of that type too.

Tue, 02 Sep 2003 23:39:10 GMT
Pep 238 Why new // operator (Non-integer Division)
[Alex Martelli]

Quote:
> So what's so terrible about non-infix notation, a builtin div(a,b) [and
> mod(a,b) too since we're at it...?].  Sure, infix can be handy --

Infix is also a speed issue in Python, since syntax is fixed but builtin
names are not reserved; so the speed freaks will surely argue for syntax.

Quote:
> but then this might be the occasion to steal a leaf from Haskell's
> book... let any 2-operand function be used as an infix operator
> (possibly with some stropping if that is needed to disambiguate
> syntax).

I'll let someone else channel Guido on this one.  Who's up to the challenge?

x delattr "attr"
lamdba x: x%2 filter x
"channel.txt" open "w"
3 complex ("beef" int 16)

Wed, 03 Sep 2003 17:50:30 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:

>All these changes make my head spin.  There is more to life than learning
>all the fine details in a computer language.  The fewer number of ways to do
>something the better.

Just because the changes are being made doesn't mean you have to USE them.
You wouldn't be the only one sticking to 1.5.2.  I like the more rapid
pace of development, but I'm mostly running 1.5.2 right now because I
don't want to start writing code that's going to break on a few dozen
machines.  ;-)

Sean
--
I think you are blind to the fact that the hand you hold
is the hand that holds you down.  -- Everclear

tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

Wed, 03 Sep 2003 17:39:07 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:
>>All these changes make my head spin.  There is more to life than learning
>>all the fine details in a computer language.  The fewer number of ways to do
>>something the better.

>Just because the changes are being made doesn't mean you have to USE them.

This isn't true; the moment you encounter code written by someone else,
you DO have to use them. This simple principle is the magic of Python
minimalism, and the primary driving reason why new Python programmers
can become so effective so fast (IMO).

C//

Thu, 04 Sep 2003 03:51:24 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:

> >>All these changes make my head spin.  There is more to life than learning
> >>all the fine details in a computer language.  The fewer number of ways to do
> >>something the better.

> >Just because the changes are being made doesn't mean you have to USE them.

> This isn't true; the moment you encounter code written by someone else,
> you DO have to use them. This simple principle is the magic of Python
> minimalism, and the primary driving reason why new Python programmers
> can become so effective so fast (IMO).

> C//

Adding 'line noise' symbols to a language doesn't help at all.  It doesn't even

The difference between fixed/floating point arithmetic resides in the operands,
not the operators.

For example, consider fixed point(precision,scale) arithmetic for variables like

A decimal(5,2)

B decimal(3,1)

C decimal(9,6)

You want to detect overflows when A = B / C exceeds 999.99.  You want to round
'appropriately' to .01 without knowing what an LSB is.  And so on.

This is garden-variety, every-day commercial arithmetic.  Your paycheck and tax
witholding are calculated this way.

Python, actually, can handle 'decimal arithmetic' very well:  define variables as
{name:(integer value,precision,scale)} with functions for add, subtract, multiply,
divide, move, compare, and display.

Let's reserve the 'line noise' infix operators for enhancing Python's complex
arithmetic to handle the octonions.

Thu, 04 Sep 2003 10:29:28 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:

> >>All these changes make my head spin.  There is more to life than learning
> >>all the fine details in a computer language.  The fewer number of ways to do
> >>something the better.

> >Just because the changes are being made doesn't mean you have to USE them.

> This isn't true; the moment you encounter code written by someone else,
> you DO have to use them. This simple principle is the magic of Python
> minimalism, and the primary driving reason why new Python programmers
> can become so effective so fast (IMO).

> C//

[ simulated persona = "Kurt G?del", node #157, max search depth 49%, neural
variance 12.180 ]

For simplicity's sake I do all my computations in the base-pi number
system. In
this system pi=10.

Thu, 04 Sep 2003 11:16:03 GMT
Pep 238 Why new // operator (Non-integer Division)

:           For simplicity's sake I do all my computations in the base-pi number
:system. In
:           this system pi=10.

Um, in base pi, wouldn't pi = 1   ???

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/

Thu, 04 Sep 2003 13:45:16 GMT
Pep 238 Why new // operator (Non-integer Division)

:
:Um, in base pi, wouldn't pi = 1   ???

Oh, crud, never mind. You're right. pi = 10. Duh.

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/

Thu, 04 Sep 2003 14:01:22 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:

>> This isn't true; the moment you encounter code written by someone else,
>> you DO have to use them. This simple principle is the magic of Python
>> minimalism, and the primary driving reason why new Python programmers
>> can become so effective so fast (IMO).
>           For simplicity's sake I do all my computations in the base-pi number
>system. In this system pi=10.

While I perceive a shadowy point here, the fact of the matter is that the more
features you add to a language, the more a new programmer must know in
order to read code produced by more experienced programmers. I'm a big
fan of Python's minimalism for this case, and believe it's one of its strong
selling points. The relative paucity of forms in Python is a strength, not a
weakness. If Python departs from this aspect of its origin, it will no longer
really be Python.

This isn't to say that I'm against the growth of the language. I merely would
like to point out that all additions are at odds with Python's principal of
means in Python, perhaps it shouldn't be added.

Python is not Perl.

C//

Thu, 04 Sep 2003 14:47:31 GMT
Pep 238 Why new // operator (Non-integer Division)

Quote:
Tim Peters writes:
> [Alex Martelli]
>> So what's so terrible about non-infix notation, a builtin div(a,b) [and
>> mod(a,b) too since we're at it...?].  Sure, infix can be handy --
> Infix is also a speed issue in Python, since syntax is fixed but builtin
> names are not reserved; so the speed freaks will surely argue for syntax.
>> but then this might be the occasion to steal a leaf from Haskell's
>> book... let any 2-operand function be used as an infix operator
>> (possibly with some stropping if that is needed to disambiguate
>> syntax).

Many Prologs also have this capability, with a way to define prefix, infix,
and postfix operators, along with precedence values to determine grouping.

--
Don Dwiggins                    "Solvitur Ambulando"