From ok@atlas.otago.ac.nz  Thu May 11 07:28:01 2000
Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id HAA26582;
	Thu, 11 May 2000 07:27:58 +0200 (MET DST)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id RAA18539;
	Thu, 11 May 2000 17:28:02 +1200 (NZST)
Date: Thu, 11 May 2000 17:28:02 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200005110528.RAA18539@atlas.otago.ac.nz>
To: ino-waiting@gmx.net, jan@swi.psy.uva.nl, prolog@swi.psy.uva.nl
Subject: Re: handling small numbers

Jan Wielemaker <jan@swi.psy.uva.nl> wrote:
	All in all, I think I vote for the introduction of a prolog flag. 
	Basically, to an engineer 100000000 =:= 100000000.0 (and =~=
	100000000.1), but to a mathematician this is complete nonsense (and
	actually floats by themselves are very close to nonsense :-).
	
Oh xxxx, not another Prolog flag.
I thought I had already explained that prolog flags make it unreasonably
hard to write library code.
They are, after all, global variables.

I note that there is a standard for doing integer and floating point
numbers in programming language standards, the "Language Independent
Arithmetic" standard, with two parts that I know of.  I've a notion
that it was consulted during the development of ISO Prolog.

The programming languages that engineers actually use:  Fortran, C, C++,
and to some extent Ada, keep integer arithmetic clearly separate from
floating point arithmetic via the type system.  (Ok, sometimes engineers
use spreadsheets, but a meta-survey of spreadsheets done in Hawaii found
that about a quarter of spreadsheets, including ones used in banks, got
their sums wrong.)

Has anyone in this list ever used APL?
Remember the contortions you had to go through to be independent of []IO?
Remember the even nastier problems you had protecting against other code's
changes to []CT?  The proposed flag is very very close to []CT.

You could make an excellent case for a Prolog *dialect* that had a
single data type `number' instead of `integer' and `float'.  All the
major floating-point systems I've looked at (IBM System/360, B6700,
DEC-10, VAX, IEEE) can, in double precision, handle a usefully wide
range of integers *exactly*.  In fact the "Brown" axioms (which my
paper on specifying arithmetic for Prolog cited) guarantee that this must
be so.

The thing is that Prolog _does_ have separate `integer' and `float' types,
with different behaviour, and quietly sliding from one to the other, so that
they are *SOMETIMES* different and *SOMETIMES* the same, and it's not
predictable from the code itself which, is a really really bad idea.

An ``all numbers are floats, but some of them exactly represent integers''
dialect would be free of this criticism.  It would *not* be changing the
expected type behind the scenes, it would not be switching without the
programmer's explicit say-so from one set of axioms to another, it would
be *consistently* obeying the Brown (or the IEEE) axioms for all numbers.

	This flag can also deal with 4.5 @< 3, which is true according to ISO
	Prolog, but false in SWI-Prolog default's behaviour (true if the iso
	flag is set to true).

Note that Quintus Prolog correctly and consistently distinguished between
integers and floats, *but* sorted them together (as recommended by me in
1984 in PS/6) so that @< and < were as compatible as possible.  It's clear
that a system that quietly returns the wrong type without explicit permission
is going to provide even more headaches for programmers if that disrupts the
sort order, but a system that consistently gets its types right has the
choice of doing things the ISO way or the right way.

	To an engineer, doing sort/2 on an array of mixed
	floats and ints and getting all floats in front is pretty weird.

I think it's pretty weird for anyone.  It's certainly consistent with
Lisp to intermingle them, and PS/6 (unlike ISO Prolog) includes the
results of serious consideration of Prologs embedded in Lisp.
	
	So, this flag should basically tell Prolog whether or not floats and
	ints should both be regarded as coming from one space or not.  A
	suggestion for a good name?
	
Keep the two issues separate.
A language which gets the types right and
a language which quietly returns the wrong type
are *different* languages which are best kept separate;
it's especially dangerous to try to mix them temporally
in the same code.  Make that one a command line flag,
with a pragma so that
	:- pragma(integer_overflow(exception)).
or
	:- pragma(integer_overflow(float)).
would cause a source file to be rejected if the system were not operating
in that mode.  Files without that pragma would be presumed not to care.

