Pascal, I have not yet had a chance to look at your proposed dictionary addon. But I will. And it is nice that Raul is paying attention.
I want to strongly second your comment that locales are not at all appropriate for this. Locales are good for what they are good for. Using them for a serious implementation of a data structure is a wrong and a serious misuse. Next stop would be a locale based implementation of integer arrays. I On Mon, Mar 14, 2022 at 4:23 PM 'Pascal Jasmin' via Programming < programm...@jsoftware.com> wrote: > I'll remind "the world" that a dictionary implementation has been > published: https://github.com/Pascal-J/kv > > I'll defend it as being the most J friendly implementation for having > functional access + manipulation features, it further has, through the kvO > adverb, the ability to J-optimize access at the expense of future > manipulation. J is mostly considered a tool for structuring information > prior to querying/subsetting it. A locale based state-oriented dictionary > approach makes it overhead/difficult to extract information subsets, and > adds object management difficulties on top of the access. > > > To paraphrase Hitchhiker's galaxy, "first God/J/Ken created OOP and > locales, and everyone agreed that was terrible" > > > > On Monday, March 14, 2022, 10:01:28 a.m. EDT, Michal Wallace < > michal.wall...@gmail.com> wrote: > > > > > > It's true that dictionaries aren't really a "fundamental" data type, since > they're easy to implement atop arrays. > But I think for a lot of people, they've become a fundamental "thinking > type"... > > I think jan-pieter's requirements list is a good start. I would add: > > - nice syntax for constructing the mapping as a list of pairs rather than a > pair of lists. > - nice syntax for traversing nested structures > - ability to write "accessor" methods that intervene > - ability to chain dictionaries together (to give search paths like locales > have) > > I've mentioned before that I think there could be a real benefit to having > a nested namespace model for locales. > I think it would be nice if, when you imported a module from path > 'foo/bar/baz', you could trust that it would load > something into a namespace that had a corresponding nested path name. > > That does raise the question about how to make navigating a path play nice > with J's right-to-left syntax. > > In other words, I think locales already do much of what we want for > dictionaries, but I'm not sure if they're implemented > in terms of hashtables. (AFAIK, k3 doesn't even use hash tables for > dictionaries. It's always just a linear lookup.) > > One thing that is missing is the ability to have arbitrary (non-identifier, > or even non-string) keys, or the ability to fetch multiple values at once. > > In j-kvm (that console library I've been working on), I implemented a > simple verb that I really wish had a standard name in J: > > of =: {{ (x,'__y')~ [ y }}"1 0 > > My ui widgets have two separate flags related to display: V__w indicates > that w is visible, and R__w indicates that it's in need of a refresh. > So when it comes time to render an application with list of widgets W: I > can select both flags at once from all the widgets: > > render =: {{ > for_w. W #~ *./'VR' of "0 W do. > NB. render w > end. }} > > > > On Mon, Jan 31, 2022 at 1:27 PM Henry Rich <henryhr...@gmail.com> wrote: > > > 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 > > > > > > > > On 1/31/2022 12:58 PM, Elijah Stone wrote: > > > I agree with Eric regarding the challenges of adding dictionaries. > > > > > > One issue: I think a necessary prerequisite is improved symbols. > > > > > > On Mon, 31 Jan 2022, Alex Shroyer wrote: > > > > > >> I 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 > > >> > > >> > > >> On Mon, Jan 31, 2022 at 5:30 AM Raoul Schorer < > raoul.scho...@gmail.com> > > >> wrote: > > >> > > >>> 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 > > >>> > > >>> Le lun. 31 janv. 2022 à 03:49, Ric Sherlock <tikk...@gmail.com> a > > >>> écrit : > > >>> > > >>> > 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 :) > > >>> > > > >>> > On Mon, Jan 31, 2022 at 3:28 PM Elijah Stone <elro...@elronnd.net> > > >>> wrote: > > >>> > > > >>> > > 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. > > >>> > > > > >>> > > On Mon, 31 Jan 2022, Ric Sherlock wrote: > > >>> > > > > >>> > > > 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? > > >>> > > > > > >>> > > > > > >>> > > > On Mon, Jan 31, 2022 at 9:01 AM Michail L. Liarmakopoulos < > > >>> > > > m.l.liarm...@gmail.com> wrote: > > >>> > > > > > >>> > > >> 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 > > >>> > > >> > > >>> > > >> On Sun, Jan 30, 2022, 20:39 R.E. Boss <r.e.b...@outlook.com> > > >>> wrote: > > >>> > > >> > > >>> > > >> > > > >>> > > >> > > > >>> > > >> > 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 > > >>> > > >> > > >>> > > > > > >>> > ---------------------------------------------------------------------- > > >>> > > > 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 > > > > > > -- > > 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
