🚀 go-pugleaf

In article <1214@robin.cs.nott.ac.uk>, abc@cs.nott.ac.uk (Andy Cheese) writes:
> having agreed all integers are reals, and the only thing a float can be
> is a float, lets look at BSI document PS/172 page 17 bip real/1.
> real(X) succeeds if X is a real, it doesn't say succeeds if X is a float.
> if i see the word "real" writen in english when refering to numbers i expect
> it to mean real numbers.
> 
> real(3). fails
> real(3.3) succeeds.
> what is this nonsense.
> 
> float(3). fails
> float(3.3). succeeds
> this makes more sense.
> 
> oh Richard why do you (according to the document) say reals are the
> opposite of complex, reals are complex numbers, or else you've changed
> the meaning of the word "opposite", or you've been misquoted.
> 
> there might be a more up to date document than PS/172 for the description
> of real/1 but i couldn't find it.

I too expect the word "real" written in technical English to refer to the
real numbers |R, which is why I have strongly suggested to the BSI
committee that the predicate in question should be called float/1.
[I'd like to point out that I was advocating this in 1984, before I
ever saw anything about Quintus Prolog.]

What PS/172 may be referring to is my comment on PS/140, in which the
following text appeared (arguing _against_ the name 'real' for the
floating-point type):
    "real" contrasts with "imaginary" and "complex", and it
    appears that the standard will not contain complex numbers.

"Contrasts with" is not identical in meaning to "is the opposite of".
To show a contrast between A and B, one has to show a "striking difference".
Real numbers have no imaginary part; this is not true of complex numbers in
general, and to my mind that is a "striking difference".
The idea I had at the back of my mind was that Fortran, which has both a
COMPLEX and a REAL type, has some sort of excuse.  "Why is this variable
declared REAL?  Oh, because it has no imaginary part."  If BSI Prolog had
a complex type, so that
	complex(3.3_i_1.1)
	complex(3.3)
and	real(3.3)
but not	real(3.3_i_1.1)
in which case real/1 would _mean_ this:
	real(X) :- complex(X), X =:= re(X).
then 'real' would convey to the programming the idea "no imaginary part"
(which would be true) rather than the idea "arbitrary member of the real
number line" (which would be incorrect), and there would be some excuse
for using 'real' rather than 'float'.  In the absence of a 'complex' type,
this contrast is not present in the programmer's mind (only the contrast
between real and integer), and there is no such excuse.

I believe that the most up-to-date and specific definition of the real/1
predicate in BSI Prolog is to be found in the Formal Specification, which
appears in the latest issue of the Logic Programming Newsletter.  (Spacing
is, as usual, theirs, not mine.)

Page 22, section 7, second column, "REAL predicate".

	execbip ( _, func ( real, X.nil ), empsubs)
	<= is--real ( X ).
{ I believe that this is a misprint for
	<= is-a-real ( X ). }

	in-error ( func ( real, X.nil ), Undef-message )
	<= L-var ( X ).

Page 13, section 1.28, first column, "real definition".

	is-a-real ( func ( N, nil ) )
	<= |R-real ( N ).

Page 22, section 7, first column

	We suppose that we have a denumerable infinity of clauses:
	...
	|R-real ( X ).		for all reals X.

What this is intended to mean is anyone's guess:  the set of floating-point
numbers is finite for any machine, not infinite, but the set of reals is
not denumerable.  I pointed out in an earlier message that the Formal
Specification provides no means of constructing irrational numbers, so
perhaps 'real' is to be read as 'rational'.