performance of concatenating 1 item to an array - repeatedly

[circular]

Are you trying just to undermine whatever I am saying?

[MarkMLl]

Are you trying just to undermine whatever I am saying?

Not at all. I was just pointing out that software has some things which are assumed to be easy (sequential evaluation with conditional jumps as examples) with which "mathematics" is unhappy. This is particularly in evidence with APL- invented by a mathematician- which is very much given to "let's take the Sin() of this and multiply it by..." for cases where most "real" programming languages would say "skip this if even".

So while it might be strictly correct to describe a set as a sorted array without duplication (and I'm sure that Russell&Whitehead devotes a chapter to that), it's not necessarily helpful in a programming context. Which I'm afraid implies that notation which might make sense in a strict mathematical context might not be helpful in "real World" programming.

MarkMLl

[MarkMLl]

is a lousy idea of Turbo Pascal stolen from basic.

Just because it was "stolen" from BASIC doesn't necessarily make it a bad idea.

In any event, it's better than C/C++ "lets concatenate adjacent strings with no need for an operator".

MarkMLl

[PascalDragon]

Or is like a set union where each bit is an element of the set. And a set can be represented as an array (sorted and without duplicates).

I don't think that Pascal defines a set as being ordered: you can apply Pred() and Succ() to the base type, but that doesn't translate to LeftOf() and RightOf() applied to the set.

Modula-2 has a bitset which is defined as mapping onto the machine word, but even there the ordering was inconsistent.

To be fair in FPC and Delphi a set is represented by an array of bits. For small sizes of the base type it might be 1 to 4 Byte, but for larger types it's an array of 32-bit values (the largest currently supported is a set with 256 elements, thus resulting in an array of 8 32-bit values.

[MarkMLl]

To be fair in FPC and Delphi a set is represented by an array of bits. For small sizes of the base type it might be 1 to 4 Byte, but for larger types it's an array of 32-bit values (the largest currently supported is a set with 256 elements, thus resulting in an array of 8 32-bit values.

Undoubtedly (and I did choose my words carefully :-) but from the POV of the language even a small set could potentially be implemented as e.g. a hash table.

From an implementation POV it would probably be useful to be able to give the compiler a hint whether it was more important that a set be stored efficiently (which might allow a hash table, or mini-sets in a tree structure) or manipulable efficiently by bitwise operations.

MarkMLl

[440bx]

<snip> for larger types it's an array of 32-bit values (the largest currently supported is a set with 256 elements, thus resulting in an array of 8 32-bit values.

It would be nice if that were expanded to about 1024 elements (but... I'll settle for 512 and initialized variable groups)

[PascalDragon]

<snip> for larger types it's an array of 32-bit values (the largest currently supported is a set with 256 elements, thus resulting in an array of 8 32-bit values.

It would be nice if that were expanded to about 1024 elements (but... I'll settle for 512 and initialized variable groups)

See here.

[440bx]

See here.

That's good. ... now all we need to work on is initialized variable groups.