MaplePrimes - answers and comments on Question, Remember tables

Records are mutable

Carl Love — Sun, 09 Dec 2012 07:16:23 Z

Records are mutable, as the following shows:

restart;
A:= Record(a=1):
B:= Record(a=1):
T[A]:= 1: T[B]:= 2:
eval(T);

table([B = 2, A = 1])

Compare that with what happens with an immutable structure, in this case an unevaluated function call (named `record`, just for fun):

restart;
A:= record(a=1):
B:= record(a=1):
T[A]:= 1: T[B]:= 2:
eval(T);

table([record(a = 1) = 2])

But that doesn't mean that they absolutely can't be used with remember tables. If the records being compared are address identical, not just copies which "just happen to be" equal, then the remember table will recognize them. If just a few cases slip through unrecognized because they just happen to be equal, it won't ruin your recursion. On the other hand, if your algorithm relies on making copies of records (not just copying the address, or pointer), the remember table won't work.

Cache tables, remember tables, and just-plain tables all function like the tables in the examples above. The only difference that cache tables have is that the amount of memory that they use can be easily controlled.

Another example of mutability

Carl Love — Mon, 10 Dec 2012 05:05:01 Z

The example above showed that two Records which seem identical but are stored at different addresses will be stored as separate entries in the table---which may slow down the recursion, but won't cause a real error. The following example---of the converse situation: different Records, same address---is more insidious.

restart;
A:= Record(a=1):
T[eval(A)]:= 1:
A:-a:= 2:
eval(T);

table([Record(a = 2) = 1])

So even though the record has changed, the value associated with it in the table has not. This situation would cause a procedure that used a remember table on Record arguments to give wrong results.

There is a way that cache tables might help, though it wouldn't usually be worth it: If the situation in the example immediately above was relatively rare, then you could clear the cache every time you changed the contents of a record.

@Carl Love Yes, your 2nd example demonstrates

Mac Dude — Mon, 10 Dec 2012 07:36:32 Z

@Carl Love Yes, your 2nd example demonstrates what I have already seen in a different context: changing field-contents of a record by assignment is a bit dangerous, leading in my case to the whole thing getting out of sync as the fields in my records are interrelated. The moral here is to only use setter routines to change the content of any field, and then making sure it is all done right. Presumably I can then use forget (in the setter routine) to clear the remember table or maybe even just the relevant entries.

More work is needed but I go the basic structure to work, and the remember option definitely speeds things up.

Thanks for an illuminating discussion of this topic,

M. D.