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
