Hi,
after having spent many hours, I finally found the reason
for a bug which resulted from an apparently completely harmless
rewrite of a function in set-ish style to list-ish style:
I have a function f, which suddenly aborted with strange error messages
when obtaining its input from a function g. Now when just copying the
output of g, then f works fine, and also when redefining the function g
on the command-line, also no problem --- only when g itself is used,
and defined in a file, then the error occurred.
I'm using the hash-table from graph_core.lisp in the graphs-package.
The error occurs when evaluating the hash-table on some non-atomic
value which apparently is in the table, for example:
hash_table_data shows
[1 -> 1, [1, - 1] -> 2, [1, 1] -> 3]
but the hash-table evaluated on [1,1] yields false (i.e.,
undefined).
Now I printed out the hash-table itself, and what did my surprised eyes see:
#S(HASH-TABLE TEST FASTHASH-EQUAL
(((MLIST SIMP
(75 /home/kullmann/csoliver/SAT-Algorithmen/OKplatform/OKsystem/Transitional/ComputerAlgebra/\
Graphs/Lisp/tests/Basic.mac SRC
$OKLTEST_DG2MDG 28))
1 1)
. 3)
(((MLIST SIMP) 1 -1) . 2) (1 . 1))
h2: [1 -> 1, [1, - 1] -> 2, [1, 1] -> 3]
V: [1, [1, - 1], [1, 1]]
E: [[1, [1, - 1]], [1, [1, 1]]]
h: [1 -> 1, [1, - 1] -> 2, [1, 1] -> 3]
set map: {[1, 1], [[1, - 1], 2], [[1, 1], 3]}
H: [[1, false], [1, false]]
e: [1, [1, - 1]] , 1 [1, - 1] ; [1, false]
e: [1, [1, 1]] , 1 [1, 1] ; [1, false]
#S(HASH-TABLE TEST FASTHASH-EQUAL
(((MLIST SIMP
(89
/home/kullmann/csoliver/SAT-Algorithmen/OKplatform/OKsystem/Transitional/ComputerAlgebra/Sat\
isfiability/Lisp/ClauseSets/Hypergraphs.mac
SRC $VAR_LIT_CLAUSE_DIGRAPH 87))
1 1)
. 3)
(((MLIST SIMP
(89
/home/kullmann/csoliver/SAT-Algorithmen/OKplatform/OKsystem/Transitional/ComputerAlgebra/Sat\
isfiability/Lisp/ClauseSets/Hypergraphs.mac
SRC $VAR_LIT_CLAUSE_DIGRAPH 87))
1 -1)
. 2)
(1 . 1))
That's pretty fascinating: The hash-table stores the origin of the values, namely for example
that it comes from function $VAR_LIT_CLAUSE_DIGRAPH, and there, more precisely,
from line 89 in file /home/kullmann/csoliver/SAT-Algorithmen/OKplatform/OKsystem/Transitional/ComputerAlgebra/Sat\
isfiability/Lisp/ClauseSets/Hypergraphs.mac.
Ha! That's quite an accomplishment for a little hash table: Perhaps it's no wonder that Maxima
is slow, when it's carrying around with every compound value its origin.
Now the above bug is explained: Entering a plain list [1,1] into the hash-table
is not good enough, since it doesn't match with the original [1,1] which has
these annotations. In this way all of mathematics vanishes --- my vector and your
vector are not the same, since created by different persons at different places (it's
a little bit disappointing that not also time and other data is stored --- perhaps
terrorists could be caught in this way).
Is this behaviour common with Maxima?? Or is only the hash-map so obfuscated, so that it
cannot be used otherwise? How to disable this intentional behaviour (back to good old
extensionality)??
Hope somebody can enlighten me; the hash-map is really useful.
(Btw, such things seems to me much more irritating than any dynamic binding.)
Oliver