These are different spellings of the same value.
Except, maybe, for …x which may be treated differently.
After all, some values are not bijectively convertible,
and that goes for both domains, iirc.
Otoh, I personally would say equal numbers (0x-:0) are the same key.
So just convert, if possible, to a common representation before hashing.
Am 14.04.21 um 17:36 schrieb Henry Rich:
> Should keys must have a canonical form so that 0, 00, 0., all represent
> the same key? What about 0x?
>
> Henry Rich
>
> On 4/14/2021 11:33 AM, Raul Miller wrote:
>> That route would work.
>>
>> Though I would add "inspect [the dictionary]" as an operation here.
>> This could initially be a sampling, like J's command line display for
>> arrays. But some kind of way of inspecting the aggregate is important.
>>
>> That said, having keys of "any type" seems like overkill. It's great
>> for small implementations, but when I think about large deeply nested
>> data structures, (For example, 30 megabytes most of which is nested
>> six levels deep across thousands of boxes), I wince. (I think keys
>> have an implicit "relatively small and simple" requirement.) But don't
>> let me stop you if you want to go there.
>>
>> But, sure -- having an example application to characterize the use of
>> the system would be nice. And, there, I suppose a locale-as-a-hash
>> would be a good starting point (since a person could build a sample
>> application on a prototype and the application could then be used to
>> further characterize a "next implementation").
>>
>> With that in mind, here's a prototype:
>>
>> newdict0_z_=:{{
>> (;:'hdict0 z')copath dref=. cocreate''
>> dref
>> }}
>>
>> add_hdict0_=:{{
>> (enckey x)=: y
>> EMPTY
>> }}
>>
>> enckey_hdict0_=:{{
>> '_hdict0_',~a.{~70+(+ 8*20<])2#._5]\,(8#2)#:0-.~a.i.3!:1 y
>> }}
>>
>> get_hdict0_=:{{
>> ". ::_: enckey y
>> }}
>>
>> ------------
>>
>> Example use:
>>
>> D=: newdict0''
>> 42 add__D i.3 3
>> 'fred' add__D p:i.9
>> get__D 42
>> 0 1 2
>> 3 4 5
>> 6 7 8
>> get__D 'fred'
>> 2 3 5 7 11 13 17 19 23
>>
>> Note, however, that I have not supported "inspect the dictionary".
>> That's doable, of course, though obviously it requires additional
>> implementation -- probably doubling the size of 'add' and 'get' and
>> throwing in an additional verb approximately the size of this initial
>> implementation.
>>
>> I hope this helps,
>>
>> --
>> Raul
>>
>>
>>
>>
>> On Wed, Apr 14, 2021 at 10:56 AM Henry Rich <[email protected]> wrote:
>>> Let's get a spec for what we need before we implement.
>>>
>>> 1. What datatypes are needed?
>>> * Dictionary
>>>
>>> 2. What operations are needed?
>>> * Add key/value pairs
>>> * return value for a given key
>>>
>>> 3. What are the types of key and value?
>>> * they can have any type
>>> * perhaps the keys have to have all the same type, values likewise
>>>
>>> Please fill this out. This is as far as I got, and for that I think the
>>> Dictionary type could just be a numbered locale with a few methods.
>>>
>>> Henry Rich
>>>
>>>
>>>
>>> On 4/14/2021 10:47 AM, Raul Miller wrote:
>>>> Conceptually, here, you're probably thinking about using hashes of
>>>> character strings as array indices.
>>>>
>>>> A character string, in J, is either a boxed rank 1 list of characters
>>>> or a rank 1 member of a higher dimensional character array which has
>>>> been padded on the right hand side with spaces.
>>>>
>>>> Since all of the current array index primitives throw an error when we
>>>> try to use characters to index them, I think that we would not need
>>>> any new primitives -- we would "only" need to characterize the
>>>> normalization process used to convert arbitrary character arrays or
>>>> boxed character arrays to array indices.
>>>>
>>>> That said, these hashed arrays would also be sparse. And, it would be
>>>> desirable to support boxed items and boxed hashes. And that gets into
>>>> some issues which are ... rather involved, if we think about the
>>>> existing sparse array implementation.
>>>>
>>>> So ... when estimating this task it might be best to think of it as
>>>> "re-implementing sparse arrays from the ground up"?
>>>>
>>>> Thanks,
>>>>
>>>
>>> --
>>> This email has been checked for viruses by AVG.
>>> https://www.avg.com
>>>
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
