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)

it's-often-not-pretty-in-haskell-either-ly y'rs  - tim



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
address the underlying problem.

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
minimalism. If some addition can already be achieved through a simple
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"
Advanced MP Technology



Sat, 06 Sep 2003 01:39:47 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

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

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

3. Future division patch available (PEP 238)

4. Future division patch available (PEP 238)

5. PEP 238 (revised)

6. awk's mod operator % question (application: log base2 non-integer result)

7. Numeric and the new division operator

8. PEP: Adding new operators for elementwise/objectwise operations

9. integer/integer division

10. Why reliable loop variants must non-INTEGER expressions

11. Near Final PEP 237 - Unifying Long Integers and Integers

12. Revised PEP 237 - Unifying Long Integers and Integers

 

 
Powered by phpBB® Forum Software