[Maxima-commits] CVS: maxima/share/contrib/graphs graph_core.lisp, 1.15, 1.16



2008/5/6 Stavros Macrakis <macrakis at alum.mit.edu>:
> On Mon, May 5, 2008 at 7:34 PM, Oliver Kullmann
>  <O.Kullmann at swansea.ac.uk> wrote:
>
> >  In Maxima it should be simple:
>  >  Isn't every object a term? So just evaluate this term, take it as a string, use a standard hash function for strings, and use bucket hashing.
>
>  Maxima operations work on the internal list structure (tree). If you
>  want to hash the string value, you can certainly do that as well,
>  though it is rather inefficient.
>
>
>  >  But the hash-table from the graphs-package works normally!
>
>  No, this contributed package has a bug:
>
>
>     load(graphs)$
>     h: hash_table()$
>     set_hash(x^2,h,x2)$
>     set_hash(ratsimp(x^2),h,ratsimpx2)$
>     get_hash(x^2,h) => x2
>     get_hash(ratsimp(x^2),h) => ratsimpx2
>     is(x^2 = ratsimp(x^2) ) => true
>
>  Maxima expressions may be equal (predicate: alike1) as Maxima objects
>  without being equal as list structures.  Perhaps the simplest example
>  is x^2 vs. ratsimp(x^2) -- internal forms ((mexpt simp) $x 2) and
>  ((mexpt simp ratsimp) $x 2). A correct hash function would ignore all
>  the annotations (like ratsimp).  Unfortunately, Common Lisp apparently
>  has no standard way of specifying a hash function for its hash table
>  operations.  The simplest way to fix this is to copy the arguments,
>  stripping the annotations.

This is not a bug. A bug is when a function gives results which are
different from what the author intended. The has table functions are
not documented. You shouldn't assume anything about functions which
are not documented. If you find a function in graphs package which
gives results different than what the documentation claims, then that
is a bug. I have no interest in providing a general hash table in the
graphs package.

-- 
Andrej