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
