Specifically, if we normalize keys then it could make sense to normalize numeric keys and it could make sense to normalize character keys, but it does not make sense to support arbitrarily structured boxes as keys.
As for extended precision numeric types... the most robust approach would be to have a set of fallbacks where convertible numbers share a common representation, I suppose. Thanks, -- Raul On Wed, Apr 14, 2021 at 11:41 AM Raul Miller <[email protected]> wrote: > > I did not implement a canonical form in that prototype. > > (The first draft didn't even support independent dictionaries -- the > bugfix added that.) > > Anyways, in my opinion: if keys are going to have a canonical form > which merges types, then it no longer makes sense to support "all > types". > > Thanks, > > -- > Raul > > On Wed, Apr 14, 2021 at 11:36 AM Henry Rich <[email protected]> wrote: > > > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
