Re: 3DLDF

[Hans Aberg]

At 01:52 +0100 2004/08/16, Frank Heckenbach wrote:
>> 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.
>
>Seems useful in many cases, problematic in others (does it add the
>factor's precisions in a multiplication?), impossible in some (sqrt,
>even most divisions).

I do not myself believe in this idea. I think that the correct way to treat
this problem is to add an explicit relative error component to the floating
point number. (The relative error of f(x_1, ..., x_k) can be found using
the usual analysis of dlog f = df/f.) The fixed number type (not supported
by GMP) would have an absolute error components.

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

In the beginning of the eighties, people using the popular Borland Pascal
compiler (which you are cloning?) remarked its multiprecision very useful.

>> 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.
>
>I think you need to allow for several b_i*... terms to get it closed
>under addition.

Right.

>> 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.
>
>Same for Pascal, except that it also admits different kinds of real
>type approximations.

I saw it.

>> >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 :-),
>
>So much about starting language wars. Of course, the same can be
>(and has been) said about C, Unix and probably anything that isn't
>to the speaker's taste.

There are still new standard revisions of C, latest is C99. Is Pascal still
being developed? As for UNIX variations, one is now unifying them, and more
and more computers use then as OS, one of the latest additions is MacOS X.
And C is the language developed for implementing UNIX. So C and UNIX will
be around for write some time as major components of programming and
computers. Pascal was used to implement the original MacOS, but they too
switched to C, when Pascal started to fall out of vogue.

C is a strange blend of new and old features and has some serious problems
built into it, for example its many implicit type conversion, and some
syntactical features. This in part bogs down C++, trying to keep a C
legacy. So eventually, one will have to find a replacement for them both,
but there is not a major contender as of yet, even though there are people
paying around with such ideas (see for example the language "D").

>> >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.
>
>LOL. I know a lot of programmers, but few of them talk in the
>language of the standards. A more useful answer would be: Use Google
>to see what people really use. (I just searched for "int integer c",
>and it seems few of the pages found make that distinction between
>"integer" vs. `int'/"integral" you're so obsessed with, quite the
>contrary.)

It is important to distinguish between formal and informal use: People may
informally speak about integers, but formally they are named "integral
types". Otherwise, I usually hang out in groups like
comp.lang.c(++).moderated and comp.std.c(++), and that is what I am used
to, places where people tend to be more exact because it is needed. My
guess is that you would do the same in math, relying typical expert
mathematicians usage, and not really what all undergrads are doing.

I also have had discussions with people developing the numerical features
of Haskell, and those more exact distinctions are really needed in modern
language development.

>> 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.)
>
>Most texts about numerical algorithms that I know do their
>computations with real numbers indeed and talk about rounding
>errors. (Of course, computing the rounding errors requires knowledge
>about the (floating-point or other) implementation. But it requires
>more detailed information than just that it's floating-point, which
>is all that C guarantees.)

This is why it is important to distiguish the flotang point type from other
numerical types, such as the real numbers.

>> >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.
>
>Also to C, another archaic language, with its incorrect type names
>such as `double', possibly `int' (you're still trying to argue it's
>not), not to mention `char'.

C has an archaic origin, but is still actively developed. The latest
revision is C99.

  Hans Aberg