I just combined my number view into a file. Some issues might be interested:
1. Infinity
2. Real axis
3. 'cardinality' of ℝ is greater than ℵ1,ℵ2,ℵ3,...
4. Infinite series
5. 1=√1=√(-1)*(-1)=i*i=-1.

Possible issues about 0.999...=1 (or lim(x->∞) 1/x=0) had been debated for
years (both are wrong).
https://sourceforge.net/projects/cscall/files/MisFiles/Infinity-zh.txt/download
------
+--------------+
| Nomenclature |
+--------------+
Entity::The real object under measurement. We understand and describe the real object
via measurement. What we feel and inside our brain are the results of
measurement, not the real object itself.

Symbol '='::x=y means the occurrence of x can be replaced by y, vice versa.
Note that this is a formal definition. Actual usage is normally accompanied by
an 'equivalence relation=='. If "x=y" is a proposition, then a=b iff a==b.
This definition emphasizes the operational meaning (needed in programming).

Trichotomy Property::Same as well-ordered property. For any two elements a,b, exactly one of the
relation holds: a<b, a==b, or a>b (elements can be sorted). Explanation for
other symbols (<=,>=) are omitted.

Real Axis::A widthless graduated scale for measuring the length or position of an entity.
The division marks on the scale may be referred to as points or
'real numbers'. The marks are the cracks separating the 'continuous space'.
The mark itself has no measure of length, so the point or the number.

Point::The same as in Euclidean geometry. A mark of position, same as the marks on a
graduated scale.

Number::A symbol(operand or expression) that identifies point.

Number '∞'(infinity)::1. ∀n∈ℕ, n<∞
2. The multiplicative inverse of ∞ is 1/∞, the additive inverse is -∞

Distance::The absolute differences between two numbers. For two numbers a,b on the real
axis, d=dist(a,b)=|a-b|. (sometimes, length is used for distance)

Interval::The set of numbers on the real axis between two numbers. E.g. [a,b]≡
{x| x is a number on the real axis, a<=x<=b}. Definition of other kind of
intervals [),(],() are the same as in average mathematics. Note that a single
point x can construct a single-point interval [x,x], dist(x,x)=len(x,x)|x-x|=0.

Density Property::For any two different numbers, there exists another different number in
between. Take interval [a,b] for instance: ∀i,j∈[a,b], i<j such that ∃k,
i<k<j.

Extended ℕ::ℕ∪{∞}, noted as Eℕ

Extended ℤ::ℤ∪{∞}, noted as Eℤ

Extended ℚ::Set {p/q; p,q∈Eℤ, q≠0}, noted as Eℚ

Corollary: The maximal(of minimal) number in an open interval can not be
precisely explicitly shown. (prohibited by density property)

+--------------------------------------------------------------+
| Prop5: Non-zero length interval can not be stuffed by points |
+--------------------------------------------------------------+
Let interval A=[a,b], a<b. Because any point p∈A is 1-1 correspondent to
interval [p,p], p∈[p,p], dist([p,p])=|p-p|=0:
But the maximal possible length of all q numbers of sub-intervals containing
a single point in A is q*0=0.
QED.

Corollary: The 'cardinality' of ℝ is greater than ℵ1,ℵ2,ℵ3,...

+------+
| Line |
+------+
Line::Line is a set of well-ordered points(if in term of points). Conversely, any
well-ordered set could be called a line.

Straight Line::Two different points A,B define a straight line L(A,B)≡ {x| x satisfies
exactly one of the following equations 1:dist(A,x)= dist(A,B)+dist(B,x)
2:dist(x,B)=dist(x,A)+dist(A,B) 3:dist(A,B)=dist(A,x)+dist(x,B)}
I.e. x that satisfies equ-1 is an extended line point from B.
x that satisfies equ-2 is an extended line point from A.
x that satisfies equ-3 is in line [A,B].

Corollary: Real axis is a straight line.
Corollary: The shortest distance between two points is a straight line (this
sentence reads funny).
Corollary: The sum of the length of any two sides of a triangle is greater than
that of the third side.

+-----------------+
| Infinite Series |
+-----------------+
Rule1: Infinite series A,B are equal iff the summand and the index are equal
Rule2: The expanded form of infinite series must list the last addend.
Otherwise, the expanded form is ill-formed (obsecure semantics).

Ex.1 (the last addend is omitted):
A=1+2+3+4+5+...
=(1+2)+(3+4)+5+...
=3+7+5+... // ill-formed, obsecure semantics.

Last addend listed:
A=1+2+3+4+5+...+∞ // well-formed, the exanded form of Σ(n=1,∞) {n}

Ex.2:
S=1+2+4+8+... // ill-formed
<=> S=1+2(1+2+4+8+...)
<=> S=1+2S
<=> S=-1

Last addend listed:
S=1+2+4+8+...+2^∞
<=> S=1+2(1+2+4+...+2^(∞-1))
<=> S=1+2S-2^(∞+1)
<=> S=2^(∞+1)-1 // Lots of similar "magic calculation" deriving the result
// S=-1 can be found in youtube. (the term containing the
// last addend ∞ is ignored)

Ex.3:
"f(n)= Σ(k=0,n) 1/k! => f(∞)=e(The base of natural logarithm)"?
We know for sure ∀n∈ℕ, f(n)∈ℚ. To get the result f(n)=e (f(n)∉ℚ), the only
current option is n=∞. But the issue whether or not f(∞)=e (exact equal by
definition) can only be decided via definition, e.g. e≡f(∞).. Otherwise, we
can only say f(∞)≈e. (In considering the definition of the equal sign '=',
other forms of e are likely not mutually replaceable with f(∞))

Ex.4: x= Σ(n=1,∞) 1/n²
A common expression is x= Σ(n=1,∞) 1/n²= π²/6, therefore, π=√(6*x)
The issue here is: Lots of π can be derived from various infinite serieses.
But, according to the definition of '=', the result of mutual substitution
may become inconsistent.
For now, the uncontroversial definition of π is the ratio of the
circumference of a circle to its diameter, it is safer to use '≈'.
Therefore, Σ(n=1,∞) 1/n² ≈ π²/6

+--------------------------------------+
| Equality of multi-value of n-th root |
+--------------------------------------+
From the fundamental theorem of algebra, square root has two solutions, e.g..
√2=±1.414... Therefore, "√2=1.414..." is not really correct and can cause
contradictory results like n=-n. This is a common case, e.g. If √1=1 is
correct, then 1=√1=√(-1)*(-1)=i*i=-1...

∴ The symbol '√' (or nth root of a number) should mean operation, can not be
substituted with any ascertained number.

+-------------------------------------------------------------------------+
| Prop6: Periodic exponential function is equivalent to constant function |
+-------------------------------------------------------------------------+
Let f:T->T be a computational(decisive) function. x,a,t∈ T. function f
satisfies two properties:
P1: f(x)=f(x+n*t) ... f is periodic of t, ∀n∈ ℕ
P2: f(x)^a=f(a*x) ... f has such an exponential arithmetic property

Lemma1: For any a∈ T, f(x)=f(x+a*t)
Proof: f(x)=f(x+a*t)
=> f(x)^(1/a)=f(x+a*t)^(1/a)
<=> f(x/a)= f(x/a+t) ... from P2
<=> f(x/a)= f(x/a) ... from P1
<=> true

Lemma2: For any a,b∈ T, f(a)=f(b)
Proof: f(a)=f(b)
<=> f(a)=f(a+(b-a))
<=> f(a)=f(a+((b-a)/t)*t)
<=> f(a)=f(a) ... From Lemma1
<=> true

∴ If Lemma2 is converted to text: Function that satisfies P1,P2 are equivalent
to a constant function.

+---------------------+
| De Moivre's formula |
+---------------------+
x,θ∈ ℝ, k∈ ℤ, (cos(θ)+i*sin(θ))^x= cos(x*(θ+2kπ))+i*sin(x*(θ+2kπ))
If simplified using "cis": cis(θ)^x= cis(x*(θ+2kπ))

Note: This section contains unsolved issues, but not important for now.

To prevent issues raised by Prop6 (including issues in the identity
x^(a*b)=(x^(1/b))^a=(x^a)^(1/b)):
1. De Moivre's formula only applicable to complex number (Exponential
operation of real number x must first convert x to a complex number of
cis form. But converting complex of cis(x) form to a+b*i form may suffer
downcast problem)
2. cis(θ)≠cis(θ+2kπ)

wij <wyniijj@gmail.com> writes:
> I just combined my number view into a file. Some issues might be interested:
> 1. Infinity
> 2. Real axis
> 3. 'cardinality' of ℝ is greater than ℵ1,ℵ2,ℵ3,...
> 4. Infinite series
> 5. 1=√1=√(-1)*(-1)=i*i=-1.
>
> Possible issues about 0.999...=1 (or lim(x->∞) 1/x=0) had been debated for
> years (both are wrong).
> https://sourceforge.net/projects/cscall/files/MisFiles/Infinity-zh.txt/download

That document is in Chinese, so it won't be useful to most people.

Why did you post this to comp.lang.c? It has nothing to do with the C
programming language.

[snip]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Wednesday, 28 July 2021 at 01:52:15 UTC+8, Keith Thompson wrote:
> wij <wyn...@gmail.com> writes:
> > I just combined my number view into a file. Some issues might be interested:
> > 1. Infinity
> > 2. Real axis
> > 3. 'cardinality' of ℝ is greater than ℵ1,ℵ2,ℵ3,...
> > 4. Infinite series
> > 5. 1=√1=√(-1)*(-1)=i*i=-1.
> >
> > Possible issues about 0.999...=1 (or lim(x->∞) 1/x=0) had been debated for
> > years (both are wrong).
> > https://sourceforge.net/projects/cscall/files/MisFiles/Infinity-zh.txt/download
> That document is in Chinese, so it won't be useful to most people.

The correct link: (my negligence)
https://sourceforge.net/projects/cscall/files/MisFiles/Infinity-en.txt/download

> Why did you post this to comp.lang.c? It has nothing to do with the C
> programming language.
The preliminary doc. is for a program plan. The number view is made on
programmer's point of view. I thought sometimes somethings like this is not bad.
To C/C++, the immediate effect is the concept and design of INFINITY and real number
I hope someone can spot some inconsistent contents or phrasing errors.

> [snip]
>
> --
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
> Working, but not speaking, for Philips
> void Void(void) { Void(); } /* The recursive call of the void */

On Wednesday, 28 July 2021 at 15:24:34 UTC+8, minf...@arcor.de wrote:
> wij schrieb am Dienstag, 27. Juli 2021 um 17:40:59 UTC+2:
> > I just combined my number view into a file. Some issues might be interested:
> > 1. Infinity
> > 2. Real axis
> > 3. 'cardinality' of ℝ is greater than ℵ1,ℵ2,ℵ3,...
> > 4. Infinite series
> > 5. 1=√1=√(-1)*(-1)=i*i=-1.
> <snip>
>
> Never confuse math with numerics. Prof. Kahan made that very clear.
>
> http://people.eecs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf
> https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

The view of real number is different from common math. which clib follows:
floating-point number is 'hoped' to represent real number.
I just think now the symbol INFINITY should be reserved, not for signaling overflow.
There is also a thread of the same topic in comp.theory
https://groups.google.com/g/comp.theory/c/Lr94sLfqFjg

On Thursday, 29 July 2021 at 11:00:54 UTC+1, wij wrote:
>
> The view of real number is different from common math. which clib follows:
> floating-point number is 'hoped' to represent real number.
>
Floating point number are a sufficient approximation to real numbers for most
purposes. The exception is when doing certain types of mathematics itself.
>
> I just think now the symbol INFINITY should be reserved, not for signaling overflow.
>
There's no distinction made between "overflow" and "mathematical infinity". You can
of course say that INFINITY represents mathematical infinity in the particular
program you are writing, but this is fraught with dangers. Really you're best using
a package like Mathematica if you want to do maths rather than bit bashing.

On Thursday, 29 July 2021 at 18:11:37 UTC+8, Malcolm McLean wrote:
> On Thursday, 29 July 2021 at 11:00:54 UTC+1, wij wrote:
> >
> > The view of real number is different from common math. which clib follows:
> > floating-point number is 'hoped' to represent real number.
> >
> Floating point number are a sufficient approximation to real numbers for most
> purposes. The exception is when doing certain types of mathematics itself.

Precisely, FP is an encoding of number in (binary) scientific notation.
Floating-point number almost represents an approximate number.
The error accumulates.

> >
> > I just think now the symbol INFINITY should be reserved, not for signaling overflow.
> >
> There's no distinction made between "overflow" and "mathematical infinity". You can
> of course say that INFINITY represents mathematical infinity in the particular
> program you are writing, but this is fraught with dangers. Really you're best using
> a package like Mathematica if you want to do maths rather than bit bashing.

I understand the changes would not happen in decades.
Like the global warming issue, someone has to emit the message.
I am not particularly worried about this.

wij <wyniijj@gmail.com> writes:

> On Thursday, 29 July 2021 at 18:11:37 UTC+8, Malcolm McLean wrote:
>> On Thursday, 29 July 2021 at 11:00:54 UTC+1, wij wrote:
>> >
>> > The view of real number is different from common math. which clib follows:
>> > floating-point number is 'hoped' to represent real number.
>> >
>> Floating point number are a sufficient approximation to real numbers for most
>> purposes. The exception is when doing certain types of mathematics itself.
>
> Precisely, FP is an encoding of number in (binary) scientific notation.
> Floating-point number almost represents an approximate number.

It's more accurate to say that floating-point numbers are exact.

> The error accumulates.

Yes. The results of operations (and that includes input and the
conversion of source-code literals) may not be representable. Most
quality implementations will give very tight bounds on the acceptable
error for each operation. For example, most implementations will expend
considerable effort to convert a decimal literal to the nearest
representable floating point number.

--
Ben.

On 7/29/21 12:26 PM, Ben Bacarisse wrote:
> wij <wyniijj@gmail.com> writes:
....
>> Precisely, FP is an encoding of number in (binary) scientific notation.
>> Floating-point number almost represents an approximate number.
>
> It's more accurate to say that floating-point numbers are exact.
>
>> The error accumulates.
>
> Yes. The results of operations (and that includes input and the
> conversion of source-code literals) may not be representable. Most
> quality implementations will give very tight bounds on the acceptable
> error for each operation. For example, most implementations will expend
> considerable effort to convert a decimal literal to the nearest
> representable floating point number.

In more detail, here's what the C standard has to say about it:

"The accuracy of the floating-point operations (+, -, *, /) and of the
library functions in <math.h> and <complex.h> that return floating-point
results is implementation-defined, as is the accuracy of the conversion
between floating-point internal representations and string
representations performed by the library functions in <stdio.h>,
<stdlib.h>, and <wchar.h>. The implementation may state that the
accuracy is unknown." (5.2.4.2.2p6)

That means that an implementation could be fully conforming even if it
evaluates subtraction so inaccurately that

LDBL_MAX - LDBL_MIN < LDBL_MIN - LDBL_MAX

evaluates as "true", so long as it's documentation doesn't claim to
provide any higher degree of accuracy, which would essentially render
floating point math useless. The C standard recommends, and in some
contexts, requires that conversions be correctly rounded, which means:

"representation in the result format that is nearest in value, subject
to the current rounding mode, to what the result would be given
unlimited range and precision" (3.9)

which is pretty much the strongest possible requirement, but that is
nearly useless unless floating point arithmetic also has fairly strong
accuracy requirements.

However, when __STDC_IEC_559__ is pre-#defined by the implementation,
the much stronger requirements of IEC 60559 (== ANSI/IEEE 754) apply,
and in that case floating point math is very useful (though care is
still required when using it).

That's why Ben referred to "quality implementations" - such
implementations will provide accuracy much better than the minimum
allowed by the C standard.