help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3DLDF


From: Frank Heckenbach
Subject: Re: 3DLDF
Date: Mon, 16 Aug 2004 01:52:03 +0100
User-agent: semail 20040101

Hans Aberg wrote:

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

I know. That's why I said it's statically unbounded (dynamically
it's only bounded by available (addressable) memory, AFAIK).

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

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

I do, thank you.

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

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

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

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

I don't quite parse this sentence. Anyway, you are aware that Pascal
has evolved quite a bit since Wirth's original language? (Otherwise,
some of your statements might be understandable, though as being
based on ignorance.)

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

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

Which do not apply to C's `int' type, so how are they relevant?

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

Frank

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]