Re: Surprise in array concatenation

On Thu, 08 Sep 2005 20:18:26 +0200, Georg Bauhaus wrote:

> 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
^^^^^^^^^^^^^^^^^!

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

Try to define "hole" in terms of ADT, maybe then you'll understand the
problem better.

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

The index ranges need to be convex if you want to have your "length / 2".
The above is the definition of a convex set.

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

Ada was designed as a higher level programming. If you want an assembly
language, there are plenty of them...

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

Care to show a difference?

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

It is always a good reading. Though any introductory book on modern algebra
could also help.

> If there are 4 trees in a garden, there is really 1 tree in the
> garden, because of modulo 3.

You still missing the point, and still mixing apples and oranges.

It is not 1 tree, it is a class of equivalence: { 1 tree, 4 trees, 7 trees,
....}. 4 trees (a set!) is in this class (a set of sets!) which you have
denoted as 1 (a number!)

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

Those are philosophical questions. As a follower of Plato, you should
address them to his philosophy. In the philosophy I adhere they are just
meaningless.

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

And what's the point? This or that way, but Universal_Integer is a type
different from one of array index.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages