Re: 3DLDF

[Frank Heckenbach]

Hans Aberg wrote:

> So in C, the floating point types are evidently finite in their potential
> values. This need not be so, of course, in multiprecision packages.
> (Perhaps this can be achieved in GNU GMP.)

GMP implements floating point numbers with statically unbounded (but
finite) number of binary digits (mpf), and rational numbers as
quotients of two integers (mpq), but it cannot represent irrational
numbers.

> >Similarly, for any given real number, there can potentially be a
> >Pascal implementation that supports this number. (Even if
> >transcendent, it could just define this particular number as a
> >special symbol.) So, according to this definition, all real values
> >are potentially reachable. (With a big emphasis on potentially, of
> >course.)
>
> So go ahead and make a single Pascal compiler that potentially admits all
> real numbers.

Not a single compiler -- just as little as any single C compiler
supports all floating point numbers (i.e., all real numbers with a
finite number of digits in any given base).

> I feel sure that the original designer never had this idea in
> his head.

I suppose the intention was simply to not specify the implementation
as indicated by a note in the standard: "The nature of the internal
representation of values of real­type is not specified, and hence
could be fixed­point, floating­point, or something quite different."
Floating-point is by far the most common today, but it could be
something else (in the future, or today seen from the time when it
was designed, or perhaps for some special situations a different
implementation is more suitable). So I still think it makes sense to
call a "type of some real numbers" `real', just as most people
except you think of `int' as a "type of some integers".

> >Just as little as C `int' values satisfy basic arithmetic
> >properties, so it's hard to think of them as integral numbers?
> 
> The integral types of C contains "integral numbers", but as type does not
> represent the set of integers in math. If you want to have a set of
> integral numbers in math which are not the set of integers, just take the
> integral numbers in an algebraic number field.

But C's `int' is neither of it (consider `/', comparisons, etc.),
and no programmer would reasonably assume so.

> >IMHO it's possible to think of them as such in both cases, as long
> >as you're aware of the restrictions, which applies to many other
> >areas of programming.
> 
> You may think of them as whatever you like, but that is not what they are
> logically. You may think of the set of real numbers as a continuous line,
> but nobody has produced a real line in reality.

Wasn't it you who mentioned pragmatic computer languages? For many
real-world problems defined in terms of integers or reals, it's more
convenient to implement them using C-style "integral numbers" and
floating-point numbers and to be aware of the restrictions, than to
think of those numbers as bit-patterns or whatever that have some,
but few mathematical properties.

> I, as well as a number of other people, are working on implementing this
> stuff in a computer. Not many years form now there will commonly programs
> that combines what is now different programing language styles. There is
> also a crisscross of ideas, for example, ML, predecessor to Haskell, was
> created as a metalanguage to the theorem prover Isabelle. These type
> theories then sprung out from attempts to solve problems in metamathematics
> of higher order theories. As these developments are taking place, it is
> important to straighten out the earlier, sometimes sloppy, terminology.

This may be important in those new languages, but I don't think
you'll change all existing computer languages or their terminology.
I also don't think these new languages will supersede all existing
languages, same as all the other "new paradigms" failed to. So go
ahead with your project and try to build a mathematically correct
language and its terminology if you like, but don't believe that C
is so.

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)