[Edu-sig] re: Types and true division (was Re: strange output)

[Arthur]

Danny -

I think your argument holds together perfectly were there in fact an
underlying unification of types in Python.

There is not.

Getting a conscious awareness of the practical issues involved remains a
practical necessity for working in Python - irrespective of the div operator
behavior.

At least if you are doing anything related to numerics.

And thanks for all your help to me and others as we try to contend with
these things.

Art

----- Original Message -----
From: "Danny Yoo" <dyoo@hkn.eecs.berkeley.edu>
To: "Arthur" <ajs@ix.netcom.com>
Cc: <edu-sig@python.org>
Sent: Thursday, October 10, 2002 2:22 PM
Subject: Re: [Edu-sig] re: Types and true division (was Re: strange output)


>
>
> > Only because Python is still young. Others have and I trust and hope
> > many others will share that experience in the future.
> >
> > > And what would that side effect be?  What's the benefit >of 1/2==0?
> >
> > Provides the signal and the reminder of the importance of giving
> > attention to the underlying numeric typing scheme.
>
> Hello!
>
> This model assumes that the programmer believes that division between
> integers is possible.  *grin*
>
>
> Seriously though, some other languages hold division as a very strict and
> dangerous thing.  Standard ML, for example, takes its types darn
> seriously: it doesn't even allow division between integers using '/'!
>
> ###
> - 1.0 / 2.0;
> val it = 0.5 : real
> - ;
> - ;
> - 1 / 2;
> stdIn:18.3 Error: overloaded variable not defined at type
>   symbol: /
>   type: int
> - ;
> - ;
> - 1 div 2;
> val it = 0 : int
> - ;
> - ;
> - 1.0 div 2.0;
> stdIn:23.5-23.8 Error: overloaded variable not defined at type
>   symbol: div
>   type: real
> ###
>
> (SML's prompt character is '- ', which is visually confusing...)
>
>
> ML'ers use a separate DIV operator that explicitely does truncation
> between integers.  So that is one potential future that Python could have
> turned toward, but all this typing does feel a bit like bondage.  If we
> really want to teach typing concepts, I don't think Python's the language
> to do this.
>
> Should a programming languages abstract the numeric model of the machine
> away from the programmer?  In the case of Python, it looks like the answer
> is leaning toward "yes", especially since it already has long integers and
> complex numbers (and probably rationals soon!) as basic types that the
> programmer can use.
>
>
> My feeling is that Python division doesn't have to reflect what the
> machine is doing underneath.  At long as we explain to folks that Python
> is an abstraction on top of the machine, I don't think it will cause
> long-term harm.
>
> The big problem is if we just use just Python alone to teach how computers
> work: that would be an extraordinarily unbalanced view!  If we want to
> show people the real details about computation, then we really should be
> doing this in combination with a low-level language like MIPS assembly.
> Have you thought about doing something like this?
>
>
> Best of wishes to you!
>
>