Re: 3DLDF

[Hans Aberg]

At 16:53 +0100 2004/08/15, Frank Heckenbach wrote:
>GMP implements floating point numbers with statically unbounded (but
>finite) number of binary digits (mpf),

Actually the precision allocation is dynamic (check the definition of
mpf_t). The arithmetic operations, I think, though, will preserve precision
length. But someone wrote on top of GMP a C++ library that sort backwards
tries to figure out a dynamic precision.

>and rational numbers as
>quotients of two integers (mpq),

These are (potentially) infinite types though. It was the need for them
when writing on an implementing Buchberger's GBA (Groebner Basis Algorithm)
that caused me to pick it down: There, polynomials with small coefficients
can generate solutions with large coefficients, so this seems necessary.

If you do not have GMP available in your Pascal compiler, perhaps you should.

>but it cannot represent irrational
>numbers.

It is difficult to implement even algebraic numbers. One representation
seems to be as a pair, a polynomial with rational coefficients, and a
floating point number (or pair, when working in the complex plane)
sufficient close to the number to isolate it as a zero of the polynomial.
If you want to merely add say the set of (real) square roots, one might use
all numbers of the form
    a + b * sqrt(p_1*...*p_k)
where a, b are rational numbers and the p_i are different primes.

>> 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).

Different C compilers in effect implements different finite floating point
types. The C standard is deliberately written to admit this. Strictly
speaking, each C compiler implements a different language. The C standard,
in effect, tries to describe a collection of such languages. This was done
to admit efficient, local implementations, but the drawback is lack of
portability. For example, it is hard to make C code for a 32-bit machine to
run on a 16-bit machine.

>> 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,

This is in fact interesting, because I pointed out the fixed point type to
the GMP people. Somehow, this type has fallen out of vogue.

>floating‚point, or something quite different."
>Floating-point is by far the most common today, but it could be
>something else (in the future,

The language Pascal does not have much of a future :-), even though it
still might be important making compilers and have a legacy interest in the
language.

>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',

Well, we disagree. And for example IEEE 64-bit floats have numbers with no
analogue in the set of real numbers of math (like NaN and +0, -0). I think
that (later) C/C++ have support for such numbers, as well.

Does it make it impossible for you to write on a Pascal compiler, just
because here and there, Niklaus Wirth made some poor choices?

>just as most people

I gather "most" refer to yourself. :-)

>except you think of `int' as a "type of some integers".

Read the C/C++ standards to see what people use. They are known as
"integral types", not "integer types".

>> 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.

I do not claim anything such; I just give examples of English usage.

>> 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...

In working with floats, it is important to realize that these are not real
numbers, but at best approximations. So the usual way in applied math and
computer programming is to carefully not program floats as though they were
real numbers, but as though they were floats. (Newbies often complain about
roundoff problems, attempting to program as though floats were reals.) It
is sorry that languages like Pascal and FORTAN confuse those matters.

>... 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 have lost you here: One thinks of them as bit-patterns when that is
convenient, and as something more structured when that is convenient. This
is the usual paradoxical dichotomy (Turing equivalence, etc.).

>> 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 gather "all existing computer languages" refer to Pascal, an archaic
language. Languages of the past are of course as they are, as no-one can
change the past.

>I also don't think these new languages will supersede all existing
>languages, same as all the other "new paradigms" failed to.

Languages of the past are often useful simply because they do not change,
and therefore there is not the question of having to update the code
written for them, as well as a source of inspiration for new languages. But
it would be a poor practise to repeat old mistaken when developing new
languages.

>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.

I really do not get this: What is mathematically incorrect with C? It does
not pretend to implement real numbers, but some machine specified variation
of floats. That seems to be a mathematically correct way to go.

  Hans Aberg