Russ Abbott russ.abbott at gmail.com
Thu Nov 25 12:53:32 EST 2010

```I gave this concrete example a couple of messages ago.

Let's assume that instead of keeping for each cage the Operation and target
number we pre-compute all the combinations of values that will satisfy the
cage.  For example, assume that in a 4x4 game, we have a cage that refers to
cells C1 and C2 and that the cage requires those two cells to produce a
value of 2 using division,

Pre-computing the possibilities, we store [(1, 2), (2, 1), (2, 4), (4, 2)]
in this cage.

The cage points to the two cells it constrains, and each cell points to the
cage that constrains it.

When a cell (say C1) gets a value of (say) 2, we want to change the cage to
be [(2, 1), (2, 4)]. But when that happens, it's necessary to change cell C2
to point to the new cage -- and of course since the cell was changed the
construct that held that cell has to be changed also.

It's a bit of a pain to write the code to do all that.  This isn't to say
that the code will take that long to run or that it will use excessive
memory -- only that it feels like one is being forced to write code that one
shouldn't have to write.

*
-- Russ *

On Thu, Nov 25, 2010 at 9:42 AM, Ozgur Akgun <ozgurakgun at gmail.com> wrote:

>
> On 25 November 2010 17:12, Russ Abbott <russ.abbott at gmail.com> wrote:
>
>> Thanks, Patrick. I'm disappointed, though, that no one has
>> actually responded to my question. It wasn't how to solve KenKen. It was how
>> best to deal with quasi-mutable data structures.
>>
>
> You gave an example about how your data structure look like, but I haven't
> seen an example  case of "quasi-mutating" an expression of such data
> structures. If you give a concrete example, people can suggest better ways
> of doing it, if there are any.
>
> Best,
> Ozgur
>
-------------- next part --------------
An HTML attachment was scrubbed...