The dyad i. primitive contains optimizatins using hash and should perform much better than linear search, moreover j806 avx uses hardware crc32 as hash. I suspect simple dyad i. can out perform some dictionary implementations.
Ср, 12 апр 2017, jprogramming написал(а): > One potential problem with using two arrays, one for keys and one for values, > is that lookup time increases by O(n), whereas it may be desirable for > constant time lookup, or O(log n). > E.g. it makes it difficult to implement some algorithms that require constant > time lookup datastructures. > > > On Apr 12, 2017, 23:07, at 23:07, Raul Miller <[email protected]> wrote: > >The reason J does not implement dictionaries (and seems to be designed > >to discourage their use) has to do with how bad dictionaries can > >mangle your architecture. > > > >In my experience you usually want to find multiple different pieces of > >information when looking things up. With a dictionary approach that > >typically means you wind up with objects that hold all these different > >things. > > > >But when you are working with collections what this means is that for > >each kind of information you want to extract you need to visit each > >object in the collection. And, while that is fine for some things, it > >is really bad for dealing with lots of things. > > > >So, instead, J encourages you to think through the process. > > > >Anyways, I typically wind up working with indices (which I get through > >some lookup mechanism), and then on sequences extracted using indices. > >This all seems simple and second nature to me, but apparently it > >baffles some people (and I do remember having to be taught some tricks > >involving grade-up and/or grade-down to deal with some of the > >complications that can arise when dealing with things which are > >ordered in different ways). > > > >Put differently, I think people spend way too much time trying to add > >abstraction to J, when J already provides way more abstraction than > >they have had time to understand. > > > >Put differently, it's usually best to learn J while focusing on > >"non-computer-science" problems: Physics, chemistry, engineering, > >biology, music, 3d printing, art, even [human] language drills all can > >lead to quite instructive questions (and you should *not* be > >embarrassed about asking them nor should you be hesitant about > >clarifying your focus and needs when the initial exchange is not > >satisfying). > > > >Put differently, there's reasons people keep re-inventing abstractions > >like dictionaries and one of those reasons is that the thousands (or > >more) of existing implementations all have baggage that make them > >inappropriate for some kinds of problem solving. > > > >Or, at least, that's my opinion. > > > >That said, here's basic J lookup: > > > > inds=. keys i. names > > vals=. inds { values > > ... > > > >Or, if you really don't have multiple things you're after: > > vals=. (keys i. names) { values > > > >Or, if you must have shorter lines (never mind that we're already more > >concise than a variety of implementations of dictionaries): > > v=.V{~k i.nm > > > >(or skip the assignment and plug the expression in where you need the > >values). > > > >Put differently: how are you going to use this? > > > >Thanks, > > > >-- > >Raul > > > > > >On Wed, Apr 12, 2017 at 9:28 AM, 'Jon Hough' via Programming > ><[email protected]> wrote: > >> I created one a while ago. > >> https://github.com/jonghough/msgpack-j/blob/master/hashmap.ijs > >> This is a crude implementation of a hashmap, using separate chaining. > >Admittedly, it isn't particularly great. E.g. hashing function > >implementation isnt very good. It uses symbols to represent inner > >hashmaps as a horrific workaround. > >> > >> As Pascal said, maybe it is better to use a functional / J-esque > >approach. J oop has some serious limitations. E.g. there is no typeof > >function (that i am aware of), and object references are represented as > >boxed literals. . . So what do you do if your dictionary contains > >another dictionary, and boxed literals? There is no way to distinguish > >them. > >> > >> On the same topic, I wonder if anyone has implemented a good > >noncrypto hash function in J? E.g. murmurhash? Would be useful for > >implementing a hashmap. > >> > >> Regards, > >> Jon > >> > >> On Apr 12, 2017, 21:34, at 21:34, Herbert Weissenbaeck // Privat > ><[email protected]> wrote: > >>>Next beginner's question: What would be an efficient/fast (or the > >>>recommended) J way to implement a dictionary with strings as keys and > >>>arbitrary contents (nouns, verbs, boxes) as values, which allows > >>>inserting, removing, fetching and editing? > >>> > >>>Thank you. > >>> > >>> > >>> > >>> > >>>Sent from my iPhone > >>>---------------------------------------------------------------------- > >>>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 -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
