alright, start with the most bare-bones approach, adding more depending on overwhelmingly frequent user request, got it there’s no need to fill out anything, then
still, the conclusion remains valid: if we want the user to be able to invert any dict, metavars key and value must be interchangeable Am 14.04.21 um 17:11 schrieb Henry Rich: > Why not say that if the user wants an inverted index, they create one? > > Henry Rich > > On 4/14/2021 11:10 AM, Hauke Rehr wrote: >> there should be a create-inverse-dict routine >> which may or may not be trivial to do depending on design choices >> >> … which means either both the key and value types are flexible, >> or neither >> >> (that’s just what came to my mind spontaneously) >> >> Am 14.04.21 um 16:56 schrieb Henry Rich: >>> 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, >>>> >>> > > -- ---------------------- mail written using NEO neo-layout.org ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
