[Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich , comparison

Alex Martelli aleaxit at yahoo.com
Wed Oct 25 10:12:03 CEST 2000

"Steven D. Majewski" <sdm7g at virginia.edu> wrote in message
news:mailman.972451147.10397.python-list at python.org...
> On Wed, 25 Oct 2000, Donald O'Donnell wrote:
> > Correct, that's called operator overloading, a form of polymorphism.
> > I've seen postings in the past where someone has complained about
> > the fact that 5/2 results in 2.  I can't, for the life of me
> > understand why anyone would want it to be otherwise.  Every
> > main-stream language I've ever used (Fortran, COBOL, Basic,
> > C, C++, Java,...) have all truncated the result of integer
> > division to an integer, and that can be very useful.
> Well -- again those are all statically typed languages where
> variables have a fixed type. ( Not sure if modern Basics still
> fit that catagory -- they did in the old days when I last used
> Basic. )

Visual Basic has 5/2 return 2.5.  It IS statically typed, but
often rather weakly (a common type is "variant", which means
a discriminated union of just about any other type; another is
"object", which means just about any non-elementary type).

Pascal is statically and strongly typed, yet has 5/2 return 2.5;
a specific operator, DIV, is supplied for truncating division
of integers (5 DIV 2 does return 2).  I think Pascal derivatives
follow Pascal in this.

Haskell is statically and strongly typed, yet has 5/2 return
2.5 :: Double.  Asking the interactive listener (HUGS98)
about / responds:

Prelude> :type (/)
(/) :: Fractional a => a -> a -> a

i.e., (/) is a function that applies to any value whose type
is in typeclass Fractional (one way to look at it is that it
takes 2 values of such a type, and returns a value of the
same type).
Again, you get an alternative function, for truncating division
of integral values, whose name will not surprise Pascal'ers...:

Prelude> :type div
div :: Integral a => a -> a -> a

OCAML is statically and strongly typed, and _never_ overloads
operators: operators intended to apply to floating-point values
include a dot.  So, e.g., 2.0+4.0 is a typing error (you have
to write 2.0 +. 4.0).  Unsurprisingly, therefore, 5/2 returns 2,
and 5.0/2.0 is also an error (5 /. 2 returns 2.5).  I do *NOT*
consider this peculiarity a strong point of OCAML:-).

> Among dynamically typed languages, Lisp and Scheme return either
> floats or rationals. Don't know offhand about Smalltalk.
> I can't recall S+ and I don't know Matlab, but I would be surprised
> if they didn't follow Lisp.

Perl considers 5/2 to be worth 2.5, _except_ if you have
a "use integer;" in the current module, 'of course', in
which case all arithmetic is integral.

Dylan, a language whose typing (and other features...) is
an idiosyncratic and interesting mix of static and dynamic,
considers 5 / 2 (spaces are mandatory, as 5/2 would be
a single token -- another Dylan peculiarity...) an error,
"no defined method for generic function /".  5.0 / 2 and
5 / 2.0 _are_ both defined (and return 2.5), but the
language apparently avoids committing to a specific way
to divide _integers_:-).  You may, of course, give a
specific "method" for the "generic-function" / when
applied to integers, for any given module.

> >            Try writing
> > a binary search (where you are constantly dividing your
> > range by 2) -- not much fun if the interpreter/compiler keeps
> > secretly changing your integer indexes to floats every time you
> > have an odd sized range.  If you really want a floating point
> > result in the above example, all you need to do is use a/2.0
> > -- see, you are in control this way, not the compiler

I've written lots of binary searches back when I was using
Pascal, and using "a div 2" was absolutely no hardship, nor
did it in any way interfere with "me being in control".

> It's not much fun it the interpreter/compiler keeps secretly
> truncating correct answers to incorrect ones every time your
> args aren't evenly divisible. If you really wanted it truncated,
> all you need to do is use floor/ceil/int. ( Works fine for binary
> searches too! )

Seems a waste of effort to compute the fractional-result when
all I'm interested in is its integer-part; I would much rather
have a way to ask for that integer-part *directly*, with a div
operator or function. Often, when I want that, I also want the
remainder, in which case existing function divmod is just
right; but I'd like to have separate div and mod too, for
those cases in which I _don't care_ about the other part -- as
"explicit is better than implicit", why not let me be explicit
about 'not caring', rather than "implicitly" expressing it by
doing nothing further with the computed-anyway value...?


More information about the Python-list mailing list