http://www.perlmonks.org?node_id=369484


in reply to Re^3: Quantum Weirdness and the Increment Operator
in thread Quantum Weirdness and the Increment Operator

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.

  1. Because it may vary across implementations.
  2. Because the explanation my not appear logical or rational.
  3. Because it isn't a useful behaviour.

Mostly, because if they do define the behaviour, then

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

  2. 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
  • Comment on Re^4: Quantum Weirdness and the Increment Operator

Replies are listed 'Best First'.
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

      Yes and no.

      Unless I use srand, print rand() for 1.. 100; will likely give me different output for each run of the program. So no, the output will not be the same. Yes, the output will be 100 random(ish) numbers between 0 and 1.

      The return order of keys %hash since 5.8.something is deliberately randomised, so the definition of the order is that they will be random.

      This is different to pre-5.8.something in that the order was previously "an order", that was neither random nor easily predictable, but was consistant between runs of the same program on a given build.

      The order is both defined, and explainable.


      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