Re: copying arrays

Alan Manuel K. Gloria wrote:
> In my experience it's quite rare to have to have to *copy* a
> sequence. If you're manipulating an array, why would you want to
> retain the previous version? What is it that you are trying to do?
> In general, it is usually very rare that you have to actually copy
> the sequence.

Dan Bensen wrote:
> In a game, you might want to pass the state of the game
> (e.g. the board in a board game) to a computer player
> so it can decide what it wants to do. The safe way to do that
> would be to pass the player a copy, so the player doesn't
> corrupt the game. Often the player will destructively modify
> the board, but undo all its changes at the end. With a copy,
> you can also check the player for correctness by comparing
> the final state of the player's copy with the original board.

Kent M Pitman wrote:
> Warning: The "rant" below might or might not be relevant to Dan's
> remarks directly. So don't take this as necessarily responding to
> his particular situation.
With all due respect, Kent, that's exactly how I take it.
You directly addressed me and my comments in a highly critical way.

> it's no "more safe" to call a function that's supposed to
> add 1 to a number only to find that it subtracts 1.
This is ridiculous. In many cases, one glance at (incf x)
will be enough to determine whether it's correct.
The same cannot be said for dozens or hundreds of lines
of tree-searching code.

> A program that does not understand its contract is unsafe.
> If a program does understand its
> contract, it can use side-effects safely.
A buggy program is also unsafe, even if it understands its contract.

> Yes, it's true, there are cases where you give a piece of structure to
> a program that is supposed to do some computation, and it's true that
> it can accidentally do a side-effect if the programmer is not aware
> that they are receiving shared structure. But there's a strong
> question of whether this is a bug in the use of operators or in
> the definition of protocol.

There's also a strong question of whether human programmers are
infallible and whether bugs should be guarded against in a modular way.

> The fact that this word "safe" is used in relation to destructive
> operators that people simply learn badly and use badly suggests that
> it is just code for talking about another attribute of people because
> they are uncomfortable talking directly to the issue of programmer
> competence.
> I'd rather teach people to be competent than pamper them in this way.

I don't think it's code, I think it's a simple fact. You can't teach
people to be perfect. If your code is in production use, it may be
safer for it to fail gracefully instead of blindly allowing
every part of the program to change important data.

> I've seen people who purport to be serious programmers
> stare at programs and say out loud "what if we replace these
> destructive operators with non-destructive ones, does that fix it?"
> It reminds me of when I first got in-range of solving Rubik's cube.
> I feel the same about yielding up the control of protocol design to
> the chance sense that someone might not make or read a protocol
> definition.

With all due respect, neither of those subjects has anything to do
with this thread, and I really don't appreciate being the person
whose post you use in discussing bad programmers.

>> The safe way to do that would be to pass the player a copy,
>> so the player doesn't corrupt the game.
> Safe is relative. What if safety is based on space as a criterion?
> Running out of space in a lot of cases will swamp a program just as
> quickly as a program error, and the idea of copying a large game board
> an a possibly-exponential number of times seems destined to do badly

Also in the most polite terms I can muster, you're knocking down
a straw man, and not even a clever one. Avoiding exponential copying
is precisely the point of a destructive search, so obviously that
can't be what we're talking about. All I said was that it might help
to make a copy at the root of the search.

>> Often the player will destructively modify the board,
>> but undo all its changes at the end.
> Ownership is something everyone should understand, whether it's
> something in the real world or something in the imaginary world.
> People need to know what they can modify and what they can't.
> This is as fundamental as "caller saves vs callee saves",
> and cannot be left to chance.

Actually, what I had in mind is a search that's called only for
its return value, even though it searches destructively for
performance reasons. The callee doesn't save in that protocol
becuase that's not its job. It doesn't make sense to give the
callee access to the original copy of the data if it's not being
called for side effects.

> You're talking like people can independently choose their
> favorites, and I'm not sure I see that's so.
I have no idea what that means.

> Lisp, as a natural set of operations, assumes callee-saves,
> since it assumes that pointer-passing is the efficient way.
That sounds like a bad idea if it's not necessary. In the real,
imperfect world that we all live in, it's safer to minimize the
amount of code that can potentially corrupt important data.

> This statement isn't just a statement by itself but is offered in
> a context where it has increased importance. It's in a situation
> where it's defending not just making a copy, but making one often.
Again, you're just making stuff up. I never suggested any such thing.

> I infer that it's on each call that we're talking.
You infer incorrectly. I would make a copy on each call
to the entry point at the root of the search tree,
not at every node.

> But there's a subtext of your remarks that seems to imply you can get
> from there to "copies are good, and it's non-copies that are a danger"

No, there is no such subtext. But as long as we're discussing subtext,
is it just a coincidence that this post of yours occurred only days
after I made a technical criticism of the HS? Just wondering.

--
Dan
www.prairienet.org/~dsb/
.

Relevant Pages

  • Re: Exploitation and Evasion
    ... We try to balance Crawl such that no player is ever safe. ... If a game cannot be won safely, we'll obviously get unfair games -- the unfairness could be the sudden appearance of three lethal bad guys who snipe the player in two rounds, or also the absolute lack of poison resistance. ...
    (rec.games.roguelike.development)
  • Re: Eve Online - Thoughts for Noob!
    ... And the 'safe' areas are pretty much solo-only & don't have any of the ... realised I was done with the game after the 14-day trial. ... EVE isnt for everyone, either you like it or you don't. ... Funny you mention grouping and team work, did you actually pursue any player ...
    (comp.sys.ibm.pc.games.rpg)
  • Poker Strategies Teil 1 Author Selzer-McKenzie
    ... Texas Hold’m Poker Secrets and Strategy ... deals around until each player has two cards face down. ... If there is more than one player left in the game at the end, ... The second round of betting (after the flop) is in units ...
    (de.etc.finanz.misc)
  • Re: Play to Win - counter-intuitive example
    ... activities...Collusion to alter the results of a game". ... Since I really don't see what function it serves, given PTW, I'd say it should ... the rulebook when they're in conflict with the goals written in the rulebook." ... except to make sure no single player gains a second one to get a game win. ...
    (rec.games.trading-cards.jyhad)
  • Federer blog - February/March 2007 ...
    ... it's the greatest player of all time here". ... Pete, how's it going?" ... a huge weakness in my game as I always piss ... to play tight matches, due to ...
    (rec.sport.tennis)