[solved] macro for code ?

[Zoran]

I wonder how it’s implemented though. ..
Has anyone experimented with adding numbers to a set in a particular order and then using

Code: Pascal  [Select][+][-]

1.  for x in theSet do

Even if they come out in the same order they were put in it might be considered undefined behavior.

The particular order in which the elements were added to the set has surely no influence on the order which the "for in" loop chooses.

They will probably come out in ascending order -- as if you used:

Code: Pascal  [Select][+][-]

1. var
2.   x: TElementType;
3. for x := low(TElementType) to high(TElementType) do begin
4.   if x in theSet then begin
5.     // ...
6.   end;
7. end;
8.  

Because, that is the most probably how the "for in" is internally implemented.
But I would NOT rely on it.
And in my opinion, even if this order were guaranteed, it would still be better practice to use the classic for loop explicitly, because I really think that by using "for in", the programmer implicitly suggests that the order is not important.

If you need a particular order, which is neither ascending or descending (if you need the latter you can simply use "for x = High(TElementType) downto Low(TElementType)"), then you need some other approach.

One way would be to declare an array and add elements in the needed order. If the number of elements is known and constant, you can use a static array, otherwise dynamic in which case you have to take care that the needed size has been allocated before you add each element. Then some container class, such as TFPGList can make things easier, or some other class from fgl unit might be more appropriate for your needs.

[Thaddy]

No, that's plain wrong! A Pascal set is not ordered.

A Pascal set is ordered. In all pascal dialects. A pascal set is ordered, and  behaves as an ordinal
Mathemetically a set is not ordered.
You misunderstood me.
Wrong again, in only two days..... Check your sources.....

[Zoran]

No, that's plain wrong! A Pascal set is not ordered.

A Pascal set is ordered. In all pascal dialects. A pascal set is ordered, and  behaves as an ordinal
Mathemetically a set is not ordered.
You misunderstood me.
Wrong again, in only two days..... Check your sources.....

How is it ordered?
Of course I might be wrong, but can you take a look at what I wrote earlier and answer:
Regarding order, how does the Pascal set differs from mathematical set which you claim is not ordered (I certainly agree with that)? What makes the difference? А Pascal set has some limits which do not exist in mathematical sets -- it is always finite and cannot have more than 256 elements, the underlying type must be an ordinal type. But nothing that would make a difference regarding order.

, and  behaves as an ordinal

This is a particularly strange claim! Perhaps you can make an example which shows what do you mean, how a set behaves like an ordinal!?

The ordinals can be put in a unique order, as they are always comparable, (a<=b) or (b<=a) is always true, for any a and for any b.
For instance, let's look at numbers 2 and 5 - one of these expressions is true: 2<=5 or 5<=2.

Lets look at the Pascal sets A=[2, 3, 5]; B=[1, 2, 3, 5, 7, 9], C = [3, 5, 9].
A and B are indeed comparable (A <= B equals True), so are B and C (C <=B), but A and C are not (both A<=C and C<=A are False).

[440bx]

A set is unordered, for instance [a, b] = [b, a], the fact that the order of the elements differs does not affect equality.

That said, in Pascal (and likely other compilers that implement sets), every set element is enumerated.  Using that enumeration, the compiler selects the bit that represents the set element.  That is a form of ordering but, that ordering does NOT affect set equality (among other possible operations applicable to sets.)  IOW, the internal implementation does not affect the mathematical properties of sets, among them, that element order does not affect the set properties.


@Zoran,

Because Pascal enumerates the set elements and selects a bit based on that enumeration, it is fair to say that sets are internally ordered, i.e, bit 0 is always the first element, bit 1 the second and so on but, that internal ordering  does not impose an external ordering.  i.e., [a, b] still equals [b, a]


In Mathematics a set is an unordered collection of elements and FPC's implementation is true to all mathematical properties of sets. 

It's internal implementation, so far, imposes only a few limits, among them the number of elements that a set can contain.  IOW, a Pascal set has a limit (currently 256), a Mathematical one does not (e.g, set of primes.)

The current implementation also imposes limits on the values of the elements that can be members of a set, e.g, defining a set of [32767..32800] is asking for trouble because FPC does not handle a lower or upper) bound outside the 0 through 255 range. 

[alpine]

The ordinals can be put in a unique order, as they are always comparable, (a<=b) or (b<=a) is always true, for any a and for any b.
For instance, let's look at numbers 2 and 5 - one of these expressions is true: 2<=5 or 5<=2.

Lets look at the Pascal sets A=[2, 3, 5]; B=[1, 2, 3, 5, 7, 9], C = [3, 5, 9].
A and B are indeed comparable (A <= B equals True), so are B and C (C <=B), but A and C are not (both A<=C and C<=A are False).

There is a thing called "partial order" and the inclusion operator (<=) defines such a partial order in a set, but that is true both for math and the FPC.
I'm just amazed by the topic and the debate.

[Zoran]

There is a thing called "partial order" and the inclusion operator (<=) defines such a partial order in a set, but that is true both for math and the FPC.

Yes, each set type in Pascal is partially ordered by operation "<=" (subset, or whatever the correct term in English is), and yes that is so in both math and fpc. So we can say that sets in Pascal are ordered just as much as the sets are ordered in math - that was what I've been trying to say from the start.

Unlike this, ordinal types in Pascal are totally ordered (each two elements are comparable).

I'm just amazed by the topic and the debate.

Because Pascal enumerates the set elements and selects a bit based on that enumeration, it is fair to say that sets are internally ordered, i.e, bit 0 is always the first element, bit 1 the second and so on but,

I disagree that it is fair to say. It is misleading - sets are not internally ordered.
The set is not internally represented by any particular bit. It is the members which are represented by the bits, not sets. So the members are ordered (and that's the reason why the elements' type must be ordinal), sets are not internally ordered.
How are these three sets internally ordered (shown here by the underlying bit representation):
A=10010100, B=11010111, C=00010110 ?
The answer for these is A<=B, C<=B, A and C are not comparable.

By the way, I really wanted to avoid the talk about the internal representation (because it shouldn't be relevant), but I should have known it was sooner or later unavoidable.

[TRon]

By the way, I really wanted to avoid the talk about the internal representation (because it shouldn't be relevant), but I should have known it was sooner or later unavoidable.

+1

You should not care about that for even a split second. Imagine having to do that for every programing language in use... such a waste of time with absolutely no gain whatsoever that is unless you are compiler developer actually implementing as such.

[440bx]

I disagree that it is fair to say. It is misleading - sets are not internally ordered.

Not only it is fair to say, it is 100% accurate. 

The compiler has to choose a bit to represent a set element.  It is internally ordering the elements, each element is assigned a different bit, which consequently orders the elements, without that order it simply cannot represent the set.

The set is not internally represented by any particular bit.

read slowly, the sentence referred to set elements. 

It is the members which are represented by the bits, not sets.

Really ?...  you're so smart.

Good luck!

[Zoran]

It is the members which are represented by the bits, not sets.

Really ?...  you're so smart.

Or not.

Anyway, by what you said, it is obvious that you do understand well how sets work.
That is why I find it quite strange that you said that "it's fair to say that the sets are internally ordered", when it seems quite clear that you understand that only their elements are ordered...

And the fact that the elements are ordered and that the type on which a set is declared must be an ordinal type is what makes such statements even more problematic, because it can lead to confusion. That is why I believe that such a statement can only be misleading, not fair.

[440bx]

That is why I find it quite strange that you said that "it's fair to say that the sets are internally ordered", when it seems quite clear that you understand that only their elements are ordered...

Looks like we're getting off track due to semantics. what's "inside" a set are its elements, my saying that sets are internally ordered means that their elements are ordered (the enumeration imposes the order.)

One thing I find "less than ideal" is the assumption that the internal representation shouldn't be taken into account or the programmer shouldn't have any knowledge of.  Nothing could be farther from reality.  It is understanding the compiler's internal representation that explains the behavior of this small program:

Code: Pascal  [Select][+][-]

1. program _sets;
2.  
3. var
4.   a, b, c : integer;
5.  
6. begin
7.   a := 500;
8.   b := 550;
9.   c := 525;
10.  
11.   if c in [a..b] then writeln('c is in the set') else writeln('c is NOT in the set');
12.  
13.   a := 50;
14.   b := 55;
15.   c := 52;
16.  
17.   if c in [a..b] then writeln('c is in the set') else writeln('c is NOT in the set');
18.  
19.   readln;
20. end.
21.  

Of course, the code above is purposely written to demonstrate what can happen to a programmer who doesn't understand (or ignores) the internal representation of sets.

Currently, while the compiler enumerates the elements of a set, it _needs_ a direct correspondence between the enumeration and the value of the element.  That's why the first case doesn't yield the value an unsuspecting programmer would expect.

Lastly, that's just one of the traps a programmer who doesn't understand (or ignores) how sets are implemented can fall into.

[TRon]

First rule of documentation: comprehending what it reads 

[Zoran]

Looks like we're getting off track due to semantics. what's "inside" a set are its elements, my saying that sets are internally ordered means that their elements are ordered (the enumeration imposes the order.)

I wouldn't say the elements are ordered in the set - the set to which the elements belong has nothing to do with their order. This order is not a property of the set. These elements got this order in their ordinal type, and it's their property which doesn't change and which they have regardless of the set.

The array orders its elements, which may or may not be of an ordinal type. Their place in the array is independent of their own type, its something they get when they are included in the array.
That's why we say that an array is an ordered structure, unlike a set.

[alpine]

There is a thing called "partial order" and the inclusion operator (<=) defines such a partial order in a set, but that is true both for math and the FPC.

Yes, each set type in Pascal is partially ordered by operation "<=" (subset, or whatever the correct term in English is), and yes that is so in both math and fpc. So we can say that sets in Pascal are ordered just as much as the sets are ordered in math - that was what I've been trying to say from the start.

Unlike this, ordinal types in Pascal are totally ordered (each two elements are comparable).

Strictly speaking, the total order requires relation to be reflexive, transitive, asymmetric and, what you have mentioned earlier, strongly connected (x<=y or y<=x). https://en.wikipedia.org/wiki/Total_order
As long as in the computer memory everything is represented by a whole numbers (exclude the recent quantum delirium) a secondary total order can be always defined by considering the N injection, i.e. everything is countable. But this is just a rethought theory, where is the practical benefit in the end?

I'm just amazed by the topic and the debate.

And increasingly puzzled, we should be aware of the limitations of the sets in Pascal and ultimately use them for their intended purpose/convenience, without pointless debates. (Not a personal remark)

Really a lot of pointless pages have been written lately full of nagging on topics regarding types in FPC (to mention the Boolean). Unfortunately this forum has become quite repulsive lately.

[Zoran]

There is a thing called "partial order" and the inclusion operator (<=) defines such a partial order in a set, but that is true both for math and the FPC.

Yes, each set type in Pascal is partially ordered by operation "<=" (subset, or whatever the correct term in English is), and yes that is so in both math and fpc. So we can say that sets in Pascal are ordered just as much as the sets are ordered in math - that was what I've been trying to say from the start.

Unlike this, ordinal types in Pascal are totally ordered (each two elements are comparable).

Strictly speaking, the total order requires relation to be reflexive, transitive, asymmetric and, what you have mentioned earlier, strongly connected (x<=y or y<=x). https://en.wikipedia.org/wiki/Total_order
As long as in the computer memory everything is represented by a whole numbers (exclude the recent quantum delirium) a secondary total order can be always defined by considering the N injection, i.e. everything is countable.

Yes, that is of course so, but...

But this is just a rethought theory, where is the practical benefit in the end?

I'm just amazed by the topic and the debate.

And increasingly puzzled, we should be aware of the limitations of the sets in Pascal and ultimately use them for their intended purpose/convenience, without pointless debates. (Not a personal remark)

Really a lot of pointless pages have been written lately full of nagging on topics regarding types in FPC (to mention the Boolean). Unfortunately this forum has become quite repulsive lately.

The original subject of this topic got polluted. I am sorry for taking big part in this, but I couldn't just leave Thaddy's claim ("Pascal sets are ordered") unanswered, and then "Pascal set type behaves as an ordinal type". I still think that, had this topic been left finishing with such statements, it would have been more damaged than it is now.

[alpine]

The original subject of this topic got polluted. I am sorry for taking big part in this, but I couldn't ...

No need to be sorry, I also fall for this bait from time to time. Others have pointed out the usual pollutants here more than once, so I won't.