Re: Surprise in array concatenation

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitry A. Kazakov wrote:

> Note that A=1 from the problem state is not a bit pattern. It is a set of
> computational states for which A is considered be 1. So when you make a
> memory dump and discover a bit pattern 000000001 at the address FF07712CA0
> that tells absolutely nothing.

A dump might tell me a lot provided I know what kind of dump it is and when
it happened. Depending on the algorithm, for example, if FF07712CA0
addresses a cell that is 000000000 at the start of the program, and
the program sets it to 000000001 just once during the program's run,
then, assuming regular operation, I know what happened.


> I don't care about representations as long as they aren't the part of the
> problem space (like in communication protocols.)

Finiteness of computers happens to be one of the problems we
are discussing.


>>>   type Unordered_Index is (A, B, C, D);
>>>   function "<" (Left, Right : Unordered_Index)
>>>      return Boolean is abstract;
> 
> 
> if A < B then -- Compile error! What else you need?


"Ordered" as per Ada's requirements for enumerations.
For arrays (Ada arrays), I'd rather not have to think about *user*
*defined* order of the index type when it comes to element change.


> If some day Ada will
> have abstract arrays, then "for I in A loop" should iterate it in the order
> of the Index, and not in the arbitrary one of Index'Pos.

Please, could you stop naming this ADT an array? It has so many
more assumptions that it deserves a distinguishing name!

For example, you could have holes in your index type, IIUC.


>>>(For generalizations on unordered cases see "convex hull")
>>
>>I'm trying to see arrays, and possible improvements. If a convex hull
>>offers something useful
> 
> 
> Believe me, convex sets (whether (1-t)a + tb belongs to the same set forall
> 0<=t<=1) are extremely important for countless numeric methods,
> computational geometry etc.

I'm curious. How does this relate to array indexing?


>>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);
> 
> 
> This has little to do with the order of Unordered_Index.

It has a lot to do with Ada's notion of the order of enumeration literals
(increasing).

> The representation
> clause defines representation. You should never mix:
> 
> 1. The user-defined order and other operations (like +, -) and literals
> from the problem space;
> 2. The positions of discrete values;
> 3. The representations of discrete values.
> 
> These all are different things. I hope it is clear that algorithms should
> be written in terms of (1)?

I can't imagine non-DK-array algorithms are usually written in terms
of (1) (*user-defined* sorting order of the index types).
These are Ada arrays, rock solid low level stuff, based on preexisting
contracts inherent in enumeration order or Positive's order, etc..

Why should I impose *any* order on (Red, Green) when this type lists
the colors of apples in my garden? I can very well construct my arrays
using the predifined order.
 Incidentally, Haskell permits user defined sorting order (<) for types that
are instances of type class Enum. Yet at the same time, you can request a
default order by stating "derives Enum".

Why should I redefine the order of Positive when using Ada.Strings.Fixed?


>>>3. Note that (1) is wrong for modular types.
>>
>>And?
> 
> 
> and you could not write a generic array algorithm both relying on (1) and
> usable for modular types.


My definition of "generic array algorithm" has limitations.
Some are imposed by Ada. I'm awaiting your abstract array data type,
same efficiency as Ada arrays, capable of making empty array
objects using a one-enumeral index type, permitting compile time
data layouts, safe indexing after index computations, perhaps
dynamically changing their length, ...


> You again mixing sets and elements of. 42 is a literal. In the case of
> equivalence classes it denotes not a number (Z) but a class of.

I'm not mixing sets and elements, I'm pointing out that symbol manipulation
and counting are sometimes different. I'm trying to point out the *you*
are talking evasively about special cases. Cases when there is a finite
subset of mathematical items that can be represented inside a computer,
element-wise or not. And this works in the special cases just because
the problem to solve is really about finite sets, inside a computer.
Whatever the finite sets represent in our interpretations, they are
finite.

If we need all umpteenth decimal digits in the expansion of Pi,
we might or might not get them, depending on what umpteenth is,
because any storage is finite.


> There is no
> class X'(42) for mod 10. Yet 42, now as an element of Z, is one of X'(2)
> because 42=2(mod 10).

Not "is", but "is represented" in an algorithm which is about equivalence
classes, not about counting.
 "Package number 245345=5(mod 10) is malformed. So please look at
package number 5." Huh?

>>Belonging and congruence are not the same thing.
> 
> 
> They are exactly same. It is how the set is defined.

It's time for me to study Lewis Carrol's stories, to that I can
legitimately refer to Humpty Dumpty. 

If there are 4 trees in a garden, there is really 1 tree in the
garden, because of modulo 3. BTW, was that modulo number the class
representative 3 or the number three or the symbol 3? Oh well...
Meanwhile the apples and plums below the 3 other trees start to rot.
Time for a depressing garbage collection... 


> The type of the
> cardinal numbers in Ada is defined as Universal_Integer.
> It is not the type of the elements in a set!

Universal_Integer is subject to capacity constraints, e.g. storage.
Therefore there exists a corresponding set, for each compiler + computer,
outside the domain of pure math-think and inside the domain of computer-
math-think.


> (Taking too much C++ might be dangerous for your health! (:-))

What has C++ got to do with this? (Except that C++ programmers might
be more aware of the limitations of the computer, because they have
to take care of limits themselves? Because template recursion is
usually limited to a certain depth, but OTOH template recursion
becomes highly visible in error messages?)