I used dictionary objects in Visual Basic (Access) to report similarity in text strings based on trigram usage. The keys were the distinct 3-letter combinations; the values were the incremented hit counts. It was both efficient and effective. But I think there is a better array approach in J.
> On Nov 18, 2019, at 1:15 PM, Devon McCormick <devon...@gmail.com> wrote: > > I would like to see examples of where a dictionary would be the preferred > way of dealing with some data. Does anyone know of any, not necessarily in > J, that are short and to the point? > > >> On Mon, Nov 18, 2019 at 1:02 PM Danil Osipchuk <danil.osipc...@gmail.com> >> wrote: >> >> I quickly put together a minimal implementation along those lines, to have >> a subject for a discussion regarding performance and general usage >> An object 'Map has a hash list mapping hash value to other 2 lists -- boxed >> lists of boxed keys (per hash value) and boxed lists of boxed values. >> >> It is not thoroughly tested and not well thought through about argument >> boxing and ranks, but should be pretty close to what would be a >> straightforward implementation of the thing. >> 'get_Map key' should give a boxed value for a key or raise a error if key >> is absent >> 'somevalue get_Map key' should give a stored value or save and return >> somevalue if key is not there (but I can not catch an exception raised in a >> monad called from a dyad - something silly, but have to go home) >> 'key put__Map value' stores a value >> 'delkey__Map key' removes a key if there >> >> M=: 0 conew'map' >> >> 123 put__M 1230 >> >> 1230 >> >> 'strkey' put__M 'strval' >> >> strval >> >> (<'boxkey') put__M <'boxval' >> >> ┌──────┐ >> >> │boxval│ >> >> └──────┘ >> >> keys__M >> >> ┌─────┬────────┬──────────┐ >> >> │┌───┐│┌──────┐│┌────────┐│ >> >> ││123│││strkey│││┌──────┐││ >> >> │└───┘│└──────┘│││boxkey│││ >> >> │ │ ││└──────┘││ >> >> │ │ │└────────┘│ >> >> └─────┴────────┴──────────┘ >> >> hashes__M >> >> _1845511330 2120780259 _71755953 >> >> values__M >> >> ┌──────┬────────┬──────────┐ >> >> │┌────┐│┌──────┐│┌────────┐│ >> >> ││1230│││strval│││┌──────┐││ >> >> │└────┘│└──────┘│││boxval│││ >> >> │ │ ││└──────┘││ >> >> │ │ │└────────┘│ >> >> └──────┴────────┴──────────┘ >> >> get__M 123 >> >> ┌────┐ >> >> │1230│ >> >> └────┘ >> >> get__M 'not there' >> >> |uncaught throw.: get__M >> >> | get__M'not there' >> >> 'to set to something' get__M 'not there' >> >> |uncaught throw.: get >> >> | get y >> >> delkey__M 123 >> >> 1 >> >> get__M 123 >> >> |uncaught throw.: get__M >> >> | get__M 123 >> >> values__M >> >> ┌────────┬──────────┐ >> >> │┌──────┐│┌────────┐│ >> >> ││strval│││┌──────┐││ >> >> │└──────┘│││boxval│││ >> >> │ ││└──────┘││ >> >> │ │└────────┘│ >> >> └────────┴──────────┘ >> >> keys__M >> >> ┌────────┬──────────┐ >> >> │┌──────┐│┌────────┐│ >> >> ││strkey│││┌──────┐││ >> >> │└──────┘│││boxkey│││ >> >> │ ││└──────┘││ >> >> │ │└────────┘│ >> >> └────────┴──────────┘ >> >> пн, 18 нояб. 2019 г. в 16:10, Henry Rich <henryhr...@gmail.com>: >> >>> Right now I am thinking that the need for dictionaries could be met by a >>> class whose instances are associative memories. Key, values, >>> hashtables, chains if needed would be stored inside the instance. The >>> interface would be simply x Put y and Get y. I reckon this would be >>> fast enough without any special support from the interpreter beyond the >>> hash calculation that is there now. >>> >>> Henry Rich >>> >>> On 11/18/2019 6:10 AM, Danil Osipchuk wrote: >>>> symbols are essentially names optimized for lookup and comparison, as >>> such >>>> they are useful to implement locales efficiently, if one to build an >> map >>>> using those as keys, indeed one gets something resembling K >> dictionaries >>>> http://www.math.bas.bg/bantchev/place/k.html : >>>> >>>> "Another distinguishing feature of K is the use of dictionaries: >>>> associative tables whose keys are symbols, i.e., internalized strings. >> In >>>> turn, dictionaries are the building material of a hierarchically >>> organized >>>> global data space called the K-tree" >>>> >>>> https://github.com/kevinlawler/kona/wiki/Dictionaries >>>> >>>> This is important case of course, but still a restriction. Tables in >> Lua >>>> are more fundamental: >>>> >>>> "The table type implements associative arrays. An associative array is >> an >>>> array that can be indexed not only with numbers, but also with strings >> or >>>> any other value of the language, except *nil*. Moreover, tables have no >>>> fixed size; you can add as many elements as you want to a table >>>> dynamically. Tables are the main (in fact, the only) data structuring >>>> mechanism in Lua, and a powerful one. We use tables to represent >> ordinary >>>> arrays, symbol tables, sets, records, queues, and other data >> structures, >>> in >>>> a simple, uniform, and efficient way. Lua uses tables to represent >>> packages >>>> as well. When we write io.read, we mean "the read entry from the io >>>> package". For Lua, that means "index the table io using the string >> "read" >>>> as the key". >>>> >>>> >>>> >>>> пн, 18 нояб. 2019 г. в 13:11, 'Mike Day' via Programming < >>>> programm...@jsoftware.com>: >>>> >>>>> It's a long time since I played with s: - do J symbols have any >>>>> relevance to dictionaries/directories? >>>>> >>>>> APL/J cousin, K, appears to have the dictionary as pretty central to >> its >>>>> data organisation, but maybe >>>>> that's more akin to J's locales. >>>>> >>>>> Neither topic helpful probably relevant here, but might start a hare! >>>>> >>>>> Mike >>>>> >>>>> On 18/11/2019 02:49, Henry Rich wrote: >>>>>> In J I find myself coming back to simple arrays for most data >>> structures. >>>>>> >>>>>> Trees can be represented as boxes containing subtrees. That works, >>>>>> but is usually more trouble than simply managing an array. >>>>>> >>>>>> Linked lists are used only for efficiency, and in the cases where >> that >>>>>> matters you can easily have a list of indexes to an array of data >>> items. >>>>>> >>>>>> Stacks are just lists, as Devon said. >>>>>> >>>>>> The datatype I really want is a directory object that acts as an >>>>>> efficient and easy-to-use associative memory. You put key/values in >>>>>> and then retrieve a value by presenting its key. Has anyone written >>>>>> an addon for that? >>>>>> >>>>>> (Note: the primitive 128!:8 (create a hash for a noun) was added to >>>>>> J9.01 with this in mind) >>>>>> >>>>>> Henry Rich >>>>>> >>>>>> On 11/17/2019 8:16 PM, 'Bo Jacoby' via Programming wrote: >>>>>>> I failed to communicate the links before, but here they are. >>>>>>> Ordinal fractions are somewhat like infinite-dimensional arrays. >>>>>>> >>>>> >>> >> https://www.academia.edu/10031088/ORDINAL_FRACTIONS_-_the_algebra_of_data >>>>>>> >>>>>>> >>>>>>> http://www.statemaster.com/encyclopedia/Ordinal-fraction >>>>>>> Bo. >>>>>>> >>>>>>> Den søndag den 17. november 2019 22.07.28 CET skrev Devon >>>>>>> McCormick <devon...@gmail.com>: >>>>>>> Trees are simple to implement in J - >>>>>>> https://code.jsoftware.com/wiki/User:Devon_McCormick/Trees - as are >>>>>>> graphs >>>>>>> - >>>>>>> >>>>> >>> >> https://code.jsoftware.com/wiki/NYCJUG/2009-11-10/BreadthFirstGraphTraversal >>>>>>> . >>>>>>> A stack is simple to implement too but I'm not sure why you would >>>>>>> want to >>>>>>> as it's simply a vector with very restrictive rules to manipulate >> it. >>>>>>> Linked lists make no sense in a language with dynamic arrays for >> much >>>>>>> the >>>>>>> same reason since a linked list is mainly a way of implementing >>> dynamic >>>>>>> arrays but has benefit only in a language which lacks these >> natively. >>>>>>> >>>>>>> On Sun, Nov 17, 2019 at 8:24 AM 'Bo Jacoby' via Programming < >>>>>>> programm...@jsoftware.com> wrote: >>>>>>> >>>>>>>> ORDINAL FRACTIONS - the algebra of data >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | | | >>>>>>>> >>>>>>>> | >>>>>>>> >>>>>>>> | >>>>>>>> | >>>>>>>> | | >>>>>>>> ORDINAL FRACTIONS - the algebra of data >>>>>>>> >>>>>>>> This paper was submitted to the 10th World Computer Congress, IFIP >>> 1986 >>>>>>>> conference, but rejected by the referee.... >>>>>>>> | >>>>>>>> >>>>>>>> | >>>>>>>> >>>>>>>> | >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Den søndag den 17. november 2019 07.12.02 CET skrev Raul >>> Miller < >>>>>>>> rauldmil...@gmail.com>: >>>>>>>> >>>>>>>> Arrays are roughly analogous to computer memory. >>>>>>>> >>>>>>>> Put different: I think you are asking the wrong question. >>>>>>>> >>>>>>>> (Partially: it's worth thinking about why you pick whichever data >>>>>>>> structures...) >>>>>>>> >>>>>>>> ((It can also sometimes be useful to look on rosettacode for >>>>>>>> examples of >>>>>>>> various daya structure handling mechanisms.)) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -- >>>>>>>> Raul >>>>>>>> >>>>>>>> On Sat, Nov 16, 2019 at 6:00 PM Jimmy Gauvin < >> jimmy.gau...@gmail.com >>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> when dealing with data structures other than arrays such as trees, >>>>>>>> graphs, >>>>>>>>> stacks, linked lists what other programming language do you resort >>>>>>>>> to ? >>>>>>>>> >>>>>>>>> Or do stick with J for all endeavours? >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy >>>>>>>>> >>> ---------------------------------------------------------------------- >>>>>>>>> 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 >>>>> ---------------------------------------------------------------------- >>>>> 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 >> > > > -- > > Devon McCormick, CFA > > Quantitative Consultant > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
