Re: 3DLDF

[Hans Aberg]

At 23:13 +0100 2004/08/14, Frank Heckenbach wrote:
> Obviously you think that C (or the C standard) is God and
>anything it claims must be true. Well, talk as you like, but don't
>claim mathematics for your support. C may be a good assembler-like
>language, but it's not really famous for its mathematical concepts.

I was merely happily surprised that the C/C++ folks seems to have thought
this through more carefully than say the guys who made FORTRAN and Pascal.

>> The thing is there will be clash in names when one introduces real
>> representation of real numbers into computers. So it is better to stick to
>> the terminology, simply.
>
>And there will be a clash when introducing a less limited floating
>point type. Or in fact it has been there already. Or are you going
>to claim that "double" is the "mathematically correct" term for a
>floating-point number represented in twice as many bits as the ones
>used before?

My guess is that "double" is originally short for "double float(ing point
number)". It is just a typical way in natural languages that words out of
one of the features of the objects one attempts to describe. Therefore it
may not appear as logical at superficial inspection.

>> Same here. I already pointed out that Haskell has both the types Integer
>> and Int.
>
>Well, you use "float" as standing for "floating point number" (as
>you pointed out in another mail), and now you make a big distinction
>between "int" and "integer". Very logical!

You must carefully distinguish between the informal use of words and the
technical ones. People might in principle informally abbreviate "integer"
to "int" (as opposed to the technical use in C of "int" as a type name),
but I do not know of any such usage. Perhaps if you check out with an
expert on the English language, you might find out why.

>> I think I pointed out that the set of real numbers is in math, as well in
>> computers, when done correctly, developed using an axiomatic system.
>
>And so are integers. What does this have to do with the terminology?

I have lost you here. Otherwise, the set of integers are mathematically
different from the set of real numbers in that there is a standard model
which is preferred over the axiomatic formulation for example when
implementing in a computer. This standard integer model then, for its
representation, does not need a theorem prover present, but has
straightforward computer implementations. So it is easy to implement a type
integer, but difficult to implement a type real.

>> The use of float and int in say C is is more or less correct, as one
>> speficies which values can be used, and all those values are potentially
>> reachable.
>
>Not in C (where those terms are used).

Sure, check the header <limits.h>.

>> This is not the case of real as thought as representation of
>> mathematical real nimbers, as many real numbers are not potentially not
>> reachable (as say pi or e).
>
>Not in a floating-point representation, but with other
>representations. So using "real" for a type of (some) real numbers
>that does not specify the internal representations still seems
>reasonable.

One would expect that if expressible real numbers to be contained in the
real type, not just a subset of some rational numbers with nonstandard
arithmetic operations, if you know want to regard floats as real numbers.
It is hard to think of the floats of some kind as reals, as they are not
even associative under + and *.

>> >Then usual computer languages could only...
>>
>> Usual computer languages such as Haskell <http://haskell.org/> has
>> potentially infinite types, for example Integer. In fact the Haskell lists
>> are also (potentially) infinite, so it is for example possible to define a
>> list of all the Fibonacci numbers.
>
>Yes, but still it can only represent a tiny fraction of all real
>numbers, or of all lists of integer numbers etc.

You can only do that in pure math as well, as you are limited by expressing
them via a metamathematical system, which is only potentially countable
infinite. This is essentially a special case of the Skolem "paradox".

  Hans Aberg