hi,
when doing a union (|) on arrays it appears as if the first array remains as is, and then any missing values from the second array are appended, with duplicates in the first array remaining.
a = ({ 1, 7, 2, 5, 4 }); b = ({ 2, 1, 3, 5, 5 });
a|b is ({ 1, 7, 2, 5, 4, 3, 5 }) b|a is ({ 2, 1, 3, 5, 5, 7, 4 })
the reason for these questions is that the tutorial claims: the elements in the result can come in any order and duplicates may or may not be removed.
should pike be (and remain) that unpredictable?
greetings, martin.
Just because the tutorial allows for Pike to be unpredictable doesn't necessarily mean that Pike is.
/ Martin Nilsson (DivX Networks)
Previous text:
2004-09-19 02:43: Subject: duplicates in a|b
hi,
when doing a union (|) on arrays it appears as if the first array remains as is, and then any missing values from the second array are appended, with duplicates in the first array remaining.
a = ({ 1, 7, 2, 5, 4 }); b = ({ 2, 1, 3, 5, 5 });
a|b is ({ 1, 7, 2, 5, 4, 3, 5 }) b|a is ({ 2, 1, 3, 5, 5, 7, 4 })
the reason for these questions is that the tutorial claims: the elements in the result can come in any order and duplicates may or may not be removed.
should pike be (and remain) that unpredictable?
greetings, martin.
/ Brevbäraren
which is exactly why i am asking. i'd like to replace this attribution to voodo with a correct prediction.
greetings, martin.
The manual does intentionally not specify the order, so as to allow for algorithm changes.
/ Henrik Grubbström (Lysator)
Previous text:
2004-09-19 03:29: Subject: Re: duplicates in a|b
which is exactly why i am asking. i'd like to replace this attribution to voodo with a correct prediction.
greetings, martin.
/ Brevbäraren
good point, but claiming its random sounds wierd, something like "the current algorithm..." or not explaining it at all seems better.
greetings, martin.
Well, some of the array operations have had "random-" (or rather hash-) order in their result. Explicitly saying that the order is undefined or random makes sure that nobody writes code that relies on the order.
/ Henrik Grubbström (Lysator)
Previous text:
2004-09-19 10:33: Subject: Re: duplicates in a|b
good point, but claiming its random sounds wierd, something like "the current algorithm..." or not explaining it at all seems better.
greetings, martin.
/ Brevbäraren
The manual is inconsistent since the docs for `|() do state that order is preserved.
In my experience the documentation and the reality have never been totally in sync. Back in 7.2 the order wasn't preserved even though the docs claimed so, and later the implementation (at least 7.4+) was changed to fix that, so I don't really understand why people here say it's left undefined.
/ Jonas Walldén
Previous text:
2004-09-19 10:26: Subject: Re: duplicates in a|b
The manual does intentionally not specify the order, so as to allow for algorithm changes.
/ Henrik Grubbström (Lysator)
i suppose there is a different between order that is not preserved (and thus changes frim run to run) to order that is not defined but predictably consistent.
the questions are: what result would we like to have ideally? do we get that result? if yes, then the result is not going to change and may be documented as such. if no, what is the best description for the current result that will not confuse people even if it changes later?
currently the most correct description seems to be: the order is undefined but consistently the same (for 7.6)
greetings, martin.
We like all the set operators to provide a completely well defined order on arrays, and afaik we get that in 7.4.36 and later. In 7.6 there's also a fairly detailed doc for the operators that among other thing describes the order. You're very welcome to update the tutorial with this.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-09-19 17:52: Subject: Re: duplicates in a|b
i suppose there is a different between order that is not preserved (and thus changes frim run to run) to order that is not defined but predictably consistent.
the questions are: what result would we like to have ideally? do we get that result? if yes, then the result is not going to change and may be documented as such. if no, what is the best description for the current result that will not confuse people even if it changes later?
currently the most correct description seems to be: the order is undefined but consistently the same (for 7.6)
greetings, martin.
/ Brevbäraren
excellent, that is what i have been looking for, that document is in cvs i suppose, can you give a closer pointer?
greetings, martin.
Hmm, I hoped someone more knowledgeable than me could provide an answer to this.
Anyway, no I don't know where the authorative tutorial source is. I suspect it's in the sitebuilder at pelix.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-09-21 20:51: Subject: Re: duplicates in a|b
excellent, that is what i have been looking for, that document is in cvs i suppose, can you give a closer pointer?
greetings, martin.
/ Brevbäraren
I didn't know what document you were referring to. The tutorial is in the pike.ida.liu.se sitebuilder. The best place for a authorative description would be the reference manual, which is in the Pike CVS, refdoc/chapters.
/ Martin Nilsson (DivX Networks)
Previous text:
2004-09-24 20:22: Subject: Re: duplicates in a|b
Hmm, I hoped someone more knowledgeable than me could provide an answer to this.
Anyway, no I don't know where the authorative tutorial source is. I suspect it's in the sitebuilder at pelix.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum