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: Sat, 14 Aug 2004 23:13:57 +0100
User-agent: semail 20040101

Hans Aberg wrote:

> At 19:51 +0100 2004/08/14, Frank Heckenbach wrote:
> >You started the rant about terminology, didn't you?
> 
> You was the guy who started the rant, jumping and inflating a small rematk
> I had in a discussion with Laurence Finston. You wanted to start a language
> war, remember? :-)

No, I asked you whether you wanted to as it appears from your
comments. 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.

> >about using "real" for a type to represent some real values and
> >claim that using "float" for a type to represent some real values in
> >a floating point representation was "mathematically correct".
> 
> 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?

> > While
> >at the same time using "int" for a type to represent some integer
> >values or integral values (which means the same AFAIK).
> 
> 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!

> >Are you trolling now? I suppose you know that mathematical
> >statements about real numbers (and most anything) are not made by
> >performing computations on examples (whether by hand or by
> >computers), but by using quantors.
> 
> (Is "quantor" what is usually called quantifier?)

Yes (I confused the German and English terms -- no need to start
another thread here ;-).

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

> >> (If one wants to implement properly implement the
> >> set of real numbers in a computer, one does that exactly the same way as in
> >> pure math, via a finite, but potentially infinite via substitutions,
> >> axiomatic system.)
> >
> >Yes. If that's your point, then all of "real", "float", "int" etc.
> >as used in most programming languages are incorrect,
> >and should be
> >reserved for the sets of all real, floating point or integer
> >numbers.
> 
> The use of float and int in say 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).

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

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

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]