Re^2: Quantum Weirdness and the Increment Operator

Good morning Abigail.

Looking up the word "behaviour", I find that it relates to "actions" and "reactions". Things that have happened. Actions that have taken place. Past tense.

Saying that behaviour is undefined, makes no sense. Until something has happened it isn't behaviour.

If you predict that a certain thing will (future tense) display a certain behaviour, and you get it wrong. It didn't display the "wrong behaviour", or "no behaviour". The action the the thing displayed (past tense) was the behaviour. You were simply wrong in your prediction.

Therefore, you can't say a "behaviour is undefined", because an action or reaction doesn't become behaviour until it has happened, and when it has happened, it can be measured, and is therefore not "undefined".

It may not be predictable--though in this case, I (rashly) bet the outcome has been the same since Perl 1; maybe you would confirm that?--which kinda makes it a bit predictable.

It may also be unexplainable. Which may explain why the explainations are so lacking.

It is, however, OBSERVABLE! Huge red font omitted.

If a phenomena can be observed, it can be questioned. The strongest defining impulse of the human being over our non-sentient co-inhabitants, is the ability and need to ask the question WHY?.

You may well be correct in reaching your conclusion that asking why is not "worth your effort" or "likely to result in a you reaching a satisfactory conclusion", but that is your conclusion. It satisfies your criteria.

Is it your assertion that because you have reached a conclusion that satisfies you, that noone else in the entre world is allowed to think about this, or discuss it any place where you might observe that discussion?

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

Comment on Re^2: Quantum Weirdness and the Increment Operator

Replies are listed 'Best First'.
Re^3: Quantum Weirdness and the Increment Operator by halley (Prior) on Jun 25, 2004 at 14:28 UTC
"Results are undefined" in Computer Science means, "the documentation is not going to explain what you'll get in Tuesday's version of the compiler on John's favorite machine." In the case of `keys %foo`, the results are defined: you will get all keys. The order they're returned is defined but poorly so: it's a mistake for documentation to say they are returned in "random order," because the order has nothing to do with a PRNG. It would be better to say the order is not defined, as that is more accurate. Tuesday's compiler on John's machine will produce something inconsistent with your own experiments. In the case of `++$m + $m++`, the results are undefined: no documentation claims to give an authoritative answer on such expressions, and some documentaion will specifically disavow any predictable results. For those who do not program in C, here's the gist of the action. The `do { my $x = $m; $m++; $x }` mechanism is not a sufficient postincrement operator, because real post-incrementation happens after the rest of the expression. However, the specific moment that is defined to be after the rest of the expression is not clearly defined; various versions of a C compiler will differ, and various hardware platforms may also have something to say about it. It's undefined. -- `[ e d @ h a l l e y . c c ]`	[reply] [d/l] [select]
Re^3: Quantum Weirdness and the Increment Operator by southampton (Novice) on Jun 24, 2004 at 20:19 UTC
By 'undefined', I think the traditional comp-sci meaning of "you may get anything or nothing" was meant. There's no telling what will happen, and whatever does happen may change over time as new compilers and libraries are implemented.	[reply]
Re^4: Quantum Weirdness and the Increment Operator by BrowserUk (Patriarch) on Jun 24, 2004 at 20:54 UTC
I think the more accurate Comp-Sci phrase is "not well defined". For any given implementation, you can tell what will happen, because it is very unlikely to vary from what happened last time on that same implementation. It may well vary with other implementations. The implementers may (and do) choose not to define the behaviour. Because it may vary across implementations. Because the explanation my not appear logical or rational. Because it isn't a useful behaviour. Mostly, because if they do define the behaviour, then they will have to ensure that the defined behaviour is consistent across platforms and versions. Which if the behaviour is generally non-useful, and is likely to be influenced by things (like compilers) beyond their control, then the extra work that this would commit them to is not worth it. the defined behaviour will have to be defendable and defended. Also a waste of energy for what is essentially a non-useful behaviour. But given the OP's disclaimer; statement that this was purely an academic exercise; etc.; his being condemned on the basis of a non-sequitous statement, and a short phrase in an obscure document that the behaviour "is same as C"--where it may be defined as not being well-defined, but my attempts to located such definition in K&R or Waite Group's guide haven't located it--hardly seems justified. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon	[reply]
Re^5: Quantum Weirdness and the Increment Operator by ihb (Deacon) on Jun 25, 2004 at 02:58 UTC
For any given implementation, you can tell what will happen, because it is very unlikely to vary from what happened last time on that same implementation. Does that even apply to the order that `keys %foo` return the keys of `%foo`? `ihb`	[reply] [d/l] [select]
Re^6: Quantum Weirdness and the Increment Operator by BrowserUk (Patriarch) on Jun 25, 2004 at 03:28 UTC