Re: Surprise in array concatenation

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitry A. Kazakov wrote:

>>Almost no real number can be represented in a computer.
 
> OK, it is beaten to death.

The fact is quite alive.


> How else you could check if 1 really refers to the physical 1!

Which physical 1? There is a written agreement on what represents
1 inside a computer, per computer. As I said, math declares the swamp
away into which it is built. Computer descriptions do soemthing similar.
I do not usually try to write programs using funny interpretations of
bits, and assume you don't either.


>>When are you interested in computing the value half-way between
>>the ends of a (non-numeric) enumeration type, attempting to use
>>A'Length / 2?
> 
> 
> Iteration algorithms in numeric analysis.

Sounds more like adding rectangles or points, when X runs along
the axis of discrete non-numeric enumeration values.
A plausible algorithm could be binary search when the indexed values
grow or shrink as the non-numeric index values grow in position.


>>Can there be an index type in Ada that isn't ordered?
> 
> 
> Sure:
> 
>    type Unordered_Index is (A, B, C, D);
>    function "<" (Left, Right : Unordered_Index)
>       return Boolean is abstract;

I was thinking of index types that are not ordered in Ada. See
below.

> 1. This is plain wrong. If L=U then (L+U)/2=L.

As you say, "+" isn't predefined for enumeration types.

As for M and (L+U)/2 I should have said, in Ada (and other PLs)
if 0 <= A'Length <= 1, then (L+U)/2 can be 0 = M, and A'Length/2 = 0, always.


> (For generalizations on unordered cases see "convex hull")
I'm trying to see arrays, and possible improvements. If a convex hull
offers something useful in arranging memory cells and copying
some of them to a CPU or I/O register, fine. (As this is what happens
in the end.)


> 2. M could not be computed just because "+", "/", 2 aren't defined. Then of
> course there could be no order;

But in fact, Ada's enumeration types are ordered. Try to make this
pass Ada compilation,

type Unordered_Index is (A, B, C, D);
for Unordered_Index use (A => 1, B => 3, C => 2, D => 4);

What does the compiler say?


> 3. Note that (1) is wrong for modular types.

And?

> Not surprisingly, they aren't
> numbers,

That's news. There are numbers congruent modulo some number.
But you think these numbers aren't numbers?

> but classes of equivalence (sets of numbers, infinite sets, BTW,
> yet representable in the computer, how strange (:-)).

One equivalence class is not the same as the set of numbers mapped
to members of the equivalence class. "type X is mod 10;" implies a
finite set of values. Try "a: X; a := 42;" In other words, 42 cannot
belong to the set of values expressed by X. Belonging and congruence
are not the same thing. For example, we cannot count an absolute
number of items when there are at least as many items as the modulus.

Here is a representation of DK's representation of the set of real
numbers inside a computer:

  2#1010010#

It remains to be shown how computations with real numbers are useful.


> here (modular types) Ada is again not very inconsistent.

I'm glad to hear this.