arrayinfo fails on hashed array created by make_array(hashed, ...)

[rtoy]

Imported from SourceForge on 2024-07-08 10:28:13 Created by robert_dodier on 2021-02-24 04:41:42 Original: https://sourceforge.net/p/maxima/bugs/3721

---

arrayinfo fails on a hashed array created by make_array(hashed, ...) although arrayinfo handles a hashed array created by use_fast_arrays: true and then assigning to elements of the array.

Looks like arrayinfo is constructing the key list incorrectly for hashed arrays created by make_array(hashed, ...). Dunno how those differ from the ones created by use_fast_arrays: true.

%o4 is actually incorrect here; it should be [hash_table, 1, [aaa]].

(%i1) hh1: make_array (hashed, 1);
(%o1)    {Lisp Array: #<HASH-TABLE :TEST EQUAL :COUNT 1 {100276D563}>}
(%i2) hh1["aaa"]: 123;
(%o2)                                 123
(%i3) trace(arrayinfo);
(%o3)                             [arrayinfo]
(%i4) arrayinfo(hh1);
1 Enter arrayinfo [hh1]
1 Exit  arrayinfo [hash_table, 1, aaa]
(%o4)                        [hash_table, 1, aaa]
(%i5) hh2: make_array (hashed, 2);
(%o5)    {Lisp Array: #<HASH-TABLE :TEST EQUAL :COUNT 1 {100277DB23}>}
(%i6) hh2["bbb", "ccc"]: 9392;
(%o6)                                9392
(%i7) arrayinfo (hh2);
1 Enter arrayinfo [hh2]
1 Exit  arrayinfo [hash_table, 1, (bbb, ccc)]
Maxima encountered a Lisp error:

 The value
   "bbb"
 is not of type
   SYMBOL
 when binding SYMBOL

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i8) use_fast_arrays: true $

(%i9) hh3["ddd", "eee"]: 9121;
(%o9)                                9121
(%i10) arrayinfo (hh3);
1 Enter arrayinfo [hh3]
1 Exit  arrayinfo [hash_table, true, [ddd, eee]]
(%o10)                  [hash_table, true, [ddd, eee]]

[rtoy]

Imported from SourceForge on 2024-07-08 10:28:15 Created by robert_dodier on 2022-09-01 20:21:37 Original: https://sourceforge.net/p/maxima/bugs/3721/#3f91

---

I bumped into this bug again and it looks like the current behavior hinges on the presence or absence of the key DIM1 for the hash table. It appears that DIM1 being present as a hash key means that the hash table has 1 index, otherwise it has multiple indices.

When DIM1 is absent, arrayinfo returns the list of keys as [..., [a, b, c], [d, e, f], ...], i.e. each key (third and later items) is a list. However, when DIM1 is present, arrayinfo returns [..., a, b, c, ...], i.e. each key is a simple item, not a list such as [... [a], [b], [c], ...] as one might expect by analogy with two or more keys.

Note that make_array(hashed, 2) actually defines a hash table with ONE key, not two. So hh2: make_array(hashed, e); hh2["bbb", "ccc"]: ... is incorrect -- there's an inconsistency between the number of keys declared and used. That's probably a bug in array assignment -- it should detect the inconsistency and refuse the assignment.

At this point I guess it looks like the bug is actually in array assignment; it should detect and reject the inconsistency.

I think the DIM1 business is suboptimal, since it makes one key results different from two or more. I'm kind of leaning towards expunging DIM1 and making arrayinfo results consistent between one and two or more keys, but that's beyond the scope of this bug.

Also, another wart is that make_array(hashed, foo, bar, baz) doesn't actually make use of foo, bar, or baz, or even how many there are exactly; only whether there's one or two or more. Not sure how to clean that up. Maybe just accept one argument, which is an integer telling the number of keys (as I was implicitly assuming when I wrote this bug originally).