# [MATRIX-SIG] integer division -- what a concept!

**Carlos Maltzahn
**
Carlos Maltzahn <carlosm@moet.cs.colorado.edu>

*Fri, 16 Jan 1998 15:40:39 -0700 (MST)*

On Fri, 16 Jan 1998, Charles G Waldman wrote:
>*
*>* Paul F. Dubois writes:
*>*
*>* > Another way to look at it is, suppose you saw:
*>* >
*>* > x = i / j
*>* >
*>* > Wouldn't you be surprised that the type of x depended on the data?
*>* >
*>*
*>* I really don't understand this comment. It seems to me that this is
*>* the case currently; if I do
*>*
*>* i=1; j=2; x= i/j; print type(x)
*>*
*>* I get a different result than if I did
*>*
*>* i=1; j=2.0; x=i/j; print type(x)
*>*
*>* Isn't the type of x dependent on the data? (I'm not trying to be a
*
I don't understand this example either. Even if x is typed the result
would depend on whether i and j are both integer (matrix) variables or
not.
>* wise guy, I think I must be missing your point). Imagine that i and j
*>* aren't defined in the code but are being read in from a file. Then
*>* seeing the line "x = i/j" out of context, it's anybody's guess what
*>* the type of "x" will be. I'd rather have division *always* return a
*>* float, and maybe have another operator like "//" for explicit integer
*>* division.
*
I think the real issue is how you treat data import into a dynamically
typed environment and not whether we should have an extra operator for
explicit integer division (or all the other arithmetic operators for that
matter). As far as I know, NumPy lets you specify the type of matrix at
creation time. If you always specify the type of matrices at creation time
you would avoid any problems with integer division (unless your matrix
typing is wrong).
Geoffrey Furnish writes:
>* I suppose what bit me was really dynamic typing. Hmph.
*
I agree.
Carlos
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________