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

Geoffrey M. Furnish furnish@xdiv.lanl.gov
Tue, 20 Jan 1998 15:53:11 GMT


Charles G. Waldman writes:
 > 
 > Zane Motteler writes:
 > 
 >  > If i and j are the same type, then the "principle of least surprise"
 >  > says that x should be of the same type as i and j. 
 > 
 > To me, the "principle of least surprise" (and high-school algebra)
 > says that if b != 0, then b*(a/b) should be equal to a.  Values are
 > (to me) more important than types.  If we were to insist that division
 > always promotes its operands to float before dividing, and returns a
 > float, then 2*(1/2) returns 1.0, which, although not the same type as
 > the integer 1, represents the same value.  If you insist on being
 > type-centric, then 2*(1/2)==0 is true, which seems far weirder to me.

I am clearly a fence-sitter in this argument.  I definitely see both
sides.  To the extent that my comments fueled this back near the
beginning of the thread, my true surprise was in "discovering" what
the /true/ types of my operands were.  Once I knew the types, the
behavior was ocmprehensible.  Dynamic typing is just not something I
find real exciting.

I am not saying dynamic typing is worthless, or anything like that.
It clearly has uses, but it clearly also has failure modes which for
me, heinously violate the "principle of least surprise".  

With all this talk about fixing Python so it behaves reasonably, I
guess the fix I would most like to see would be some sort of a "type
constraint" mechanism.  If I could've said that that the operands to
my function were constrained to be of some type that supported
floating point arithematic, then I wouldn't have been bit.  

This doesn't necessarily have to be the same as static typing.  I am
not necessarily saying the function declaration/definition should
specify /the/ type of the operands, but perhaps a constraint on the
types of the operands, so that the true operands could be any of a
class of types which satisfy the type constraint.

This way, the integers could've been promoted to floats at the call
gate, without me having to dribble my function with explicit float
conversions. 

-- 
Geoffrey Furnish                    email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA  phone: 505-665-4529     fax: 505-665-5538

"Software complexity is an artifact of implementation."    -Dan Quinlan

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________