If I'm not mistaken though, J symbols are not garbage collected, are they? Wouldn't that be a problem for dictionaries with symbol keys doing a lot of insertions/deletions?
Sorry if I missed something I. The docs about that. Cheers, Raoul Le lun. 31 janv. 2022 à 21:40, greg heil <ghei...@gmail.com> a écrit : > i just want to reiterate > the point Alex Shroyer made > about k dictionaries > > i found them extremely useful > and upon occasion > groused about not having them in J > > i used them to represent > an (English) dictionary > very facile efficient and fast > > the fact is our world > is (mostly) filled > with ragged objects > ... not the regular arrays > that J folk so love > > eg > HTML > language dictionaries, encyclopedias... > outlines... > > ~greg heil > picsrp.github.io > i.tgu.ca/real_cal > > -- > > from: Henry Rich <henryhr...@gmail.com> > to: programm...@jsoftware.com > date: Jan 31, 2022, 10:43 AM > subject: [Jprogramming] Dictionaries WAS: Report on the J wiki meeting > of January 27, 2022 > > >Quite right. Jan-Pieter has at least a good start on the model. What I > am suggesting is that the 'more integrated implementation' might not need > to be much more integrated than the J script. Searching and sorting are > already J primitives. > > >The deficiency in J is that m&i. gives you a hashtable for searching m, > but if you modify m you have to recalculate the hash from scratch. This > makes m&i. a good read-mostly Dictionary but slow for frequent updates. If > we can refine the model to the point that such inefficiency is the worst > problem we have, a little integrated support could finish the package. > > Henry Rich > > -- > > from: Eric Iverson <eric.b.iver...@gmail.com> > to: Programming forum <programm...@jsoftware.com> > date: Jan 31, 2022, 10:37 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >A good and complete model is the first step. Then it is a matter of how > much it is used and what drawbacks it might have that would be addressed by > a more integrated implementation. > > -- > > from: Henry Rich <henryhr...@gmail.com> > to: programm...@jsoftware.com > date: Jan 31, 2022, 10:27 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >I have looked into this quite a bit. I am not convinced that Dictionary > is a fundamental datatype like number or letter, or that the current symbol > support is deficient. That makes the first questions What is a Dictionary? > and Where can a Dictionary be used in J? > > >The use case that would be important to me is a key-value store, aka > associative memory, where the Dictionary remember keys and values and later > returns a value when presented with the key. This feels to me like a > package written in J rather than a J primitive. A Dictionary would be a > numbered locale. The place where I could see added support inside J would > be in adding to and deleting from hashtables, specifically ones > created/used by m&i. . > > >I invite proposals on what a Dictionary package needs to do. I have done > this before, and Jan-Pieter Jacobs responded with a package. Quoting from > his message of 20210327: > > *** QUOTE > > install'github:jpjacobs/types_dict@main' > > >(except on (my) android, where github installs don't seem to work, > neither in the Gui version JA nor on the commandline via termux) > > >It is pretty simple in use, you just use: d=: dict keys;vals for creating > the dictionary, which is a OOP object, having the following methods: get, > set, map, sort, destroy, whose documentation is contained in help_pdict_ > > >For performance, the create verb precomputes the lookup for the get verb, > both forward get (key->value) and backward get inv (value->first key) upon > object creation. > > >*** END QUOTE > > >I have not looked into this package, but it seems to me to have the right > entry points. Can we take that as a starting point to see what needs to be > added? The first step of course would be to put the addon under Package > Manager. > > Henry Rich > > -- > > from: Elijah Stone <elro...@elronnd.net> > to: programm...@jsoftware.com > date: Jan 31, 2022, 9:58 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >I agree with Eric regarding the challenges of adding dictionaries. > > >One issue: I think a necessary prerequisite is improved symbols. > > -- > > from: Eric Iverson <eric.b.iver...@gmail.com> > to: Programming forum <programm...@jsoftware.com> > date: Jan 31, 2022, 8:36 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >It seems to me that the big distinction between J and python where J > falls far short is not in the core language but in the addon libraries. I > encourage J fans to work away at adding important addons to J! > > -- > > from: Eric Iverson <eric.b.iver...@gmail.com> > to: Programming forum <programm...@jsoftware.com> > date: Jan 31, 2022, 8:28 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > -- > > >A J dictionary type is a good idea and it has been kicked around many > times before. The hard part is not implementing it, but doing a careful and > thorough spec that is backed by a complete model written in J. > > >Presented with a full spec that had community buy in, would probably be > followed by implementation. > > -- > > from: Alex Shroyer <ashro...@gmail.com> > to: programm...@jsoftware.com > date: Jan 31, 2022, 8:14 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > -- > > >agree with Raoul that competing with Python is not a good idea. But J can > learn from Python's decisions (good and bad) to grow and improve. In my > opinion, numpy is Python's "killer app" because it brings reasonable > performance without much conceptual overhead. The feature of Python that > enabled numpy is its extensibility, down to the C layer. > > There are other good features of Python that J could copy, in > particular the 'dictionary' data type. The array language K has > dictionaries, so J might take some inspiration from there for > integrating them into the language. > > Cheers, > Alex > > -- > > from: Raul Miller <rauldmil...@gmail.com> > to: programm...@jsoftware.com > date: Jan 31, 2022, 7:02 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > -- > > What does "competing with python" mean? > > >(I suspect that we must "compete" in some contexts, but I also imagine > that "competition" would be irrelevant in many, many contexts. But.. as a > programming exercise, I don't know how to conceptualize these distinctions.) > > Thanks, > > -- > > from: Raoul Schorer <raoul.scho...@gmail.com> > to: programm...@jsoftware.com > date: Jan 31, 2022, 2:30 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >Just my 2c, but I think that competing with python in general is somewhat > delusional. I think the key point for expanding J use to have a "killer J > app". For example, an improved clone of or excellent plugin for VisiData ( > https://www.visidata.org/) is my idea of a killer app. But someone here > may have a better idea? > > >Cheers, > Raoul > > >-- > > from: Ric Sherlock <tikk...@gmail.com> > to: Programming JForum <programm...@jsoftware.com> > date: Jan 30, 2022, 6:50 PM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >Yes from a data structure point of view, inverted tables get you a lot of > the way (note they're also available in the 'general/misc' addon - load > 'general/misc/inverted' ) and I've used them to good effect in my > 'data/struct' addon (https://github.com/tikkanz/data_struct). I agree > that J's arrays are more general, flexible & powerful. But when you're > dealing with a tabular data set there is an overhead to keeping the fields > in a table in sync that dataframes can help with. Perhaps it's something > abstracting the structure so you don't have to deal so much with the > mechanics of manipulating it? At least for me :) > > -- > > from: Elijah Stone <elro...@elronnd.net> > to: Programming JForum <programm...@jsoftware.com> > date: Jan 30, 2022, 6:29 PM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > -- > > https://code.jsoftware.com/wiki/Essays/Inverted_Table, perhaps? > > >That said, I think a great strength of j is that data are _not_ > explicitly tabular. The associations are defined in an ad-hoc manner as > needed by the programmer. This is also an essential difference between the > array paradigm and the relational paradigm (cf SQL): in the former, > pointers come with implicit context; in the latter, that context must be > explicit. > > -E > > >P.S. regarding analysis/optimization: I would love to see it, but for > some reason everybody is scared of building a compiler because of the > parsing problem. > > -- > > from: Ric Sherlock <tikk...@gmail.com> > to: Programming JForum <programm...@jsoftware.com> > date: Jan 30, 2022, 6:21 PM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >Yes, I've been thinking that a Dataframes equivalent in J would be > useful. Most things are already possible with J's arrays, but conceptually > DataFrames are well understood by many now, and they make it easy to work > with datasets as named fields. I've spent a reasonable amount of time > working with Pandas, but have recently been using Polars (Rust backend with > Python bindings) which really shines for larger datasets. Performance > (especially read/write) is awesome, and the LazyFrames which optimise your > query/analysis plan make a big difference too. I haven't taken enough time > to explore it, but maybe Jd is the starting point in this space for J? > > -- > > from: Michail L. Liarmakopoulos <m.l.liarm...@gmail.com> > to: programm...@jsoftware.com > date: Jan 30, 2022, 12:06 PM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > Hello Elijah, > > >Yes, I believe you're right. I don't have much experience with them yet > though, so I cannot compare. > > Best, > > --- > Michail L. Liarmakopoulos, MSc > > -- > > from: Elijah Stone <elro...@elronnd.net> > to: programm...@jsoftware.com > date: Jan 30, 2022, 12:04 PM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > -- > > On Sun, 30 Jan 2022, Michail L. Liarmakopoulos wrote: > > >> There is also out there an amazing python library for symbolic > calculations (like the ones you can do with Mathematica or WolframAlpha: > symbolic evaluation of definite and indefinite integrals, symbolic > solutions of diff. equations, symbolic solutions of algebraic and > Diophantine equations etc...). It's called sympy. > > >> But I'm not sure if you'd like J to include symbolic computations too > or if the aim of the language is to excel only in numerics, data analytics, > stats, whatever can be quantified pretty much. > > Aren't there some symbolic calculus library functions? > > >(Though I doubt they're anywhere near the level of mathematica, let alone > sympy.) > > -- > > from: Michail L. Liarmakopoulos <m.l.liarm...@gmail.com> > to: programm...@jsoftware.com > date: Jan 30, 2022, 12:01 PM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > Hello all, > > >I find any parallels between python and J pretty interesting, being a > person with some python experience and an interest of the applications of > both python and J in mathematical modelling, analytics, computational math > and perhaps computational physics too. > > >If you'd like to bring some features from the python math/analytics > libraries/ecosystem in J, I'd suggest you to look at the features of three > libraries: > > >- numpy (I believe most features are already covered from the built in > features of an array language such as J) > > - pandas ( a nice library for manipulating csv files within python as > dataframe objects -- see the dataframes from the R language) > > >- scipy (a collection of methods and functions ranging from solving > numerically: differential equations, evaluating definite integrals, > constrained and unconstrained optimization, and I believe statistics too) > > >There is also out there an amazing python library for symbolic > calculations (like the ones you can do with Mathematica or WolframAlpha: > symbolic evaluation of definite and indefinite integrals, symbolic > solutions of diff. equations, symbolic solutions of algebraic and > Diophantine equations etc...). It's called sympy. > > >But I'm not sure if you'd like J to include symbolic computations too or > if the aim of the language is to excel only in numerics, data analytics, > stats, whatever can be quantified pretty much. > > >My few cents as food for thought. > > Best regards, > > --- > Michail L. Liarmakopoulos, MSc > > -- > > from: R.E. Boss <r.e.b...@outlook.com> > to: "programm...@jsoftware.com" <programm...@jsoftware.com> > date: Jan 30, 2022, 11:39 AM > subject: Re: [Jprogramming] Report on the J wiki meeting of January 27, > 2022 > > >I copied the first chapter of the book A Journey to Core Python (in > https://drive.google.com/file/d/1p1uIANh-LFniNNRqjDeeWWd4_-ddEZmz/view?usp=sharing) > and have the question: do we want that J is competitive with Python? > > >If the answer is yes, the next question is: what is the to do list to be > competitive and how long will it take? > > >(And then the unavoidable question: WHY?) > > >Personally I think we must aim on the niches in the market, as there are > the mathematical oriented people, e.g. the broad scientific community. > > >Then all people experienced in Excel or other spreadsheets or calculation > tools. > > >Schools and universities. Financial and statistical oriented people. > > >What we should do, IMHO, is > > >- to emphasize the strengths of J, > > >- to improve (considerably) the error handling of J, > > >- to admit the steep learning curve, > > > >- to facilitate the use of mnemonics instead of primitives (I tried this > afternoon the primitives.ijs for half an hour, but was not capable of use > any mnemonic, not even with > https://code.jsoftware.com/wiki/Primitives_to_Mnemonics) > > >- to decide which of the features, benefits or applications (of Python) > we want J to have. > > >Just my 2 cents. > >R.E. Boss > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
